Re: commit_delay, siblings - Mailing list pgsql-hackers

From Qingqing Zhou
Subject Re: commit_delay, siblings
Date
Msg-id d9dqv9$2eg3$1@news.hub.org
Whole thread Raw
In response to commit_delay, siblings  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes
>
>
> together with some kind of IPC to waken backends once xlog was flushed
> past the point they needed.  (Designing that is the hard part.)
>

I think we could use ProcSendSignal()/ProcWaitForSignal() mechanism to cope
with the problem, because they won't lost any wake-ups.

So there will be a MaxBackend sized shared memory arrary with each cell is a
 XLogRecPtr recptr;  /* record request */ bool status; /* execution results */

structure. The initial value of the cell is <(0, 0), *doesn't matter*>.
Also, we need a spinlock to protect "recptr" value since it is not a
sig_atomic_t value.

A backend requests a xlogflush will do: spinlock_acquire;   fill in the XLogRecPtr value; spinlock_release;
ProcWaitForSignal();
After waken up, it will examine the "status" value and acts accordingly.


The xlog-writer is the only one who does real xlog write in postmaster mode.
It does not work in standalone mode or recovery mode. It works based on a
periodical loop + waken up when the xlog buffer is 70% full. A cancel/die
interrupts could happen during wait, so we will plug in a
ProcCancelWaitForSignal() at AbortTransaction() or error handling in
xlog-writer loop. There also could be various error conditions in its life.
Any error happened during xlogflush will be PANIC. Some small errors in the
loop will be hopefully recoverable. If everything is good, it would scan the
arrary, for each cell do:
 spinlock_acquire;    make a local copy of XLogRecPtr; spinlock_release;
 if (recptr is (0, 0))    nothing to do;    /* no request at all */
 if (recptr is satisfied)    set XLogRecPtr to (0, 0);    status = true;    /* successfully done */
ProcSendSignal(targetbackendid);else    check if the recptr is passed the end of xlog file, if so      set XLogRecPtr
to(0, 0);      set status = false;    /* bad request */      ProcSendSignal(targetbackendid);
 

I am not sure how to check bad recptr. Currently we could do this by
comparing request and real flush point after xlogwrite(request). However,
seems this is not a solution for the xlog writer case.

Regards,
Qingqing





pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: GiST rtree logic is not right
Next
From: Richard Huxton
Date:
Subject: Re: Strange logic for partial index proving