public inbox for [email protected]
help / color / mirror / Atom feedFrom: SATYANARAYANA NARLAPURAM <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: Andrey Borodin <[email protected]>
Cc: Bharath Rupireddy <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
Date: Tue, 29 Nov 2022 09:15:21 -0800
Message-ID: <CAHg+QDdz+7H8wuNk9A6nBFei46BWhBq1A37_O4kNmJpuSq+dUg@mail.gmail.com> (raw)
In-Reply-To: <CAHg+QDcw6er6maVHq5PGR2t7NePXMWD9Vih9TRE=8Z=LDxOE9w@mail.gmail.com>
References: <[email protected]>
<CALj2ACWPMYoPSC3t-9uW+0gqDUcJf1mLww6hHzo2V2AvE-Tu+w@mail.gmail.com>
<[email protected]>
<CALj2ACXmMWtpmuT-=v8F+Lk4QCbdkeN+yHKXeRGKFfjG96YbKA@mail.gmail.com>
<CALj2ACUO6oz-43ryqfMOVZ_Q-N10C5tkzKku12+QV02NnXsDrw@mail.gmail.com>
<[email protected]>
<CAAhFRxjFGSk-hVTjnpFwm1XBUcHL8Obugt=P+ixV5AD9H+Kkrw@mail.gmail.com>
<CAAhFRxgcBy-UCvyJ1ZZ1UKf4Owrx4J2X1F4tN_FD=fh5wZgdkw@mail.gmail.com>
<CALj2ACVG5KCoPD_5AF2_u07HuZe4ajaLWKycB6OBYsGuj67OhA@mail.gmail.com>
<CAHg+QDf9sMJ-r9JqFQTALRy8dX8Mr6SoFEvXx8V-Tto10VcFPA@mail.gmail.com>
<[email protected]>
<CAHg+QDcw6er6maVHq5PGR2t7NePXMWD9Vih9TRE=8Z=LDxOE9w@mail.gmail.com>
On Tue, Nov 29, 2022 at 8:42 AM SATYANARAYANA NARLAPURAM <
[email protected]> wrote:
>
>
> On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian <[email protected]> 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 <[email protected]> https://momjian.us
>> EDB https://enterprisedb.com
>>
>> Embrace your flaws. They make you human, rather than perfect,
>> which you will never be.
>>
>
view thread (37+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication
In-Reply-To: <CAHg+QDdz+7H8wuNk9A6nBFei46BWhBq1A37_O4kNmJpuSq+dUg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox