A thought on Index Organized Tables
in [PgSql]
|
Prev: [COMMITTERS] pgsql: Oops, don't forget to rewind the directory before scanning it to
Next: Time travel on the buildfarm
From: Gokulakannan Somasundaram on 25 Feb 2010 06:57 > The replay of the heap insert/update/delete record updates the > visibility map. > > So are you planning to make that section, which writes the xlog and updates the visibility map inside a PANIC section right?
From: Gokulakannan Somasundaram on 25 Feb 2010 07:08 > The replay of the heap insert/update/delete record updates the > visibility map. > > Say a checkpoint has occured in between and flushed the dirty pages into disk, while the updater waits to update the visibility map. Now there will be no replay for the insert/update/delete right?
From: Heikki Linnakangas on 25 Feb 2010 06:38 Gokulakannan Somasundaram wrote: > OK. Say a session doing the update, which is the fist update on the page, > resets the PD_ALL_VISIBLE and just before updating the visibility map > crashes. The subsequent inserts/updates/deletes, will see the PD_ALL_VISIBLE > flag cleared and never care to update the visibility map, but actually it > would have created tuples in index and table. The replay of the heap insert/update/delete record updates the visibility map. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 25 Feb 2010 07:13 Gokulakannan Somasundaram wrote: >> The replay of the heap insert/update/delete record updates the >> visibility map. >> > So are you planning to make that section, which writes the xlog and updates > the visibility map inside a PANIC section right? The xlog record is already written in a critical section. Yeah, perhaps the critical section needs to be extended to cover the visibility map updates. The indexes haven't been changed at that point yet, so an index-only scan still produces the right result, but a subsequent update would fail to update the visibility map because the flag on the heap page was already cleared. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 25 Feb 2010 07:18
Gokulakannan Somasundaram wrote: > Say a checkpoint has occured in between and flushed the dirty pages into > disk, while the updater waits to update the visibility map. Now there will > be no replay for the insert/update/delete right? Yeah, good catch, that could happen. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |