Re: NOTIFY in multi-statement PQexec() not sent outside of transaction

From: John Muehlhausen <jgm(at)jgm(dot)org>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: NOTIFY in multi-statement PQexec() not sent outside of transaction
Date: 2020-04-20 19:32:05
Message-ID: CACk8hr6qGF78Vo7i7+mvgXqy3AMoOXAkxbCMbGwxwNOf9dpw2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Wrapping the notify in a transaction does not fix it. Shouldn't the notify
be available as soon as the containing transaction is committed?

cur.execute(("begin; notify __test; commit; "
"begin; select pg_advisory_lock(7777); "
"select pg_advisory_unlock(7777); commit"))

On Mon, Apr 20, 2020 at 1:26 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Monday, April 20, 2020, John Muehlhausen <jgm(at)jgm(dot)org> wrote:
>
>>
>> # docs seem to indicate that an implied transaction
>> # will not exist if there is an explicit begin/commit?
>> cur.execute(("notify __test; "
>> "begin; select pg_advisory_lock(7777); "
>> "select pg_advisory_unlock(7777); commit"))
>>
>>
> A more comprehensive reading of the docs finds:
>
> “ If the BEGIN follows some statements that were executed as an implicit
> transaction block, those statements are not immediately committed; in
> effect, they are retroactively included into the new regular transaction
> block. “.
>
> David J.
>
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-04-20 19:42:00 Re: NOTIFY in multi-statement PQexec() not sent outside of transaction
Previous Message Tom Lane 2020-04-20 19:19:13 Re: BUG #16112: large, unexpected memory consumption