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

From Ashwin Agrawal
Subject Re: Avoiding Tablespace path collision for primary and standby
Date
Msg-id CALfoeivxo2OTi94mkY+vMRzah_Zw9PJJxV8Cj3atG+v-Oj7wJQ@mail.gmail.com
Whole thread Raw
In response to Re: Avoiding Tablespace path collision for primary and standby  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Avoiding Tablespace path collision for primary and standby
List pgsql-hackers

On Wed, Jun 20, 2018 at 9:39 AM Bruce Momjian <bruce@momjian.us> wrote:
On Fri, May 25, 2018 at 02:17:23PM -0700, Ashwin Agrawal wrote:
>
> On Fri, May 25, 2018 at 7:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>     Ashwin Agrawal <aagrawal@pivotal.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 ?

I didn't see anyone answer your question above.  We don't expect
micro-second replay, but clock skew, which Tom Lane mention, could make
it appear to be a micro-second replay.

Thanks Bruce for answering. Though I still don't see why clock skew is a problem here. As I think clock skew only happens across machines. On same machine why would it be an issue. Problem is only with same machine, different machines anyways paths don't collide so even if clock skew happens is not a problem. (I understand there may be reservations for putting timestamp in directory path, but clock skew argument is not clear.)

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: line numbers in error messages are off wrt debuggers
Next
From: Daniel Gustafsson
Date:
Subject: Re: PATCH: backtraces for error messages