Re: Report: race conditions in WAL replay routines

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Sun, Feb 5, 2012 at 7:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> * seq_redo() has the same disease, since we allow SELECT * FROM
>> sequences.

> Why do we do that?

It's the only existing way to obtain the parameters of a sequence.
Even if we felt like inventing a different API for doing that, it'd take
years to change every client that knows about this.

>> * Not exactly a race condition, but: tblspc_redo does ereport(ERROR)
>> if it fails to clean out tablespace directories. This seems to me to be
>> the height of folly, especially when the failure is more or less an
>> expected case. If the error occurs the database is dead in the water,
>> because that error is actually a PANIC and will recur on subsequent
>> restart attempts. Therefore there is no way to recover short of manual
>> intervention to clean out the non-empty directory. And why are we
>> pulling the fire alarm like this? Well, uh, it's because we might fail
>> to recover some disk space in the dropped tablespace. Seems to me to be
>> a lot better to just elog(LOG) and move on. This is quite analogous to
>> the case of failing to unlink a file after commit --- wasting disk space
>> might be bad, but it's very much the lesser evil compared to this.

> If the sysadmin is managing the db properly then this shouldn't ever
> happen - the only cause is if the tablespace being dropped is being
> used as a temp tablespace on the standby.

Right, but that is an expected/foreseeable situation. It should not
lead to a dead-and-unrestartable database.

> If you just LOG, when exactly would we get rid of the tablespace?

The tablespace *is* gone, or at least its catalog entries are. All we
are trying to do here is release some underlying disk space. It's
exactly analogous to the case where we drop a table and then find (post
commit) that unlinking the disk file fails for some weird reason.
We've done what we can to clean the disk space and should just let it
go --- there is no risk to database integrity in leaving some files
behind, so killing the server is a huge overreaction.

regards, tom lane