On Tue, Mar 31, 2015 at 2:26 PM, Peter Geoghegan <p...@heroku.com> wrote: > Andres' wish to do things that way is at least partially motivated by > having logical decoding just work.
I should add that there appears to be some need to terminate the loop of speculative token waiting. By that I mean that since we're not looking at the proc array to get a speculative token from HeapTupleSatisfiesDirty() now, there is a livelock hazard. That goes away when the speculative inserter cleans up after itself, as Andres proposed. It would also go away if any speculative waiter cleaned up after the inserter, which you suggested (that would be kind of invasive to places like _bt_doinsert(), though). Finally, it would also work if HeapTupleSatisfiesDirty() tested if the token was still held directly, before reporting a speculative token, by for example attempting to briefly acquire a ShareLock on the token (but that would mean that the extra lock acquisition would be required unless and until someone updated that originally-speculative tuple, in doing so finally changing its t_ctid). I think that we definitely have to do something like this, in any case. Maybe just have SpeculativeTokenWait deal with the clean up is cleanest, if we're not going to have inserters clean-up after themselves immediately per Andres' suggestion. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers