From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |
Date: | 2012-12-07 01:12:27 |
Message-ID: | 20121207011227.GC12354@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Jeff Davis (pgsql(at)j-davis(dot)com) wrote:
> However, the rows will *not* be visible, because the serializable
> snapshot doesn't contain the inserting transaction.
That's what we've got now and what would be expected, however...
> Think about the current behavior: right after the commit, another select
> could come along and set all those hint bits anyway. Even if the hint
> bits aren't set, it will do a CLOG lookup and find that the transaction
> committed.
The command is 'FREEZE', which sounded to me like the transaction ID
would be set to FrozenXID, meaning that we wouldn't be able to tell if
the inserting transaction was before or after ours...
Your analysis of the hint bits themselves sounds reasonable but it seems
independent of the issue regarding setting the actual transaction ID.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-12-07 01:16:36 | Re: pg_upgrade problem with invalid indexes |
Previous Message | Andrew Dunstan | 2012-12-07 01:05:56 | Re: pg_upgrade problem with invalid indexes |