| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nikhil Shetty <nikhil(dot)dba04(at)gmail(dot)com> |
| 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 16:08:53 |
| Message-ID: | 3123996.1698941333@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
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 | Ron | 2023-11-02 17:01:00 | How to _not_ save startup options in postmaster.opts? |
| Previous Message | Nikhil Shetty | 2023-11-02 15:55:02 | Re: statement_timeout has no effect if sync standby is unavailable |