Re: SyncRepLock acquired exclusively in default configuration
От | Fujii Masao |
---|---|
Тема | Re: SyncRepLock acquired exclusively in default configuration |
Дата | |
Msg-id | 3273455e-acd6-fe2f-8136-8013e2a475b8@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: SyncRepLock acquired exclusively in default configuration (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: SyncRepLock acquired exclusively in default configuration
Re: SyncRepLock acquired exclusively in default configuration |
Список | pgsql-hackers |
On 2020/08/12 15:32, Masahiko Sawada wrote: > On Wed, 12 Aug 2020 at 14:06, Asim Praveen <pasim@vmware.com> wrote: >> >> >> >>> On 11-Aug-2020, at 8:57 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> >>> I think this gets to the root of the issue. If we check the flag >>> without a lock, we might see a slightly stale value. But, considering >>> that there's no particular amount of time within which configuration >>> changes are guaranteed to take effect, maybe that's OK. However, there >>> is one potential gotcha here: if the walsender declares the standby to >>> be synchronous, a user can see that, right? So maybe there's this >>> problem: a user sees that the standby is synchronous and expects a >>> transaction committing afterward to provoke a wait, but really it >>> doesn't. Now the user is unhappy, feeling that the system didn't >>> perform according to expectations. >> >> Yes, pg_stat_replication reports a standby in sync as soon as walsender updates priority of the standby to something otherthan 0. >> >> The potential gotcha referred above doesn’t seem too severe. What is the likelihood of someone setting synchronous_standby_namesGUC with either “*” or a standby name and then immediately promoting that standby? If the standbyis promoted before the checkpointer on master gets a chance to update sync_standbys_defined in shared memory, commitsmade during this interval on master may not make it to standby. Upon promotion, those commits may be lost. > > I think that if the standby is quite behind the primary and in case of > the primary crashes, the likelihood of losing commits might get > higher. The user can see the standby became synchronous standby via > pg_stat_replication but commit completes without a wait because the > checkpointer doesn't update sync_standbys_defined yet. If the primary > crashes before standby catching up and the user does failover, the > committed transaction will be lost, even though the user expects that > transaction commit has been replicated to the standby synchronously. > And this can happen even without the patch, right? I think you're right. This issue can happen even without the patch. Maybe we should not mark the standby as "sync" whenever sync_standbys_defined is false even if synchronous_standby_names is actually set and walsenders have already detect that? Or we need more aggressive approach; make the checkpointer update sync_standby_priority values of all the walsenders? ISTM that the latter looks overkill... Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Rahila SyedДата:
Сообщение: Re: More tests with USING INDEX replident and dropped indexes