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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
