Re: Taking into account syncrep position in flush_lsn reported by apply worker
От | Amit Kapila |
---|---|
Тема | Re: Taking into account syncrep position in flush_lsn reported by apply worker |
Дата | |
Msg-id | CAA4eK1L9WetnoZJe5n+w4A6499hZUEFqTF9QPYPkeSSX5205+Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Taking into account syncrep position in flush_lsn reported by apply worker (Arseny Sher <ars@neon.tech>) |
Ответы |
Re: Taking into account syncrep position in flush_lsn reported by apply worker
|
Список | pgsql-hackers |
On Mon, Aug 12, 2024 at 3:43 PM Arseny Sher <ars@neon.tech> wrote: > > Sorry for the poor formatting of the message above, this should be better: > > Hey. Currently synchronous_commit is disabled for logical apply worker > on the ground that reported flush_lsn includes only locally flushed data > so slot (publisher) preserves everything higher than this, and so in > case of subscriber restart no data is lost. However, imagine that > subscriber is made highly available by standby to which synchronous > replication is enabled. Then reported flush_lsn is ignorant of this > synchronous replication progress, and in case of failover data loss may > occur if subscriber managed to ack flush_lsn ahead of syncrep. > Won't the same can be achieved by enabling the synchronous_commit parameter for a subscription? -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: