Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > Tom Lane wrote: >> I really don't understand how any of this "let's release the buffer >> lock and then take it back later" logic is supposed to work reliably.
> So summarize_range first inserts the placeholder tuple, which is there > purposefully for other processes to update concurrently; then, without > blocking any other process, scan the page range and update the > placeholder tuple (this could take a long time, so it'd be a bad idea > to hold buffer lock for that long). Yeah, agreed, and your upthread point about avoiding deadlock when we need to take two buffer locks at the same time is also something that it's hard to see any other way around. Maybe we just have to find a way to make the existing structure work. The sticking point is that not only might the tuple we expected have been deleted, but someone could have put an unrelated tuple in its place. Are you confident that you can detect that and recover from it? If you're sure that brin_tuples_equal() is trustworthy for this purpose, then maybe we just have some run-of-the-mill bugs to find, like the off-the-end bug I spotted in brin_doupdate. There's apparently at least one more, but given the error message it must be something like not checking for a page to have turned into a revmap page. Shouldn't be too hard to find... regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers