Re: Avoiding Tablespace path collision for primary and standby

Поиск
Список
Период
Сортировка
От Ashwin Agrawal
Тема Re: Avoiding Tablespace path collision for primary and standby
Дата
Msg-id CALfoeivxo2OTi94mkY+vMRzah_Zw9PJJxV8Cj3atG+v-Oj7wJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoiding Tablespace path collision for primary and standby  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Avoiding Tablespace path collision for primary and standby  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: line numbers in error messages are off wrt debuggers
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: PATCH: backtraces for error messages