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: | Postg토토 사이트 순위SQL |
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.
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 |