Re: Refactoring the checkpointer's fsync request queue
От | Robert Haas |
---|---|
Тема | Re: Refactoring the checkpointer's fsync request queue |
Дата | |
Msg-id | CA+TgmoZRNHDKSnG35mPufKKgVXSPAYrQo5nHhD_ZzBzg50cTAQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Refactoring the checkpointer's fsync request queue (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Refactoring the checkpointer's fsync request queue
|
Список | pgsql-hackers |
On Wed, Nov 14, 2018 at 4:49 PM Andres Freund <andres@anarazel.de> wrote: > On 2018-11-14 16:36:49 -0500, Robert Haas wrote: > > But how do you make reading that counter atomic with the open() itself? > > I don't see why it has to be. As long as the "fd generation" assignment > happens before fsync (and writes secondarily), there ought not to be any > further need for synchronizity? If the goal is to have the FD that is opened first end up in the checkpointer's table, grabbing a counter backwards does not achieve it, because there's a race. S1: open FD S2: open FD S2: local_counter = shared_counter++ S1: local_counter = shared_counter++ Now S1 was opened first but has a higher shared counter value than S2 which was opened later. Does that matter? Beats me! I just work here... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: