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

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, 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-15 11:59:43
Message-ID: dc7b844e1002150359y5c7bdd9bhcbeab40ba9493076@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Next set of questions
>
> * Will this work during Hot Standby now? The barrier was that it wrote
> to a table and so we could not allow that. ISTM this new version can and
> should work with Hot Standby. Can you test that and if so, remove the
> explicit barrier code and change tests and docs to enable it?

I have tested it already. The point where it currently fails is the
following line:

qe->xid = GetCurrentTransactionId();

We record the TransactionId (of the notifying transaction) in the
notification in order to later check if this transaction has committed
successfully or not. If you tell me how we can find this out in HS, we
might be done...

The reason why we are doing all this is because we fear that we can
not write the notifications to disk once we have committed to clog...
So we write them to disk before committing to clog and therefore need
to record the TransactionId.

> * We also discussed the idea of having a NOTIFY command that would work
> from Primary to Standby. All this would need is some code to WAL log the
> NOTIFY if not in Hot Standby and for some recovery code to send the
> NOTIFY to any listeners on the standby. I would suggest that would be an
> option on NOTIFY to WAL log the notification:
> e.g. NOTIFY me 'with_payload' FOR STANDBY ALSO;

What should happen if you wanted to replay a NOTIFY WAL record in the
standby but cannot write to the pg_notify/ directory?

> * Don't really like pg_listening() as a name. Perhaps pg_listening_to()
> or pg_listening_on() or pg_listening_for() or pg_listening_channels() or
> pg_listen_channels()

pg_listen_channels() sounds best to me but I leave this decision to a
native speaker.

> * I think it's confusing that pg_notify is both a data structure and a
> function. Suggest changing one of those to avoid issues in
> understanding. "Use pg_notify" might be confused by a DBA.

You are talking about the libpq datastructure PGnotify I suppose... I
don't see it overly confusing but I wouldn't object changing it. There
was a previous discussion about the name, see the last paragraph of
http://archives.postgresql.org/message-id/dc7b844e1002021510i4aaa879fy8bbdd003729d28da@mail.gmail.com

Joachim

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2010-02-15 12:01:46 Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Previous Message Greg Stark 2010-02-15 11:55:36 Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after