Horton

Re: B-tree parent pointer and checkpoints

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

View thread
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2010-11-02T14:40:59Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Rewrite the GiST insertion logic so that we don't need the post-recovery

On 02.11.2010 16:30, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> I think we can fix this by requiring that any multi-WAL-record actions
>> that are in-progress when a checkpoint starts (at the REDO-pointer) must
>> finish before the checkpoint record is written.
>
> What happens if someone wants to start a new split while the checkpoint
> is hanging fire?

You mean after CreateCheckPoint has determined the redo pointer, but 
before it has written the checkpoint record? The new split can go ahead, 
and the checkpoint doesn't need care about it. Recovery will start at 
the redo pointer, so it will see the split record, and will know to 
finish the incomplete split if necessary.

The logic is the same as with inCommit. Checkpoint will fetch the list 
of in-progress splits some time after determining the redo-pointer. It 
will then wait until all of those splits have finished. Any new splits 
that begin after fetching the list don't affect the checkpoint.

inCommit can't be used as is, because it's tied to the Xid, but 
something similar should work.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com