Re: WAL replay of truncate fails if the table was dropped

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WAL replay of truncate fails if the table was dropped
Дата
Msg-id 11732.1184954790@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WAL replay of truncate fails if the table was dropped  ("Simon Riggs" <simon@2ndquadrant.com>)
Список pgsql-bugs
"Simon Riggs" <simon@2ndquadrant.com> writes:
> If I understand this: the primary would be initialised yet the standby
> would remain uninitialised? I don't think that matters because the
> actual the data contents are still zero.

From a logical perspective the page is "empty" either way.  The only
behavioral difference I can think of is that the initialized page is a
candidate for insertion of new tuples, whereas on the slave it would not
be a candidate until after another VACUUM.  So the histories would
diverge faster once the slave comes alive.  As long as the slave is just
following WAL records and not making any decisions of its own, I can't
see a failure mode; but it looks like a potential weak spot for future
extensions (particularly, trying to allow slave servers to execute
queries).

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: WAL replay of truncate fails if the table was dropped
Следующее
От: "Walter Roeland"
Дата:
Сообщение: BUG #3476: description of root.crt/crl in documentation