On 14/06/17 20:57, Andres Freund wrote:
> Don't force-assign transaction id when exporting a snapshot.
> Previously we required every exported transaction to have an xid
> assigned. That was used to check that the exporting transaction is
> still running, which in turn is needed to guarantee that that
> necessary rows haven't been removed in between exporting and importing
> the snapshot.
> The exported xid caused unnecessary problems with logical decoding,
> because slot creation has to wait for all concurrent xid to finish,
> which in turn serializes concurrent slot creation. It also
> prohibited snapshots to be exported on hot-standby replicas.
> Instead export the virtual transactionid, which avoids the unnecessary
> serialization and the inability to export snapshots on standbys. This
> changes the file name of the exported snapshot, but since we never
> documented what that one means, that seems ok.
This commit has side effect that it makes it possible to export
snapshots on the standbys. This makes it possible to do pg_dump -j on
standby with consistent snapshot. Here is one line patch (+ doc update)
which allows doing that when pg_dumping from PG10+.
I also wonder if it should be mentioned in release notes. If the
attached patch would make it into PG10 it would be no brainer to mention
it as feature under pg_dump section, but exporting snapshots alone I am
not sure about.
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From e2bca9b5271dbf29e5ab68d99c409c4f7dd752db Mon Sep 17 00:00:00 2001
From: Petr Jelinek
Date: Sat, 12 Aug 2017 13:16:48 +0200
Subject: [PATCH] Allow pg_dump -j on standby when dumping from PG10+
PG10 adds support for exporting snapthots on standby, allow pg_dump to
use this feature when consistent parallel dump has been requested.
doc/src/sgml/ref/pg_dump.sgml | 18 ++
src/bin/pg_dump/pg_dump.c | 2 +-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index bafa031..3c088f3 100644
@@ -337,14 +337,16 @@ PostgreSQL documentation
but to abort the dump.
-For a consistent backup, the database server needs to support synchronized snapshots,
-a feature that was introduced in PostgreSQL 9.2. With this
-feature, database clients can ensure they see the same data set even though they use
-different connections. pg_dump -j uses multiple database
-connections; it connects to the database once with the master process and
-once again for each worker job. Without the synchronized snapshot feature, the
-different worker jobs wouldn't be guaranteed to see the same data in each connection,
-which could lead to an inconsistent backup.
+For a consistent backup, the database server needs to support
+synchronized snapshots, a feature that was introduced in
+PostgreSQL 9.2 for primary servers and 10
+for standbys. With this feature, database clients can ensure they see
+the same data set even though they use different connections.
+pg_dump -j uses multiple database connections; it
+connects to the database once with the master process and once again
+for each worker job. Without the synchronized snapshot feature, the
+different worker jobs wouldn't be guaranteed to see the same data in
+each connection, which could lead to an inconsistent backup.
If you want to run a parallel dump of a pre-9.2 server, you need to make sure that the
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 37cb7cd..8ad9773 100644
@@ -1131,7 +1131,7 @@ setup_connection(Archive *AH, const char *dumpencoding,
AH->remoteVersion >= 90200 &&
- if (AH->isStandby)
+ if (AH->isStandby && AH->remoteVersion < 10)
"Synchronized snapshots are not supported on standby servers.\n"
"Run with --no-synchronized-snapshots instead if you do not need\n"
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: