From: | Nikhil Shetty <nikhil(dot)dba04(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: statement_timeout has no effect if sync standby is unavailable |
Date: | 2023-11-02 17:39:25 |
Message-ID: | CAFpL5VywKn-0_2qnSS=hUAnQx-ZRKZWDgyf81jzCPWD7cSN+EA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Got it but in my second scenario there was no sync standby
We froze the data mount point and ran queries and all of them were hung. It
is waiting for WalWrite - in this case, can it not timeout without
committing?
We used statement_timeout of 2s for testing
Thanks,
Nikhil
On Thu, 2 Nov 2023 at 21:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Nikhil Shetty <nikhil(dot)dba04(at)gmail(dot)com> writes:
> > I need to check the process state but statement_timeout should timeout
> such
> > queries, no?
>
> No, I don't think that should be the policy, and if it doesn't do so
> now I'm content to leave it like that. Once we have committed locally
> and started to wait for a sync standby, we are between a rock and a
> hard place: we can't back out the commit. If we were to allow a
> timeout error to occur, we'd have a choice of reporting that the
> commit failed (a lie) or that it succeeded (also a lie, given that
> the promise of sync commit is that we don't report commit until it's
> persisted on the standby too). Neither of these are preferable to
> ignoring the timeout.
>
> tl;dr: if your standby is not 100% reliable, enabling sync standby
> is a poor choice.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-11-02 17:42:37 | Re: How to _not_ save startup options in postmaster.opts? |
Previous Message | Sacha Kerres | 2023-11-02 17:39:16 | Re: How to _not_ save startup options in postmaster.opts? |