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 по дате отправления: