Re: POC: Cleaning up orphaned files using undo logs - Mailing list pgsql-hackers

From Robert Haas
Subject Re: POC: Cleaning up orphaned files using undo logs
Date
Msg-id CA+TgmoYaHnBx47bRHtD=5hpKSYGTKyJ1zaYdw-V-wwrN_UsjCg@mail.gmail.com
Whole thread Raw
In response to Re: POC: Cleaning up orphaned files using undo logs  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Jun 20, 2019 at 6:44 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> BTW, while looking at the code of UndoFetchRecord, I see some problem.
> There is a coding pattern like
> if()
> {
> }
> else
> {
>    LWLockAcquire()
>   ..
>   ..
> }
>
> LWLockRelease().
>
> I think this is not correct.

Independently of that problem, I think it's probably bad that we're
not maintaining the same shared memory state on the master and the
standby.  Doing the same check in one way on the master and in a
different way on the standby is a recipe for surprising and probably
bad behavior differences between master and standby servers.  Those
could be simple things like lock acquire/release not matching, but
they could also be things like performance or correctness differences
that only materialize under certain scenarios.

This is not the only place in the patch set where we have this kind of
thing, and I hate them all.  I don't exactly know what the solution
is, either, but I suspect it will involve either having the recovery
process do a more thorough job updating the shared memory state when
it does undo-related stuff, or running some of the undo-specific
processes on the standby just for the purpose of getting these updates
done.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Emre Hasegeli
Date:
Subject: Re: improve transparency of bitmap-only heap scans
Next
From: Tom Lane
Date:
Subject: Re: Disconnect from SPI manager on error