Horton

Re: when the startup process doesn't

Stephen Frost <sfrost@snowman.net>

View thread View on postgr.es
From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>, Magnus Hagander <magnus@hagander.net>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-04-21T21:04:18Z
Lists: pgsql-hackers 
Greetings,

On Wed, Apr 21, 2021 at 17:01 Andres Freund <andres@anarazel.de> wrote:

> On 2021-04-21 16:55:28 -0400, Tom Lane wrote:
> > My concern about it was not at all about performance, but that every time
> > you write it is a new opportunity for the filesystem to lose or corrupt
> > the data.
>
> We already do, sometimes very frequent, control file updates on standbys
> to update minRecoveryLSN. I don't recall reports of that causing
> corruption issues. So I'd not be too concerned about that aspect?


Or perhaps we should consider having multiple copies..?  Though I
definitely have seen missing WAL causing difficult to realize / detect
corruption more than corrupt pg_control files...

Thanks,

Stephen

>

Commits

  1. Un-revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

  2. Revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

  3. Disable STARTUP_PROGRESS_TIMEOUT in standby mode.

  4. Fix race condition in startup progress reporting.

  5. Report progress of startup operations that take a long time.

  6. Add enable_timeout_every() to fire the same timeout repeatedly.