| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Cc: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: Add GoAway protocol message for graceful but fast server shutdown/switchover |
| Date: | 2026-03-24 22:21:19 |
| Message-ID: | CAN4CZFPYS4iDCK3oYs3zp77K50ra6C=Hvg5-ymt9KR0OFmuGQA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
+ if (!goaway_reported && PQgoAwayReceived(pset.db))
+ {
+ pg_log_info("Server sent GoAway, requesting disconnect when convenient.");
+ goaway_reported = true;
+ }
Shouldn't this variable be reset in pqDropServerData?
+ It is possible for NoticeResponse, ParameterStatus and GoAway
messages to be
interspersed between CopyData messages; frontends must handle these cases,
The patch currently doesn't actually do this, did you add this as
future proofing?
> I thought some more about this, but ultimately, the payloads you suggest
> only seem useful if a client has something inbetween "disconnect hard
> now" and "disconnect when the connection is unused"
Couldn't a client optimize the reconnect time if it knows about the
deadline? If it knows that it still has 10 minutes before the server
kicks it out, it might choose to finish a 3-4 minute task, reconnect,
and then continue.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2026-03-24 22:32:17 | Re: Adding REPACK [concurrently] |
| Previous Message | Zsolt Parragi | 2026-03-24 22:11:01 | Re: [Patch] New pg_stat_tablespace view |