Re: Listen / Notify - what to do when the queue is full

In this version of the patch, there is a compiler warning:

async.c: In function ‘AtPrepare_Notify’:
async.c:593: warning: unused variable ‘p’

and also two trivial merge conflicts: an OID conflict for the functions
you added, and a trivial code conflict.

On Sun, 2010-02-07 at 17:32 +0100, Joachim Wieland wrote:
> On Wed, Feb 3, 2010 at 2:05 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > The original comment was a part of the NotifyStmt case, and I don't
> > think we can support NOTIFY issued on a standby system -- surely there's
> > no way for the standby to communicate the notification to the master.
> > Anyway, this is getting a little sidetracked; I don't think we need to
> > worry about HS right now.
>
> True but I was not talking about moving any notifications to different
> servers. Clients listening on one server should receive the
> notifications from NOTIFYs executed on this server, no matter if it is
> a standby or the master server.

I'm not sure I agree with that philosophy. If the driving use-case for
LISTEN/NOTIFY is cache invalidation, then a NOTIFY on the master should
make it to all listening backends on the slaves.

> This is still kind of an open item but it's an slru issue and should
> also be true for other functionality that uses slru queues.

I haven't found out anything new here.

> This I don't understand... If power goes out and we restart, we'd
> first put all notifications from the prepared transactions into the
> queue. We know that they fit because they have fit earlier as well (we
> wouldn't allow user connections until we have worked through all 2PC
> state files).
>

Ok, it appears you've thought the 2PC interaction through more than I
have. Even if we don't include it this time, I'm glad to hear that there
is a plan to do so. Feel free to include support if you have it ready,
but it's late in the CF so I don't want you to get sidetracked on that
issue.

> There was another problem that the slru files did not all get deleted
> at server restart, which is fixed now.

Good catch.

> Regarding the famous ASCII-restriction open item I have now realized
> what I haven't thought of previously: notifications are not
> transferred between databases, they always stay in one database. Since
> libpq does the conversion between server and client encoding, it is
> questionable if we really need to restrict this at all... But I am not
> an encoding expert so whoever feels like he can confirm or refute
> this, please speak up.

I would like to support encoded text, but I think there are other
problems. For instance, what if one server has a client_encoding that
doesn't support some of the glyphs being sent by the notifying backend?
Then we have a mess, because we can't deliver it.

I think we just have to say "ASCII only" here, because there's no
reasonable way to handle this, regardless of implementation. If the user
issues SELECT and the client_encoding can't support some of the glyphs,
we can throw an error. But for a notification? We just have no mechanism
for that.

Regards,
Jeff Davis