Re: SimpleLruTruncate() mutual exclusion
От | Noah Misch |
---|---|
Тема | Re: SimpleLruTruncate() mutual exclusion |
Дата | |
Msg-id | 20191115145204.GA941210@rfd.leadboat.com обсуждение исходный текст |
Ответ на | Re: SimpleLruTruncate() mutual exclusion (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
On Mon, Nov 04, 2019 at 03:43:09PM -0800, Noah Misch wrote: > On Mon, Nov 04, 2019 at 03:26:35PM +1300, Thomas Munro wrote: > > On Thu, Aug 1, 2019 at 6:51 PM Noah Misch <noah@leadboat.com> wrote: > > > vac_truncate_clog() instance 1 starts, considers segment ABCD eligible to unlink > > > vac_truncate_clog() instance 2 starts, considers segment ABCD eligible to unlink > > > vac_truncate_clog() instance 1 unlinks segment ABCD > > > vac_truncate_clog() instance 1 calls SetTransactionIdLimit() > > > vac_truncate_clog() instance 1 finishes > > > some backend calls SimpleLruZeroPage(), creating segment ABCD > > > vac_truncate_clog() instance 2 unlinks segment ABCD > > > > > > Serializing vac_truncate_clog() fixes that. > > > > I've wondered before (in a -bugs thread[1] about unexplained pg_serial > > wraparound warnings) if we could map 64 bit xids to wide SLRU file > > names that never wrap around and make this class of problem go away. > > Unfortunately multixacts would need 64 bit support too... > > > > [1] https://www.postgresql.org/message-id/flat/CAEBTBzuS-01t12GGVD6qCezce8EFD8aZ1V%2Bo_3BZ%3DbuVLQBtRg%40mail.gmail.com > > That change sounds good to me. I do think $SUBJECT should move forward independent of that.
В списке pgsql-hackers по дате отправления: