"Simon Riggs" <[EMAIL PROTECTED]> 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
b
On Fri, 2007-07-20 at 11:38 -0400, Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Interestingly, this bug isn't triggered unless there's an already empty
> > or uninitialized page at the end of table. If vacuum removes the last
> > tuple from the page, that will be WAL-logged
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Interestingly, this bug isn't triggered unless there's an already empty
> or uninitialized page at the end of table. If vacuum removes the last
> tuple from the page, that will be WAL-logged and replay of that calls
> smgrcreate.
Yeah, I tried other
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> mdtruncate throws an error if the relation file doesn't exist.
>
> Interesting corner case. The proposed fix seems not very consistent
> with the way we handle comparable cases elsewhere, though. In general,
> md.c will cut some
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> mdtruncate throws an error if the relation file doesn't exist.
Interesting corner case. The proposed fix seems not very consistent
with the way we handle comparable cases elsewhere, though. In general,
md.c will cut some slack when InRecovery if a
mdtruncate throws an error if the relation file doesn't exist. However,
that's not an error condition if the relation was dropped later.
Non-existent file should be treated the same as an already truncated
file; we now end up with an unrecoverable database.
This bug seems to be present from 8.0 on
