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

From: Paul Guo <pguo(at)pivotal(dot)io>
To: Asim R P <apraveen(at)pivotal(dot)io>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date: 2019-04-22 04:36:43
Message-ID: CAEET0ZGpUrMGUzfyzVF9FuSq+zb=QovYa2cvyRnDOTvZ5vXxTw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Please see my replies inline. Thanks.

On Fri, Apr 19, 2019 at 12:38 PM Asim R P <apraveen(at)pivotal(dot)io> wrote:

> On Wed, Apr 17, 2019 at 1:27 PM Paul Guo <pguo(at)pivotal(dot)io> wrote:
> >
> > create db with tablespace
> > drop database
> > drop tablespace.
>
> Essentially, that sequence of operations causes crash recovery to fail
> if the "drop tablespace" transaction was committed before crashing.
> This is a bug in crash recovery in general and should be reproducible
> without configuring a standby. Is that right?
>

No. In general, checkpoint is done for drop_db/create_db/drop_tablespace on
master.
That makes the file/directory update-to-date if I understand the related
code correctly.
For standby, checkpoint redo does not ensure that.

>
> Your patch creates missing directories in the destination. Don't we
> need to create the tablespace symlink under pg_tblspc/? I would
>

'create db with tablespace' redo log does not include the tablespace real
directory information.
Yes, we could add in it into the xlog, but that seems to be an overdesign.

> prefer extending the invalid page mechanism to deal with this, as
> suggested by Ashwin off-list. It will allow us to avoid creating

directories and files only to remove them shortly afterwards when the
> drop database and drop tablespace records are replayed.
>
>
'invalid page' mechanism seems to be more proper for missing pages of a
file. For
missing directories, we could, of course, hack to use that (e.g. reading
any page of
a relfile in that database) to make sure the tablespace create code
(without symlink)
safer (It assumes those directories will be deleted soon).

More feedback about all of the previous discussed solutions is welcome.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-04-22 05:37:08 Re: Runtime pruning problem
Previous Message Corey Huinker 2019-04-22 03:52:45 Re: [PATCH v1] Add \echo_stderr to psql