From: | Joachim Wieland <joe(at)mcknight(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: LISTEN/NOTIFY and notification timing guarantees |
Date: | 2010-02-16 08:28:13 |
Message-ID: | dc7b844e1002160028s61b11591i3473935bd579cebd@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 16, 2010 at 6:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Another possibility is to force a ProcessIncomingNotifies scan to occur
> before we reach ReadyForQuery if we sent any notifies in the
> just-finished transaction --- but that won't help if there are
> uncommitted messages in front of ours.
What about dealing with self-notifies in memory? i.e. copy them into a
subcontext of TopMemoryContext in precommit and commit as usual. Then
as a first step in ProcessIncomingNotifies() deliver whatever is in
memory and then delete the context. While reading the queue, ignore
all self-notifies there. If we abort for some reason, delete the
context in AtAbort_Notify(). Would that work?
Joachim
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Ouhrabka | 2010-02-16 08:40:28 | Re: Problem with 8.4 stats collector high load |
Previous Message | Boszormenyi Zoltan | 2010-02-16 08:08:21 | Re: [GENERAL] libecpg versions and libecpg_compat |