Re: smsd, postgresql and large numbers of messages - bugs?

[drbob]

On Sat, 26 Mar 2011 19:38:22 +0000, drbob wrote:

> 
> Perhaps a better solution would be to move the BEGIN..COMMIT and SELECT
> FOR UPDATE into the for loop?
> 
> I'd appreciate comments from others before I attempt to tackle these
> issues with at patch - please tell me if you concur with my analysis or
> if I've got something wrong.
> 

Further to my precious post I think that multiple instances of smsd are 
still pointless as long as smsd is issuing a select for update on all the 
pending rows. An issue will arise as decscribed here:

http://stackoverflow.com/questions/389541/select-unlocked-row-in-postgresql

Perhaps better would be to select all the unprocessed rows (without the 
FOR UPDATE), then within the for loop that iterates over all the 
unprocessed items issue a SELECT FOR UPDATE for the individual message row 
being dealt with at that time (with the NOWAIT option so we can move on to 
the next message if it's already locked). We'd also need to recheck the 
processed attribut in case another instance of smsd already got to that 
row.

I believe this would allow multiple instances of smsd to work concurrently 
on a large message queue.

Again, any comments welcome.