On Wed, 2002-07-03 at 22:43, Tom Lane wrote: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > On Wed, 2002-07-03 at 17:48, Tom Lane wrote: > >> That's why it's so important that the readers use a sharable lock. The > >> only thing they'd be locking out is some new writer trying to send (yet > >> another) notify. > > > But there must be some way to communicate the positions of read pointers > > of all backends for managing the free space, lest we are unable to know > > when the buffer is full. > > Right. But we play similar games already with the existing SI buffer, > to wit: > > Writers grab the controlling lock LW_EXCLUSIVE, thereby having sole > access; in this state it's safe for them to examine all the read > pointers as well as examine/update the write pointer (and of course > write data into the buffer itself). The furthest-back read pointer > limits what they can write.
It means a full seq scan over pointers ;) > Readers grab the controlling lock LW_SHARED, thereby ensuring there > is no writer (but there may be other readers). In this state they > may examine the write pointer (to see how much data there is) and > may examine and update their own read pointer. This is safe and > useful because no reader cares about any other's read pointer. OK. Now, how will we introduce transactional behaviour to this scheme ? It is easy to save transaction id with each notify message, but is there a quick way for backends to learn when these transactions commit/abort or if they have done either in the past ? Is there already a good common facility for that, or do I just need to examine some random tuples in hope of finding out ;) -------------- Hannu ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]