From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Ashwin Agrawal <aagrawal(at)pivotal(dot)io> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Avoiding Tablespace path collision for primary and standby |
Date: | 2018-05-26 02:10:52 |
Message-ID: | CAEepm=08dBFcydNo2NOOEA6X_CuYSze28FZ=-9tBViPaXRvOJg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 26, 2018 at 9:17 AM, Ashwin Agrawal <aagrawal(at)pivotal(dot)io> wrote:
> To generate uniqueness for the path between primary and standby need to use
> something which is not represented within database. So will be random to
> some degree. Like one can use PORT number of postmaster. As only need to
> generate unique path while creating link during CREATE TABLESPACE.
I also wondered about this when trying to figure out how to write a
TAP test for recovery testing with tablespaces, for my undo proposal.
I was starting to wonder about either allowing relative paths or
supporting some kind of variable in the tablespace path that could
then be set differently in each cluster's .conf.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-05-26 03:48:04 | Re: Avoiding Tablespace path collision for primary and standby |
Previous Message | Chapman Flack | 2018-05-26 02:09:25 | Re: SPI/backend equivalent of extended-query Describe(statement)? |