Re: Listen / Notify - what to do when the queue is full - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: Listen / Notify - what to do when the queue is full
Date
Msg-id 799900c92d357d98c40226fce46fb8de@biglumber.com
Whole thread Raw
In response to Re: Listen / Notify - what to do when the queue is full  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----                               
Hash: RIPEMD160                                                  

>> (4) drop *old* notifications if the queue is full.
>>                                                   
>> Since everyone has made the point that LISTEN is not meant to be a full
>> queueing system, I have no problem dropping notifications LRU-style.   
>                                                                         
> NO, NO, NO, a thousand times no!                                        

+1. Don't even think about going there. </me gives horrified shudder>

...
> even that was pretty hard.  There will now be a nonzero chance
> of transactions failing at commit because of queue full.  If the
> chance is large this will be an issue.  (Is it sane to wait for 
> the queue to be drained?)                                       

I think this chance will be pretty small - you need a *lot* of 
unread notifications before this edge case is reached, so I think
we can be pretty severe in our response, and put the responsibility
on cleanup on the user, rather than having the backend try to
move things around, cleanup the queue selectively, etc.

> BTW, did we discuss the issue of 2PC transactions versus notify?
> The current behavior of 2PC with notify is pretty cheesy and will
> become more so if we make this change --- you aren't really
> guaranteed that the notify will happen, even though the prepared
> transaction did commit.  I think it might be better to disallow
> NOTIFY inside a prepared xact.

That's a tough one. On the one hand, simply stating that NOTIFY and 2PC
don't play together in the docs would be a straightforward solution
(and not a bad one, as 2PC is already rare and delicate and should not
be used lightly). But what I really don't like the is the idea of a
notify that *may* work or may not - so let's keep it boolean: it either
works 100% of the time with 2PC, or doesn't at all. Should we throw
a warning or error if a client attempts to combine the two?

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200911190857
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAksFTxEACgkQvJuQZxSWSsjkiACfYeevKZ0QngZcZXUoTPP6wXh6
iOMAoLvkPlEV6ywGqyaaloqQrnoryILU
=rioB
-----END PGP SIGNATURE-----




pgsql-hackers by date:

Previous
From: Hitoshi Harada
Date:
Subject: Re: add more frame types in window functions (ROWS)
Next
From: Robert Haas
Date:
Subject: Re: Timezones (in 8.5?)