Re: Regression test PANICs with master-standby setup on same machine

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, michael(at)paquier(dot)xyz, kuntalghosh(dot)2007(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Regression test PANICs with master-standby setup on same machine
Date: 2019-04-24 17:02:03
Message-ID: 16630.1556125323@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-24 10:13:09 -0400, Tom Lane wrote:
>> I can't say that I like 0001 at all. It adds a bunch of complication and
>> new failure modes (e.g., having to panic on chdir failure) in order to do
>> what exactly? I've not been following the thread closely, but the
>> original problem is surely just a dont-do-that misconfiguration. I also
>> suspect that this is assuming way too much about the semantics of getcwd
>> --- some filesystem configurations may have funny situations like multiple
>> paths to the same place.

> I'm not at all defending the conrete patch. But I think allowing
> relative paths to tablespaces would solve a whole lot of practical
> problems, while not meaningfully increasing failure modes.

I'm not against allowing relative tablespace paths. But I did not like
the chdir and getcwd-semantics hazards --- why do we have to buy into
all that to allow relative paths?

I think it would likely be sufficient to state plainly in the docs
that a relative path had better point outside $PGDATA, and maybe
have some *simple* tests on the canonicalized form of the path to
prevent obvious mistakes. Going further than that is likely to add
more problems than it removes.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-04-24 17:43:57 Re: Thoughts on nbtree with logical/varwidth table identifiers, v12 on-disk representation
Previous Message Stephen Frost 2019-04-24 16:57:36 Re: block-level incremental backup