Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints
От | Tom Lane |
---|---|
Тема | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Дата | |
Msg-id | 3696676.1659658886@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On August 4, 2022 4:11:13 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> [pile^2] Also, what is the rationale for locking the target buffer >> but not the source buffer? That seems pretty hard to justify from >> here, even granting the assumption that we don't expect any other >> processes to be interested in these buffers (which I don't grant, >> because checkpointer). > I'm not arguing it's good or should stay that way, but it's probably okayish that checkpointer / bgwriter have access,given that they will never modify buffers. They just take a lock to prevent concurrent modifications, which RelationCopyStorageUsingBufferhopefully doesn't do. I'm not arguing that it's actively broken today --- but AFAIR, every other access to a shared buffer takes a buffer lock. It does not seem to me to be very future-proof for this code to decide it's exempt from that rule, without so much as a comment justifying it. Furthermore, what's the gain? We aren't expecting contention here, I think. If we were, then it probably *would* be actively broken. regards, tom lane
В списке pgsql-hackers по дате отправления: