From: | Laurent Birtz <laurent(dot)birtz(at)kryptiva(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: LISTEN/NOTIFY race condition? |
Date: | 2008-03-05 16:44:57 |
Message-ID: | 47CECE09.10306@kryptiva.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Tom Lane wrote:
> Laurent Birtz <laurent(dot)birtz(at)kryptiva(dot)com> writes:
>
>> From the observed sequence of events, it would appear that the event
>> thread inserts a tuple in the pg_listener table BEFORE the command thread
>> actually commits the transaction. However, when this transaction commits,
>> Postgres does not actually find the event thread's tuple in this table.
>>
>
> I'm wondering exactly when you commit the LISTEN? The command thread
> can't see the pg_listener tuple until it's committed ...
>
I'm executing the LISTEN statement outside a transaction block.
I presume Postgres implicitly adds the BEGIN and COMMIT
statements in that case?
Just to be clear, the SELECT statement that retrieve new events is
also executed outside a transaction block.
Thanks for the help,
Laurent Birtz
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-03-05 16:56:44 | Re: Re: [BUGS] BUG #3965: UNIQUE constraint fails on long column values |
Previous Message | Phil Frost | 2008-03-05 16:32:57 | Re: Re: [BUGS] BUG #3965: UNIQUE constraint fails on long column values |