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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: Asim R P <apraveen(at)pivotal(dot)io>, Paul Guo <pguo(at)pivotal(dot)io>, Alexandra Wang <leiwang(at)pivotal(dot)io>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Date: 2020-01-10 00:22:45
Message-ID: 20200110002245.GA23694@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I looked at this a little while and was bothered by the perl changes; it
seems out of place to have RecursiveCopy be thinking about tablespaces,
which is way out of its league. So I rewrote that to use a callback:
the PostgresNode code passes a callback that's in charge to handle the
case of a symlink. Things look much more in place with that. I didn't
verify that all places that should use this are filled.

In 0002 I found adding a new function unnecessary: we can keep backwards
compat by checking 'ref' of the third argument. With that we don't have
to add a new function. (POD changes pending.)

I haven't reviewed 0003.

v8 of all these patches attached.

"git am" told me your 0001 was in unrecognized format. It applied fine
with "patch". I suggest that if you're going to submit a series with
commit messages and all, please use "git format-patch" with the same
"-v" argument (9 in this case) for all patches.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
v8-0001-Support-node-initialization-from-backup-with-tabl.patch text/x-diff 4.4 KB
v8-0002-Tests-to-replay-create-database-operation-on-stan.patch text/x-diff 9.9 KB
v8-0003-Fix-replay-of-create-database-records-on-standby.patch text/x-diff 12.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-01-10 00:27:42 Re: pgbench - use pg logging capabilities
Previous Message Michael Paquier 2020-01-10 00:06:24 Re: pgbench - use pg logging capabilities