Hi Peter, Nice to see the next version, won't have time to look in any details in the next few days tho.
On 2013-09-10 22:25:34 -0700, Peter Geoghegan wrote: > I am working on an analysis of the broader deadlock hazards - the > implications of simultaneously holding multiple shared buffer locks > (that is, one for every unique index btree leaf page participating in > value locking) for the duration of a each heap tuple insertion (each > heap_insert() call). I'm particularly looking for unexpected ways in > which this locking could interact with other parts of the code that > also acquire buffer locks, for example vacuumlazy.c. I'll also try and > estimate how much of a maintainability burden unexpected locking > interactions with these other subsystems might be. I think for this approach to be workable you also need to explain how we can deal with stuff like toast insertion that may need to write hundreds of megabytes all the while leaving an entire value-range of the unique key share locked. I still think that even doing a plain heap insertion is longer than acceptable to hold even a share lock over a btree page, but as long as stuff like toast insertions happen while doing so that's peanuts. The easiest answer is doing the toasting before doing the index locking, but that will result in bloat, the avoidance of which seems to be the primary advantage of your approach. 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