Thread

Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication

SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com> — 2022-11-29T17:15:21Z

On Tue, Nov 29, 2022 at 8:42 AM SATYANARAYANA NARLAPURAM <
satyanarlapuram@gmail.com> wrote:

>
>
> On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian <bruce@momjian.us> wrote:
>
>> 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?
>
>
> Yes, Change in synchronous_standby_names is expected in this situation.
> IMHO, blocking all the connections is not a recommended approach.
>

How about allowing superusers (they can still read locally committed data)
and users part of pg_monitor role?


>
>>
>> --
>>   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.
>>
>