t...@sss.pgh.pa.us (Tom Lane) writes:
> Merlin Moncure writes:
>> On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane wrote:
>>> 2. Add an extra lock to serialize writers to the queue, so that messages
>>> are guaranteed to be added to the queue in commit order. As long as
>
>> fwiw, I think you're defin
Merlin Moncure writes:
> On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane wrote:
>> 2. Add an extra lock to serialize writers to the queue, so that messages
>> are guaranteed to be added to the queue in commit order. As long as
> fwiw, I think you're definitely on the right track. IMO, any scenario
Jeff Davis writes:
> On Tue, 2010-02-16 at 10:38 -0500, Tom Lane wrote:
>> 2. Add an extra lock to serialize writers to the queue, so that messages
>> are guaranteed to be added to the queue in commit order.
> I assume this is a heavyweight lock, correct?
Yeah, that seems the easiest way to do i
On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane wrote:
> 2. Add an extra lock to serialize writers to the queue, so that messages
> are guaranteed to be added to the queue in commit order. As long as
fwiw, I think you're definitely on the right track. IMO, any scenario
where an issued notification e
On Tue, 2010-02-16 at 10:38 -0500, Tom Lane wrote:
> 2. Add an extra lock to serialize writers to the queue, so that messages
> are guaranteed to be added to the queue in commit order.
I assume this is a heavyweight lock, correct?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing l
Joachim Wieland writes:
> On Tue, Feb 16, 2010 at 1:31 PM, Kevin Grittner
> wrote:
>> Tom Lane wrote:
>>> We could adopt the historical policy of sending self-notifies
>>> pre-commit, but that doesn't seem tremendously appetizing from the
>>> standpoint of transactional integrity.
>>
>> But one
On Tue, Feb 16, 2010 at 1:31 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>> We could adopt the historical policy of sending self-notifies
>> pre-commit, but that doesn't seem tremendously appetizing from the
>> standpoint of transactional integrity.
>
> But one traditional aspect of transactional
Tom Lane wrote:
> We could adopt the historical policy of sending self-notifies
> pre-commit, but that doesn't seem tremendously appetizing from the
> standpoint of transactional integrity.
But one traditional aspect of transactional integrity is that a
transaction always sees *its own* uncomm
On Tue, Feb 16, 2010 at 6:20 AM, Tom Lane 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
I wrote:
> ...
> 3. It is possible for a backend's own self-notifies to not be delivered
> immediately after commit, if they are queued behind some other
> uncommitted transaction's messages. That wasn't possible before either.
> ... We could fix
> #3 by re-instituting the special code path that
Joachim Wieland writes:
> One question regarding #2: Is a client application able to tell
> whether or not it has received all notifications from one batch? i.e.
> does PQnotifies() return NULL only when the backend has sent over the
> complete batch of notifications or could it also return NULL w
On Mon, Feb 15, 2010 at 3:31 AM, Tom Lane wrote:
> I'm not sure how probable it is that applications might be coded in a
> way that relies on the properties lost according to point #2 or #3.
Your observations are all correct as far as I can tell.
One question regarding #2: Is a client applicatio
12 matches
Mail list logo
