Re: WAL replay of truncate fails if the table was dropped - Mailing list pgsql-bugs

From Tom Lane
Subject Re: WAL replay of truncate fails if the table was dropped
Date
Msg-id 11732.1184954790@sss.pgh.pa.us
Whole thread Raw
In response to Re: WAL replay of truncate fails if the table was dropped  ("Simon Riggs" <simon@2ndquadrant.com>)
List 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 by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: WAL replay of truncate fails if the table was dropped
Next
From: "Walter Roeland"
Date:
Subject: BUG #3476: description of root.crt/crl in documentation