Re: pgsql: Don't force-assign transaction id when exporting a snapshot.

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-committers(at)postgresql(dot)org
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgsql: Don't force-assign transaction id when exporting a snapshot.
Date: 2017-08-12 11:32:24
Message-ID: 7aed5039-7bc5-764b-b6d5-114d835f1e9a@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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

Attachment Content-Type Size
0001-Allow-pg_dump-j-on-standby-when-dumping-from-PG10.patch text/x-patch 2.9 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-08-12 16:08:59 pgsql: Simplify fetch-slot-xmins logic in recovery TAP tests.
Previous Message Tom Lane 2017-08-11 21:39:47 pgsql: Be more thorough about cleaning out gcov litter.

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2017-08-12 11:37:55 Re: [PATCH] Generic type subscripting
Previous Message Michael Paquier 2017-08-12 08:38:29 Re: More race conditions in logical replication