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.
>
>
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 |