On 2014-04-12 10:27:16 +0300, Heikki Linnakangas wrote:
> On 04/12/2014 12:07 AM, Jan Wieck wrote:
> >The symptom is that a txid_snapshot on output lists the same txid
> >multiple times in the xip list part of the external representation. This
> >string is later rejected by txid_snapshot_in() when trying to determine
> >if a particular txid is visible in that snapshot using the
> >txid_visible_in_snapshot() function.
> It's two-phase commit. When preparing a transaction, the state of the
> transaction is first transfered to a dummy PGXACT entry, and then the PGXACT
> entry of the backend is cleared. There is a transient state when both PGXACT
> entries have the same xid.
Which I find to be a pretty bad idea independent of this bug. But I
think that's nothing fixable in the back branches.
> Hmm. Do we snapshots to be stored in tables, and included in a dump? I don't
> think we can guarantee that will work, at least not across versions, as the
> way we handle snapshot internally can change.
Hm. I don't think we'll earn much love changing that - there's at the
very least slony and londiste out there using it... IIRC both store the
result in tables.
> But yeah, we probably should do something about that. The most
> straightforward fix would be to scan the array in txid_current_snapshot()
> and remove any duplicates.
Since it's sorted there, that should be fairly straightforward. Won't
fix already created and stored datums tho. Maybe _in()/parse_snapshot()
should additionally skip over duplicate values? Looks easy enough.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services