Re: Avoiding Tablespace path collision for primary and standby - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Avoiding Tablespace path collision for primary and standby
Date
Msg-id CAMsr+YE06WjM-js2k5SFZyDLdYvXnjM7c=Bu3hh3wxPXXSWiRA@mail.gmail.com
Whole thread Raw
In response to Re: Avoiding Tablespace path collision for primary and standby  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


On Thu., 21 Jun. 2018, 04:30 Tom Lane, <tgl@sss.pgh.pa.us> wrote:
Ashwin Agrawal <aagrawal@pivotal.io> writes:
> Okay just bouncing another approach, how about generating UUID for a
> postgres instance during initdb and pg_basebackup ?

There's no uuid generation code in core postgres, for excellent reasons
(lack of portability and lack of failure modes are the main objections).
This is not different in any meaningful way from the proposal to use
timestamps, except for being more complicated.

A v4 UUID is just 128 random bits and some simple formatting. So I really don't understand your concerns about UUID generation.

That said, it can already be handled with tablespace maps in pg_basebackup. And any new scheme would need to happen in pg_basebackup too, because it must happen before the tablespace are copied and thr replica is first started.

I don't see a big concern with some pg_basebackup --gen-unique-tablespaces option or the like.

UUID would be better than timestamp due to the skew issues discussed upthread. But personally I'd just take a label argument. pg_basebackup --tablespace-prefix or the like.

For non pg_basebackup uses you have to solve it yourself anyway. Pg doesn't know if it's just been started as a copy, after all, and it's too late to move tablespace then even if we'd do such a thing.

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: XML/XPath issues: text/CDATA in XMLTABLE, XPath evaluated withwrong context
Next
From: Amit Langote
Date:
Subject: Re: partition -> partitioned