Re: listen/notify argument (old topic revisited)

On Wed, 2002-07-03 at 22:43, Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)ee> 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