Re: pg_export_snapshot on standby side - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: pg_export_snapshot on standby side
Date
Msg-id CA+U5nML2VMJ3R2YBAZ+CsAsTWF3LuYSo16Wu9+yXFrfy4=f2fA@mail.gmail.com
Whole thread Raw
In response to pg_export_snapshot on standby side  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: pg_export_snapshot on standby side  (Fujii Masao <masao.fujii@gmail.com>)
Re: pg_export_snapshot on standby side  (Bruce Momjian <bruce@momjian.us>)
Re: pg_export_snapshot on standby side  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 21 May 2013 19:16, Fujii Masao <masao.fujii@gmail.com> wrote:

> We cannot run parallel pg_dump on the standby server because
> pg_export_snapshot() always fails on the standby. Is this the oversight
> of parallel pg_dump or pg_export_snapshot()?
>
> pg_export_snapshot() fails in the standby because it always assigns
> new XID and which is not allowed in the standby. Do we really need
> to assign new XID even in the standby for the exportable snapshot?

Having looked at the code, I say No, we don't *need* to.

There are various parts of the code that deal with
takenDuringRecovery, so much of this was clearly intended to work in
recovery.

We use the topXid for the name of the snapshot file. That is clearly
unnecessary and we should be using the virtualxid instead like we do
elsewhere. We also use the topXid to test whether it is still running,
though again, we could equally use the virtualxid instead. There is no
problem with virtualxids possibly not being active anymore, since if
we didn't have an xid before and don't have one now, and the xmin is
the same, the snapshot is still valid.

I think we should treat this as a bug and fix it in 9.3 while we're
still in beta. Why? Because once we begin using the topXid as the
filename we can't then change later to using the vxid.

--Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Amit kapila
Date:
Subject: Re: pg_rewind, a tool for resynchronizing an old master after failover
Next
From: Ants Aasma
Date:
Subject: Re: pg_rewind, a tool for resynchronizing an old master after failover