Re: Avoiding Tablespace path collision for primary and standby

From: Ashwin Agrawal <aagrawal(at)pivotal(dot)io>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoiding Tablespace path collision for primary and standby
Date: 2018-05-25 21:17:23
Message-ID: CALfoeitcxqXykOhcjACZF7j47zKHHGC9ObPM=5yZNJK+TDjXHw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 25, 2018 at 7:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Ashwin Agrawal <aagrawal(at)pivotal(dot)io> writes:
> > Proposing to create directory with timestamp at time of creating
> tablespace
> > and create symbolic link to it instead.
>
> I'm skeptical that this solves your problem. What happens when the CREATE
> TABLESPACE command is replicated to the standby with sub-second delay?
>

I thought timestamps have micro-second precision. Are we expecting
tabelspace to be created, wal logged, streamed, and replayed on mirror in
micro-second ?

Clock skew is another reason to doubt that timestamp == unique identifier,
> which is essentially what you're assuming here.
>

On same machine is what we care about generating uniqueness. Different
machines the problem doesn't exist anyways, so doesn't matter clock is
skewed or not.

>
> Even if we fixed that, the general idea of including a quasi-random
> component in the directory name seems like it would have a lot of
> unpleasant side effects in terms of reproduceability, testability, etc.
>

Hmm.. aren't to some degree we currently as well create directories/files
with quasi-random numbers like tablespace-oids, database-oids and
relfilenodes, etc..

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2018-05-25 21:20:13 Re: Redesigning the executor (async, JIT, memory efficiency)
Previous Message Tom Lane 2018-05-25 21:17:12 Re: Performance regression with PostgreSQL 11 and partitioning