From: | Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A thought on Index Organized Tables |
Date: | 2010-02-25 07:19:05 |
Message-ID: | 9362e74e1002242319w18d0524di21fd13ba5dabfc4f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> The WAL record of the heap insert/update/delete contains a flag
> indicating that the visibility map needs to be updated too. Thus no need
> for a separate WAL record.
>
>
Heikki,
Have you considered these cases?
a) The current WAL architecture makes sure that the WAL Log is written
before the actual page flush( i believe ). But you are changing that
architecture for Visibility maps. Visibility map might get flushed out
before the corresponding WAL gets written. I think you would then suggest
full page writes here
b) Say for a large table, you have multiple buffers of visibility map, then
there is a chance that one buffer gets flushed to the disk and the other
doesn't. If the WAL records are not in place, then this leads to a time
inconsistent visibility map.
c) If you are going to track all the WAL linked with a buffer of visibility
map, then you need to introduce another synchronization in the critical
path.
May be i am missing something? I am asking these questions only out of
curiosity.
Thanks,
Gokul.
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-02-25 07:31:45 | Re: Assertion failure in walreceiver |
Previous Message | Fujii Masao | 2010-02-25 03:02:18 | Re: Streaming replication and pg_xlogfile_name() |