> On 30 Jan 2023, at 06:55, Bharath Rupireddy
> wrote:
> I started to spend time on this feature again. Thanks all for your
> comments so far.
Since there hasn't been any updates for the past six months, and the patch
hasn't applied for a few months, I am marking this returned with feedback
On Tue, Nov 29, 2022 at 10:45 PM SATYANARAYANA NARLAPURAM
wrote:
>
> On Tue, Nov 29, 2022 at 8:42 AM SATYANARAYANA NARLAPURAM
> wrote:
>>
>> On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian wrote:
>>>
>>> On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM wrote:
>>> > 2.
On Tue, Nov 29, 2022 at 11:20 AM SATYANARAYANA NARLAPURAM <
satyanarlapu...@gmail.com> wrote:
>
>
> On Tue, Nov 29, 2022 at 10:52 AM Andrey Borodin
> wrote:
>
>> On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian wrote:
>> >
>> > On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM
>>
On Tue, Nov 29, 2022 at 10:52 AM Andrey Borodin
wrote:
> On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian 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
On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian 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
On Tue, Nov 29, 2022 at 8:42 AM SATYANARAYANA NARLAPURAM <
satyanarlapu...@gmail.com> wrote:
>
>
> On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian wrote:
>
>> On Tue, Nov 29, 2022 at 08:14:10AM -0800, SATYANARAYANA NARLAPURAM wrote:
>> > 2. Process proc die immediately when a backend is
On Tue, Nov 29, 2022 at 8:29 AM Bruce Momjian 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
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)
>
On Sun, Nov 27, 2022 at 10:33 PM Bharath Rupireddy <
bharath.rupireddyforpostg...@gmail.com> wrote:
> On Mon, Nov 28, 2022 at 12:57 AM Andrey Borodin
> wrote:
> >
> > Some funny stuff. If a user tries to cancel a non-replicated transaction
> > Azure Postgres will answer: "user requested cancel
On Mon, Nov 28, 2022 at 01:31:39PM -0800, Andrey Borodin wrote:
> On Mon, Nov 28, 2022 at 12:59 PM Bruce Momjian wrote:
> >
> > You can prepare a patch, but it unlikely to get much interest until you
> > get agreement on what the behavior should be.
>
> We discussed the approach on 2020's
On Mon, Nov 28, 2022 at 12:59 PM Bruce Momjian wrote:
>
> You can prepare a patch, but it unlikely to get much interest until you
> get agreement on what the behavior should be.
We discussed the approach on 2020's Unconference [0]. And there kind
of was an agreement.
Then I made a presentation
On Mon, Nov 28, 2022 at 12:03:06PM +0530, Bharath Rupireddy wrote:
> Thanks for verifying the behaviour. And many thanks for an off-list chat.
>
> FWIW, I'm planning to prepare a patch as per the below idea which is
> something similar to the initial proposal in this thread. Meanwhile,
> thoughts
On Sun, Nov 27, 2022 at 11:26:50AM -0800, Andrey Borodin wrote:
> Some funny stuff. If a user tries to cancel a non-replicated transaction
> Azure Postgres will answer: "user requested cancel while waiting for
> synchronous replication ack. The COMMIT record has already flushed to
> WAL locally
On Mon, Nov 28, 2022 at 12:57 AM Andrey Borodin wrote:
>
> Some funny stuff. If a user tries to cancel a non-replicated transaction
> Azure Postgres will answer: "user requested cancel while waiting for
> synchronous replication ack. The COMMIT record has already flushed to
> WAL locally and
On Tue, Nov 8, 2022 at 9:06 PM Andrey Borodin wrote:
>
> On Thu, Sep 29, 2022 at 3:53 PM Bruce Momjian wrote:
> >
> > So, what happens when an insufficient number of synchronous replicas
> > reply?
>
> It's a failover.
>
> > Sessions hang because the synchronous behavior cannot be
> >
On Thu, Sep 29, 2022 at 3:53 PM Bruce Momjian wrote:
>
> So, what happens when an insufficient number of synchronous replicas
> reply?
It's a failover.
> Sessions hang because the synchronous behavior cannot be
> guaranteed. We then _allow_ query cancel so the user or administrator
> can get
On Thu, Oct 6, 2022 at 01:33:33PM +0530, Bharath Rupireddy wrote:
> On Thu, Oct 6, 2022 at 2:30 AM Bruce Momjian wrote:
> >
> > As I highlighted above, by default you notify the administrator that a
> > sychronous replica is not responding and then ignore it. If it becomes
> > responsive again,
On Thu, Oct 6, 2022 at 2:30 AM Bruce Momjian wrote:
>
> As I highlighted above, by default you notify the administrator that a
> sychronous replica is not responding and then ignore it. If it becomes
> responsive again, you notify the administrator again and add it back as
> a sychronous
On Sat, Oct 1, 2022 at 06:59:26AM +0530, Bharath Rupireddy wrote:
> > I have always felt this has to be done at the server level, meaning when
> > a synchronous_standby_names replica is not responding after a certain
> > timeout, the administrator must be notified by calling a shell command
> >
On Fri, Sep 30, 2022 at 4:23 AM Bruce Momjian wrote:
>
> I don't think this patch is going in the right direction, and I think we
> need to step back to see why.
Thanks a lot Bruce for providing insights.
> First, let's see how synchronous replication works. Each backend waits
> for one or
On Tue, Sep 27, 2022 at 06:52:21PM +0530, Bharath Rupireddy wrote:
> On Tue, Aug 9, 2022 at 2:16 PM Bharath Rupireddy
> wrote:
> >
> > I've explained the problem with the current HA setup with synchronous
> > replication upthread at [1]. Let me reiterate it here once again.
> >
> > When a query
On Tue, Aug 9, 2022 at 2:16 PM Bharath Rupireddy
wrote:
>
> I've explained the problem with the current HA setup with synchronous
> replication upthread at [1]. Let me reiterate it here once again.
>
> When a query is cancelled (a simple stroke of CTRL+C or
> pg_cancel_backend() call) while the
On Tue, Aug 9, 2022 at 12:42 PM Kyotaro Horiguchi
wrote:
>
> > Can you please explain more about your idea, I may be missing something?
>
> (I'm not sure I understand the requirements here..)
I've explained the problem with the current HA setup with synchronous
replication upthread at [1]. Let
At Mon, 8 Aug 2022 19:13:25 +0530, Bharath Rupireddy
wrote in
> On Fri, Aug 5, 2022 at 8:19 AM Kyotaro Horiguchi
> wrote:
> >
> > At Tue, 26 Apr 2022 08:26:59 +0200, Laurenz Albe
> > wrote in
> > > While this may mitigate the problem, I don't think it will deal with
> > > all the cases which
On Fri, Aug 5, 2022 at 8:19 AM Kyotaro Horiguchi
wrote:
>
> At Tue, 26 Apr 2022 08:26:59 +0200, Laurenz Albe
> wrote in
> > While this may mitigate the problem, I don't think it will deal with
> > all the cases which could cause a transaction to end up committed locally,
> > but not on the
At Tue, 26 Apr 2022 08:26:59 +0200, Laurenz Albe
wrote in
> While this may mitigate the problem, I don't think it will deal with
> all the cases which could cause a transaction to end up committed locally,
> but not on the synchronous standby. I think that only using the full
> power of
On Thu, Aug 4, 2022 at 1:42 PM Bharath Rupireddy
wrote:
>
> On Mon, Jul 25, 2022 at 4:20 PM Andrey Borodin wrote:
> >
> > > 25 июля 2022 г., в 14:29, Bharath Rupireddy
> > > написал(а):
> > >
> > > Hm, after thinking for a while, I tend to agree with the above
> > > approach - meaning, query
On Mon, Jul 25, 2022 at 4:20 PM Andrey Borodin wrote:
>
> > 25 июля 2022 г., в 14:29, Bharath Rupireddy
> > написал(а):
> >
> > Hm, after thinking for a while, I tend to agree with the above
> > approach - meaning, query cancel interrupt processing can completely
> > be disabled in
> 25 июля 2022 г., в 14:29, Bharath Rupireddy
> написал(а):
>
> Hm, after thinking for a while, I tend to agree with the above
> approach - meaning, query cancel interrupt processing can completely
> be disabled in SyncRepWaitForLSN() and process proc die interrupt
> immediately, this
On Tue, May 10, 2022 at 5:55 PM Andrey Borodin wrote:
>
> > 10 мая 2022 г., в 12:59, Bharath Rupireddy
> > написал(а):
> >
> > If okay, I can make the GUC behave this way - value 0 existing
> > behaviour i.e. no wait for sync repl ack, just process query cancels
> > and proc die interrupts
On Tue, May 10, 2022 at 5:55 PM Andrey Borodin wrote:
>
> > 10 мая 2022 г., в 12:59, Bharath Rupireddy
> > написал(а):
> >
> > If okay, I can make the GUC behave this way - value 0 existing
> > behaviour i.e. no wait for sync repl ack, just process query cancels
> > and proc die interrupts
> 10 мая 2022 г., в 12:59, Bharath Rupireddy
> написал(а):
>
> If okay, I can make the GUC behave this way - value 0 existing
> behaviour i.e. no wait for sync repl ack, just process query cancels
> and proc die interrupts immediately; value -1 wait unboundedly for the
> ack; value > 0 wait
On Tue, May 10, 2022 at 1:18 PM Dilip Kumar wrote:
>
> On Mon, May 9, 2022 at 4:39 PM Andrey Borodin wrote:
>
> > > On 9 May 2022, at 14:44, Dilip Kumar wrote:
> > >
> > > IMHO, making it wait for some amount of time, based on GUC is not a
> > > complete solution. It is just a hack to avoid
On Mon, May 9, 2022 at 4:39 PM Andrey Borodin wrote:
> > On 9 May 2022, at 14:44, Dilip Kumar wrote:
> >
> > IMHO, making it wait for some amount of time, based on GUC is not a
> > complete solution. It is just a hack to avoid the problem in some
> > cases.
>
> Disallowing cancelation of
> On 9 May 2022, at 14:20, Bharath Rupireddy
> wrote:
>
> On Tue, Apr 26, 2022 at 11:57 AM Laurenz Albe
> wrote:
>>
>> While this may mitigate the problem, I don't think it will deal with
>> all the cases which could cause a transaction to end up committed locally,
>> but not on the
On Mon, May 9, 2022 at 2:50 PM Bharath Rupireddy
wrote:
>
> On Tue, Apr 26, 2022 at 11:57 AM Laurenz Albe
> wrote:
> >
> > On Mon, 2022-04-25 at 19:51 +0530, Bharath Rupireddy wrote:
> > > With synchronous replication typically all the transactions (txns)
> > > first locally get committed, then
On Tue, Apr 26, 2022 at 11:57 AM Laurenz Albe wrote:
>
> On Mon, 2022-04-25 at 19:51 +0530, Bharath Rupireddy wrote:
> > With synchronous replication typically all the transactions (txns)
> > first locally get committed, then streamed to the sync standbys and
> > the backend that generated the
> 25 апр. 2022 г., в 21:48, Nathan Bossart
> написал(а):
>
> I'm personally in
> favor of just adding a GUC that can be enabled to block canceling
> synchronous replication waits
+1. I think it's the only option to provide quorum commit guarantees.
Best regards, Andrey Borodin.
On Mon, 2022-04-25 at 19:51 +0530, Bharath Rupireddy wrote:
> With synchronous replication typically all the transactions (txns)
> first locally get committed, then streamed to the sync standbys and
> the backend that generated the transaction will wait for ack from sync
> standbys. While waiting
On Mon, Apr 25, 2022 at 07:51:03PM +0530, Bharath Rupireddy wrote:
> With synchronous replication typically all the transactions (txns)
> first locally get committed, then streamed to the sync standbys and
> the backend that generated the transaction will wait for ack from sync
> standbys. While
Hi,
With synchronous replication typically all the transactions (txns)
first locally get committed, then streamed to the sync standbys and
the backend that generated the transaction will wait for ack from sync
standbys. While waiting for ack, it may happen that the query or the
txn gets canceled
41 matches
Mail list logo
