Re: standby recovery fails (tablespace related) (tentative patch and discussion)

At Thu, 21 Jul 2022 13:25:05 +0200, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote in
> On 2022-Jul-21, Alvaro Herrera wrote:
>
> > Yeah, I think that would reduce cruft. I'm not sure this is more
> > against backpatching policy or less, compared to adding a separate
> > GUC just for this bugfix.
>
> cruft:
>
> {
> {"allow_recovery_tablespaces", PG_POSTMASTER, WAL_RECOVERY,
> gettext_noop("Continues recovery after finding invalid database directories."),
> gettext_noop("It is possible for tablespace drop to interfere with database creation "
> "so that WAL replay is forced to create fake database directories. "
> "These should have been dropped by the time recovery ends; "
> "but in case they aren't, this option lets recovery continue if they "
> "are present. Note that these directories must be removed manually afterwards."),
> GUC_NOT_IN_SAMPLE
> },
> &allow_recovery_tablespaces,
> false,
> NULL, NULL, NULL
> },
>
> This is not a very good explanation, but I don't know how to make it
> better.

It looks a bit too detailed. I crafted the following..

Recovery can create tentative in-place tablespace directories under
pg_tblspc/. They are assumed to be removed until reaching recovery
consistency, but otherwise PostgreSQL raises a PANIC-level error,
aborting the recovery. Setting allow_recovery_tablespaces to true
causes the system to allow such directories during normal
operation. In case those directories are left after reaching
consistency, that implies data loss and metadata inconsistency and may
cause failure of future tablespace creation.

Though, after writing this, I became to think that piggy-backing on
allow_in_place_tablespaces might be a bit different..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center