Skip site navigation (1) Skip section navigation (2)

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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Arnaud Betremieux <arnaud(dot)betremieux(at)keyconsulting(dot)fr>
Subject: Re: Listen / Notify - what to do when the queue is full
Date: 2010-02-09 06:13:39
Message-ID: 1265696019.2739.39.camel@jdavis-laptop (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Andrew McNamaraDate: 2010-02-09 06:53:54
Subject: Re: Confusion over Python drivers
Previous:From: Marko TiikkajaDate: 2010-02-09 05:32:44
Subject: Re: Writeable CTEs and empty relations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group