Postgres Pro
Downloads
Home   >   mailing lists

Thread: GiST concurrency

GiST concurrency

From
Teodor Sigaev
Date:
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. So, may I add method to xlog.c like 
this:

/* * The returning recptr is the beginning of the current record to fill. * This value is already stored as LSN for
changeddata pages. */
 

XLogRecPtr
GetCurrentRecPtr(void) {        XLogCtlInsert *Insert = &XLogCtl->Insert;        XLogRecPtr      RecPtr;
        LWLockAcquire(WALInsertLock, LW_SHARED);        INSERT_RECPTR(RecPtr, Insert, Insert->curridx);
LWLockRelease(WALInsertLock);
        return RecPtr;
}




-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/

Re: GiST concurrency

From
Tom Lane
Date:
Teodor Sigaev <teodor@sigaev.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

Re: GiST concurrency

From
Teodor Sigaev
Date:
> 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.
> 
Global LSN needs to recognize page split produced another process by search 
algorithm, no more.


> 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.

You partially right, I don't read it with care chaper 10.1 last paragraph :(
<quotation>
To alleviate the traffic on this high-frequency counter (LSN - teodor), 
descending operations can memorize the node's LSN instead.
</quotation>

So, value of global LSN isn't needed.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/