Hi, Alexander! On Mon, Feb 5, 2024 at 7:00 PM Alexander Lakhin <exclus...@gmail.com> wrote: > 05.02.2024 02:51, Alexander Korotkov wrote: > > > Usage of heap_inplace_update() seems appropriate for me here. It > > avoids trouble with both TOAST and row-level locks. Alexander, could > > you please recheck this fixes the problem. > > I've re-tested the last problematic scenario and can confirm that the fix > works for it (though it still doesn't prevent the autovacuum issue (with > 4b885d01 reverted)), but using heap_inplace_update() was considered risky > in a recent discussion: > https://www.postgresql.org/message-id/1596629.1698435146%40sss.pgh.pa.us > So maybe it's worth to postpone such a fix till that discussion is > finished or to look for another approach...
Thank you for pointing this out. I don't think there is a particular problem with this use case for the following reasons. 1) Race conditions over pg_database.dathasloginevt are protected with lock tag. 2) Unsetting pg_database.dathasloginevt of old tuple version shouldn't cause a problem. The next tuple version will be updated by further connections. However, I agree that it's better to wait for the discussion you've pointed out before introducing another use case of heap_inplace_update(). ------ Regards, Alexander Korotkov
