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

Поиск
Список
Период
Сортировка
От Joachim Wieland
Тема Re: Listen / Notify - what to do when the queue is full
Дата
Msg-id dc7b844e1002150359y5c7bdd9bhcbeab40ba9493076@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Listen / Notify - what to do when the queue is full  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Listen / Notify - what to do when the queue is full  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Listen / Notify - what to do when the queue is full  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Listen / Notify - what to do when the queue is full  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список pgsql-hackers
On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs <simon@2ndquadrant.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after