Re: WAL replay failure after file truncation(?)

Tom Lane wrote:
> Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
>
>>>>[...] Is it sufficient to
>>>>remember just the relation and the block number or do we need the
>>>>contents a well?
>
>
>>I meant the contents of the WAL record, not the original block
>>contents. Anyway, I think it's not needed.
>
>
> Oh, I see. Yes, it might be worth hanging onto for debugging purposes.
> If we did get a report of such a failure, I'm sure we'd wish to know
> what sort of WAL record triggered it. One trusts there won't be so many
> that storing 'em all is a problem ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

I guess I am having the same problem here: I am just dealing with a
truncated table after a hard kill.
The symptoms are: The storage file of the table is missing while the
system tables can still see the table.
Looking at TRUNCATE (this is the only command which could potentially
have caused this problem in my case) it seems as if the system tables
are actually changed propery before the file on disk is truncated.

My question is: What happens if the system is killed inside
rebuild_relation or inside swap_relfilenodes which is called by
rebuild_relation?

many thanks and best regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/664/393 39 74
www.cybertec.at, www.postgresql.at