Re: GiST concurrency

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GiST concurrency
Date: 2005-06-21 13:42:43
Message-ID: 2049.1119361363@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
> Now I basically finished recovery for GiST (of course, it's need a hard testing)
> and go to concurrency. As it described in Kornaker, Mohan and Hellerstein's
> paper
> (http://www.sai.msu.su/~megera/postgres/gist/papers/concurrency/sigmod97-gist.pdf)
> it's need a way to get global LSN, in our case - XLogRecPtr of last changed
> page. As I understand, I can't use ProcLastRecPtr because it is one-process
> wide, I need value stored in shared memory.

If the method needs a truly global LSN, then it is broken --- the only
way you could have such a value and have it stay good long enough to do
anything with it is to block all other backends from inserting any new
WAL records. Which is the very antithesis of concurrency.

I think you probably misunderstood the paper. It looks to me like the
proposal in the paper is to use the LSN assigned to the WAL record that
represents a page split operation. Which you get from the XLogInsert
--- there's no need for an extra call.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2005-06-21 13:43:01 Re: [PATCHES] default database creation with initdb
Previous Message Bruno Wolff III 2005-06-21 13:34:36 Re: thousands comma numeric formatting in psql