On 2013-11-29 13:14:06 -0800, Kevin Grittner wrote: > Andres Freund <and...@2ndquadrant.com> wrote: > > On 2013-11-27 15:42:11 -0800, Kevin Grittner wrote: > > >> What back-patching will be needed for a fix? It sounds like > >> 9.3? > > > > Yep. > > In going over this, I found pre-existing bugs when a tuple was both > inserted and deleted by concurrent transactions, but fixing that is > too invasive to consider for Monday's minor release lockdown. The > attached seems very safe to me, and protects against some new > hazards related to the subtransaction changes (mostly just for an > assert-enabled build, but still worth fixing). It includes a lot > of work on the comments, to guide the subsequent fixes or other > work in that area.
> If nobody objects, I will push it to master and 9.3 tomorrow. Alvaro is about to commit a patch that will remove the behaviour of GetUpdateXid() to check for IdDidAbort() because it makes other fixes really complicated and it's a really suprising behaviour. But most of your patch shouldn't be affected by that. Check http://archives.postgresql.org/message-id/20131129193008.GP5513%40eldon.alvh.no-ip.org for the current state of the series. Looking at predicate.c I think I see a bigger problem though: Isn't its usage of HeapTupleSatisfiesVacuum() quite dangerous? It passes TransactionXmin to HeapTupleSatisfiesVacuum(). But since that's just the transaction's own cutoff, not the global cutoff that will cause wrong hint bits to be set. Or am I missing something? HTSV's comment says: * * OldestXmin is a cutoff XID (obtained from GetOldestXmin()). Tuples * deleted by XIDs >= OldestXmin are deemed "recently dead"; they might * still be visible to some open transaction, so we can't remove them, * even if we see that the deleting transaction has committed. */ 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