[Bizgres-general] Transactional Statement Queuing - Queue Design 1

[Mark Kirkwood]

The first hurdle is to come up with a reasonable design for the queue 
mechanism itself.

1/ Queue Toy Implementation

The first thing to check is what a 'n concurrent but only m active' 
queue mechanism could look like. It is pretty trivial to implement via a 
sys V semaphore (see attached sem.c).


2/ Queue Using Postgres Built-in Machinery

This is where the work is :-). PG has three semaphore/locking
constructs:

- spinlocks [TAS]
- lightweight locks [LWLock]
- regular locks [LOCK]

The first can be ruled out immediately, as it is not suitable for 
anything other than very short waits. This leaves the lightweight and 
regular locks to consider.

My initial reading of the code gives the impression that the light
weight locks will do '1 holder, many waiters' (i.e. exclusive) or 'many
holders' (i.e. shared) types of access, but not 'several holders, many
waiters'. In addition the documentation implies that long wait
activities should not use lightweight locks (tho I can't actually see
any reason for that myself, as they wait on a semaphore).

Finally it looks to me like the number of lightweight locks is 
essentially fixed ( see NumLWLocks() ), which does not match our 
requirement for a variable number of queues.


This would seem to leave the regular locking mechanism as the one to use
(altho I have yet to see if it does 'several holders, many waiters'
either...).

Obviously a concern is that the regular locks may be a lot slower than
the lightweight ones, in that case I may have to look at modifying the
lightweight code or making another type of lock based on it.

Thoughts?

Mark


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sem.c
Url: http://pgfoundry.org/pipermail/bizgres-general/attachments/20060427/3cbb3454/attachment-0001.c