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