Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
От | Bruce Momjian |
---|---|
Тема | Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication |
Дата | |
Msg-id | Y4YzWeRgDYOj5Rod@momjian.us обсуждение исходный текст |
Ответ на | Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication (SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>) |
Ответы |
Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication |
Список | pgsql-hackers |
On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM wrote: > 2. Process proc die immediately when a backend is waiting for sync > replication acknowledgement, as it does today, however, upon restart, > don't open up for business (don't accept ready-only connections) > unless the sync standbys have caught up. > > > Are you planning to block connections or queries to the database? It would be > good to allow connections and let them query the monitoring views but block the > queries until sync standby have caught up. Otherwise, this leaves a monitoring > hole. In cloud, I presume superusers are allowed to connect and monitor (end > customers are not the role members and can't query the data). The same can't be > true for all the installations. Could you please add more details on your > approach? I think ALTER SYSTEM should be allowed, particularly so you can modify synchronous_standby_names, no? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Embrace your flaws. They make you human, rather than perfect, which you will never be.
В списке pgsql-hackers по дате отправления: