mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-02-05 19:09:58 +08:00
Code Issues Packages Projects Releases Wiki Activity
36,428 Commits 37 Branches 638 Tags 434 MiB
C 85.5%
PLpgSQL 5.9%
Perl 4.2%
Yacc 1.3%
Makefile 0.7%
Other 2.2%
5c9724305e
Go to file
Tom Lane 5c9724305e Redesign handling of SIGTERM/control-C in parallel pg_dump/pg_restore. 
Formerly, Unix builds of pg_dump/pg_restore would trap SIGINT and similar
signals and set a flag that was tested in various data-transfer loops.
This was prone to errors of omission (cf commit 3c8aa6654); and even if
the client-side response was prompt, we did nothing that would cause
long-running SQL commands (e.g. CREATE INDEX) to terminate early.
Also, the master process would effectively do nothing at all upon receipt
of SIGINT; the only reason it seemed to work was that in typical scenarios
the signal would also be delivered to the child processes.  We should
support termination when a signal is delivered only to the master process,
though.

Windows builds had no console interrupt handler, so they would just fall
over immediately at control-C, again leaving long-running SQL commands to
finish unmolested.

To fix, remove the flag-checking approach altogether.  Instead, allow the
Unix signal handler to send a cancel request directly and then exit(1).
In the master process, also have it forward the signal to the children.
On Windows, add a console interrupt handler that behaves approximately
the same.  The main difference is that a single execution of the Windows
handler can send all the cancel requests since all the info is available
in one process, whereas on Unix each process sends a cancel only for its
own database connection.

In passing, fix an old problem that DisconnectDatabase tends to send a
cancel request before exiting a parallel worker, even if nothing went
wrong.  This is at least a waste of cycles, and could lead to unexpected
log messages, or maybe even data loss if it happened in pg_restore (though
in the current code the problem seems to affect only pg_dump).  The cause
was that after a COPY step, pg_dump was leaving libpq in PGASYNC_BUSY
state, causing PQtransactionStatus() to report PQTRANS_ACTIVE.  That's
normally harmless because the next PQexec() will silently clear the
PGASYNC_BUSY state; but in a parallel worker we might exit without any
additional SQL commands after a COPY step.  So add an extra PQgetResult()
call after a COPY to allow libpq to return to PGASYNC_IDLE state.

This is a bug fix, IMO, so back-patch to 9.3 where parallel dump/restore
were introduced.

Thanks to Kyotaro Horiguchi for Windows testing and code suggestions.

Original-Patch: <7005.1464657274@sss.pgh.pa.us>
Discussion: <20160602.174941.256342236.horiguchi.kyotaro@lab.ntt.co.jp>
2016-06-02 13:27:53 -04:00
config Fix configure's incorrect version tests for flex and perl. 2016-05-02 11:18:11 -04:00
contrib Ensure plan stability in contrib/btree_gist regression test. 2016-05-12 20:04:41 -04:00
doc Further improve documentation about --quote-all-identifiers switch. 2016-05-20 15:52:16 -04:00
src Redesign handling of SIGTERM/control-C in parallel pg_dump/pg_restore. 2016-06-02 13:27:53 -04:00
.gitignore Add pkg-config files for libpq and ecpg libraries 2013-03-31 16:58:40 -04:00
aclocal.m4
configure Stamp 9.3.13. 2016-05-09 16:53:56 -04:00
configure.in Stamp 9.3.13. 2016-05-09 16:53:56 -04:00
COPYRIGHT Update copyright for 2016 2016-01-02 13:33:39 -05:00
GNUmakefile.in Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:12 -05:00
HISTORY Improve text of stub HISTORY file. 2014-02-12 18:16:27 -05:00
Makefile Allow make check in PL directories 2011-02-15 06:52:12 +02:00
README Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:12 -05:00
README.git Don't generate plain-text HISTORY and src/test/regress/README anymore. 2014-02-10 20:48:12 -05:00

README 

PostgreSQL Database Management System
=====================================

This directory contains the source code distribution of the PostgreSQL
database management system.

PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions, foreign keys, subqueries, triggers, user-defined types
and functions.  This distribution also contains C language bindings.

PostgreSQL has many language interfaces, many of which are listed here:

	http://www.postgresql.org/download

See the file INSTALL for instructions on how to build and install
PostgreSQL.  That file also lists supported operating systems and
hardware platforms and contains information regarding any other
software packages that are required to build or run the PostgreSQL
system.  Copyright and license information can be found in the
file COPYRIGHT.  A comprehensive documentation set is included in this
distribution; it can be read as described in the installation
instructions.

The latest version of this software may be obtained at
http://www.postgresql.org/download/.  For more information look at our
web site located at http://www.postgresql.org/.