On Tue, Feb 16, 2010 at 6:20 AM, Tom Lane t...@sss.pgh.pa.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
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*
On Tue, Feb 16, 2010 at 1:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Joachim Wieland j...@mcknight.de writes:
On Tue, Feb 16, 2010 at 1:31 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
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
On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us 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
Jeff Davis pg...@j-davis.com 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
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us 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
t...@sss.pgh.pa.us (Tom Lane) writes:
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Feb 16, 2010 at 10:38 AM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Feb 15, 2010 at 3:31 AM, Tom Lane t...@sss.pgh.pa.us 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
Joachim Wieland j...@mcknight.de 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
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
The proposed new implementation of listen/notify works by shoving all
of a transaction's outgoing notifies into the global queue during
pre-commit, then sending PROCSIG_NOTIFY_INTERRUPT to listening backends
post-commit. When a listening backend scans the queue, if it hits a
message from a
13 matches
Mail list logo
