Tom Lane wrote:
Manfred Koizar [EMAIL PROTECTED] 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.
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
My question is: What happens if the system is killed inside
rebuild_relation or inside swap_relfilenodes which is called by
rebuild_relation?
Nothing at all, because the system catalog updates aren't committed yet,
and we
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
My question is: What happens if the system is killed inside
rebuild_relation or inside swap_relfilenodes which is called by
rebuild_relation?
Nothing at all, because the system catalog updates aren't
On Wed, 2005-05-25 at 21:24 +0200, Manfred Koizar wrote:
WAL replay does not apply changes to nonexistent blocks,
but it keeps a list (hash table, file, whatever) of those blocks.
When a truncate WAL record is found, all entries for blocks affected
by the truncation are removed from the list.
On Wed, 25 May 2005 18:19:19 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
but it keeps a list (hash table, file, whatever) of those blocks.
[...] Is it sufficient to
remember just the relation and the block number or do we need the
contents a well?
We don't *have* the contents ... that's exactly
Manfred Koizar [EMAIL PROTECTED] 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
We've seen two recent reports:
http://archives.postgresql.org/pgsql-admin/2005-04/msg8.php
http://archives.postgresql.org/pgsql-general/2005-05/msg01143.php
of postmaster restart failing because the WAL contains a reference
to a page that no longer exists.
I can think of a couple of possible
Tom Lane wrote:
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter because they'll be truncated again later in the
On Wed, 25 May 2005 11:02:11 -0400, Tom Lane [EMAIL PROTECTED]
wrote:
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter
Manfred Koizar [EMAIL PROTECTED] writes:
Another idea: WAL replay does not apply changes to nonexistent blocks,
but it keeps a list (hash table, file, whatever) of those blocks.
When a truncate WAL record is found, all entries for blocks affected
by the truncation are removed from the list.
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter because they'll be truncated again later in the
replay sequence. This
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Plan B is for WAL replay to always be willing to extend the file to
whatever record number is mentioned in the log, even though this
may require inventing the contents of empty pages; we trust that their
contents won't matter because they'll be
12 matches
Mail list logo
