On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
We could probably fake this on the Hot Standby in the following way:
We introduce a commit record for every notifying transaction and write
it into the queue itself. So right before writing
On 2/18/10 9:58 AM, Simon Riggs wrote:
I thought a bit more about this and don't really understand why we need
an xid at all. When we discussed this before the role of a NOTIFY was to
remind us to refresh a cache, not as a way of delivering a transactional
payload. If the cache refresh use
On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
We could probably fake this on the Hot Standby in the following way:
We introduce a commit record for every notifying
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
I thought a bit more about this and don't really understand why we need
an xid at all. When we discussed this before the role of a NOTIFY was to
remind us to refresh a cache,
On Tue, Feb 16, 2010 at 11:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
[ listen/notify patch ]
I found a number of implementation problems having to do with wraparound
behavior and error recovery. I think they're all fixed, but any
remaining bugs are
Joachim Wieland j...@mcknight.de writes:
While I can see a lot of improvements over my version, I think the
logic in asyncQueueProcessPageEntries() needs to be reordered:
Hmmm ... I was intending to cover the case of a failure in
TransactionIdDidCommit too, but I can see it will take a bit more
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
* We also discussed the idea of having a NOTIFY command that
would work from Primary to Standby.
Just curious, what's a use case for this?
- --
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key:
On Tue, 2010-02-16 at 16:02 +, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
* We also discussed the idea of having a NOTIFY command that
would work from Primary to Standby.
Just curious, what's a use case for this?
If you have some kind of cache
Joachim Wieland j...@mcknight.de writes:
[ listen/notify patch ]
Applied after rather a lot of hacking.
Aside from the issues previously raised, I changed the NOTIFY syntax to
include a comma between channel name and payload. The submitted syntax
with no comma looked odd to me, and it would
Simon Riggs si...@2ndquadrant.com writes:
* Don't really like pg_listening() as a name. Perhaps pg_listening_to()
or pg_listening_on() or pg_listening_for() or pg_listening_channels() or
pg_listen_channels()
BTW, I used pg_listening_channels() for that.
* I think it's confusing that
On Sun, 2010-02-14 at 17:22 +0100, Joachim Wieland wrote:
New patch attached, thanks for the review.
Next set of questions
* Will this work during Hot Standby now? The barrier was that it wrote
to a table and so we could not allow that. ISTM this new version can and
should work with Hot
On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs si...@2ndquadrant.com wrote:
Next set of questions
* Will this work during Hot Standby now? The barrier was that it wrote
to a table and so we could not allow that. ISTM this new version can and
should work with Hot Standby. Can you test that and
On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
* I think it's confusing that pg_notify is both a data structure and
a
function. Suggest changing one of those to avoid issues in
understanding. Use pg_notify might be confused by a DBA.
You are talking about the libpq
On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
On Sun, Feb 14, 2010 at 11:44 PM, Simon Riggs si...@2ndquadrant.com wrote:
Next set of questions
* Will this work during Hot Standby now? The barrier was that it wrote
to a table and so we could not allow that. ISTM this new
On Mon, Feb 15, 2010 at 1:48 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-02-15 at 12:59 +0100, Joachim Wieland wrote:
I have tested it already. The point where it currently fails is the
following line:
qe-xid = GetCurrentTransactionId();
That's a shame. So it will never
Joachim Wieland j...@mcknight.de writes:
We could probably fake this on the Hot Standby in the following way:
We introduce a commit record for every notifying transaction and write
it into the queue itself. So right before writing anything else, we
write an entry which informs readers that
On Sun, 2010-02-14 at 22:44 +, Simon Riggs wrote:
* We also discussed the idea of having a NOTIFY command that would work
from Primary to Standby. All this would need is some code to WAL log the
NOTIFY if not in Hot Standby and for some recovery code to send the
NOTIFY to any listeners on
On Thu, 2010-02-11 at 00:52 +0100, Joachim Wieland wrote:
On Mon, Feb 8, 2010 at 5:16 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
These are the on-disk notifications, right? It seems to me a bit
wasteful to store channel name always as NAMEDATALEN bytes. Can we
truncate it at
On Sun, 2010-02-14 at 17:22 +0100, Joachim Wieland wrote:
* There is no mention of what to do with pg_notify at checkpoint.
Look
at how pg_subtrans handles this. Should pg_notify do the same?
Actually we don't care... We even hope that the pg_notify pages are
not flushed at all.
Joachim Wieland j...@mcknight.de writes:
+ #define ERRCODE_TOO_MANY_ENTRIESMAKE_SQLSTATE('5','4',
'0','3','1')
Do you have any evidence that there is actually a DB2 error code
matching this, or is this errcode just invented? The one page
Google finds doesn't list it:
On Mon, 2010-02-08 at 22:13 -0800, Jeff Davis wrote:
I would like to support encoded text, but I think there are other
problems. For instance, what if one server has a client_encoding that
doesn't support some of the glyphs being sent by the notifying backend?
Then we have a mess, because we
Jeff Davis pg...@j-davis.com writes:
Looking at the documentation, it appears that all of the server
encodings represent 7-bit ascii characters using the same 7-bit ascii
representation. Is that true?
Correct. We only support ASCII-superset encodings, both for frontend
and backend.
Limiting
On Tue, Feb 9, 2010 at 4:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Davis pg...@j-davis.com writes:
Looking at the documentation, it appears that all of the server
encodings represent 7-bit ascii characters using the same 7-bit ascii
representation. Is that true?
Correct. We only
On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote:
Limiting NOTIFY payloads to 7-bit would definitely avoid the issue.
The question is if that's more of a pain than a benefit.
I don't see any alternative. If one backend sends a NOTIFY payload that
contains a non-ASCII character, there's a risk
Jeff Davis wrote:
On Tue, 2010-02-09 at 16:51 -0500, Tom Lane wrote:
Limiting NOTIFY payloads to 7-bit would definitely avoid the issue.
The question is if that's more of a pain than a benefit.
I don't see any alternative. If one backend sends a NOTIFY payload that
Wouldn't binary payloads
On Tue, 2010-02-09 at 19:02 -0500, Andrew Chernow wrote:
Wouldn't binary payloads be an alternative? NOTE: I may have missed this
discussion. Sorry if it has already been covered.
The Notify struct has a char * field, which can't hold embedded NULL
bytes, so it can't really be binary. But it
Jeff Davis wrote:
Also, the query starts out as text, so we need a way to interpret the
text in an encoding-independent way.
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64
Andrew Dunstan and...@dunslane.net writes:
Jeff Davis wrote:
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64 or hex encoded string could
possibly meet the need in the first
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Jeff Davis wrote:
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM. If we
want something more that ASCII then a base64 or hex encoded string could
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Jeff Davis wrote:
So, I think ASCII is the natural choice here.
It's not worth hanging up this facility over this issue, ISTM.
If we want something more that ASCII then a base64 or hex
encoded string
Alvaro Herrera alvhe...@commandprompt.com writes:
Andrew Dunstan wrote:
True. It's a workaround, but I think it's acceptable at this stage.
We need to get some experience with this facility before we can
refine it.
Hmm? If we decide now that it's not going to have encoding conversion,
we
Joachim Wieland wrote:
+ typedef struct AsyncQueueEntry
+ {
+ /*
+ * this record has the maximal length, but usually we limit it to
+ * AsyncQueueEntryEmptySize + strlen(payload).
+ */
+ Sizelength;
+ Oid dboid;
+
In this version of the patch, there is a compiler warning:
async.c: In function ‘AtPrepare_Notify’:
async.c:593: warning: unused variable ‘p’
and also two trivial merge conflicts: an OID conflict for the functions
you added, and a trivial code conflict.
On Sun, 2010-02-07 at 17:32 +0100,
On Wed, Feb 3, 2010 at 4:34 AM, Joachim Wieland j...@mcknight.de wrote:
On Wed, Feb 3, 2010 at 2:05 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, very well spotted... Actually the same is true for LISTEN... I
have reworked the patch to do the changes to listenChannels only in
the post-commit
On Sun, 2010-02-07 at 00:18 -0500, Robert Haas wrote:
Jeff, do you think this patch is ready for committer? If so, please
mark it as such on commitfest.postgresql.org - otherwise, please
clarify what you think the action items are.
I'll post an update tomorrow.
Regards,
Jeff Davis
On Wed, Feb 3, 2010 at 2:05 AM, Jeff Davis pg...@j-davis.com wrote:
Thanks, very well spotted... Actually the same is true for LISTEN... I
have reworked the patch to do the changes to listenChannels only in
the post-commit functions.
I'm worried that this creates the opposite problem: that a
On Wed, 2010-02-03 at 00:10 +0100, Joachim Wieland wrote:
I admit that it was not clear what I meant. The comment should only
address LISTEN / NOTIFY on the standby server. Do you see any problems
allowing it?
The original comment was a part of the NotifyStmt case, and I don't
think we can
Comments:
* In standard_ProcessUtility(), case NotifyStmt, you add a comment:
/* XXX the new listen/notify version can be enabled
* for Hot Standby */
but I don't think that's correct. We may be able to support LISTEN
on the standby, but not NOTIFY (right?). I don't think we
On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis pg...@j-davis.com wrote:
Here's the problem as I see it:
You are writing a lot of true facts but I miss to find a real
problem... What exactly do you see as a problem?
The only time you are writing problem is in this paragraph:
However, there's
On Thu, 2010-01-21 at 10:14 +0100, Joachim Wieland wrote:
On Thu, Jan 21, 2010 at 3:06 AM, Jeff Davis pg...@j-davis.com wrote:
Here's the problem as I see it:
You are writing a lot of true facts but I miss to find a real
problem... What exactly do you see as a problem?
I worded that in a
On Wed, Jan 20, 2010 at 1:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I guess Joachim is trying to provide a similar guarantee for the new
implementation, but I'm not clear on why it would require locking.
The new implementation is broadcast and ISTM it shouldn't require the
modifying
Joachim Wieland j...@mcknight.de writes:
On Wed, Jan 20, 2010 at 1:05 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I guess Joachim is trying to provide a similar guarantee for the new
implementation, but I'm not clear on why it would require locking.
It is rather about a listening backend seeing a
On Wed, Jan 20, 2010 at 5:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In that case I think you've way overcomplicated matters. Just deliver
the notification. We don't really care if the listener gets additional
notifications; the only really bad case would be if it failed to get an
event that
Joachim Wieland j...@mcknight.de writes:
Okay, what about unprocessed notifications in the queue and a backend
executing UNLISTEN: can we assume that it is not interested in
notifications anymore once it executes UNLISTEN and discard all of
them even though there might be notifications that
On Wed, 2010-01-20 at 15:54 -0500, Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
Okay, what about unprocessed notifications in the queue and a backend
executing UNLISTEN: can we assume that it is not interested in
notifications anymore once it executes UNLISTEN and discard all of
On Wed, Jan 20, 2010 at 11:08 PM, Jeff Davis pg...@j-davis.com wrote:
Yes. That is the case with the existing implementation as well, no?
We don't consider sending notifies until transaction end, so anything
that commits during the xact in which you UNLISTEN will get dropped.
Only if the
Jeff Davis pg...@j-davis.com writes:
On Wed, 2010-01-20 at 15:54 -0500, Tom Lane wrote:
Yes. That is the case with the existing implementation as well, no?
We don't consider sending notifies until transaction end, so anything
that commits during the xact in which you UNLISTEN will get
On Tue, 2010-01-19 at 19:24 -0500, Tom Lane wrote:
(I'm still
wondering if we couldn't do without the lock altogether though.)
Here's the problem as I see it:
If we insert the notifications into the queue before actually recording
the commit, there's a window in between where another backend
Hi Jeff,
thanks a lot for your review. I will reply to your review again in
detail but I'd like to answer your two main questions already now.
On Tue, Jan 19, 2010 at 8:08 AM, Jeff Davis pg...@j-davis.com wrote:
* AsyncCommitOrderLock
I believe this needs a re-think. What is the real purpose
Regarding the send_notify function, I have been working on it and have a
patch (attached) that applies on top of Joachim's.
It introduces a send_notify SQL function that calls the Async_Notify C
function.
It's pretty straightforward and will need to be refined to take into
account the
On Wed, 2009-12-09 at 11:43 +0100, Joachim Wieland wrote:
Examples:
Backend 1:Backend 2:
transaction starts
NOTIFY foo;
commit starts
transaction starts
LISTEN foo;
commit
Jeff Davis pg...@j-davis.com writes:
How does the existing notification mechanism solve this problem? Is it
really a problem? Why would Backend2 expect to receive the notification?
The intended way to use LISTEN/NOTIFY for status tracking is
1. LISTEN foo; (and commit the listen)
On Tue, 2010-01-19 at 19:05 -0500, Tom Lane wrote:
I guess Joachim is trying to provide a similar guarantee for the new
implementation, but I'm not clear on why it would require locking.
The new implementation is broadcast and ISTM it shouldn't require the
modifying transaction to know which
Jeff Davis pg...@j-davis.com writes:
I was also worried about holding multiple LWLocks at once -- is such
practice generally avoided in the rest of the code?
It's allowed but remember that there is no deadlock detection in lwlock.c.
You must be very certain that there is only one possible order
On Tue, 2010-01-19 at 19:24 -0500, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
I was also worried about holding multiple LWLocks at once -- is such
practice generally avoided in the rest of the code?
It's allowed but remember that there is no deadlock detection in lwlock.c.
You
Initial comments:
* compiler warnings
ipci.c: In function ‘CreateSharedMemoryAndSemaphores’:
ipci.c:228: warning: implicit declaration of function ‘AsyncShmemInit’
* 2PC
Adds complexity, and I didn't see any clear, easy solution after
reading the thread. I don't see this as a showstopper, so
A use case : use NOTIFY in a rule to send the primary key of a row that
has been updated (for instance to manage a cache).
This requires a patch on top of this one, and it really is a separate
concern, but I thought I'd give the use case anyway, since I believe it
is relevant to the issues
Arnaud Betremieux arnaud.betremi...@keyconsulting.fr writes:
3) My use case : NOTIFY channel 'pay'||'load' (actually NOTIFY
channel 'table_name#'||OLD.id)
4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads
WHERE ...)
I'm working on a proof of concept patch to
Arnaud Betremieux wrote:
A use case : use NOTIFY in a rule to send the primary key of a row that
has been updated (for instance to manage a cache).
This requires a patch on top of this one, and it really is a separate
concern, but I thought I'd give the use case anyway, since I believe it
is
On Mon, Jan 11, 2010 at 8:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm working on a proof of concept patch to use Joachim's new notify
function to introduce case 3. I think this means going through the
planner and executor, so I might as well do case 4 as well.
It would be a lot less work
On 11/01/2010 14:25, Tom Lane wrote:
Arnaud Betremieuxarnaud.betremi...@keyconsulting.fr writes:
3) My use case : NOTIFY channel 'pay'||'load' (actually NOTIFY
channel 'table_name#'||OLD.id)
4) Taken one step further : NOTIFY channel (SELECT payload FROM payloads
WHERE ...)
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
- do we need to limit the payload to pure ASCII ? I think yes, we need
to. I also think we need to reject other payloads with elog(ERROR...).
...[snip other followups]
On the one hand, I don't see the problem with ASCII here - the
payload
On mån, 2010-01-11 at 04:05 +, Greg Sabino Mullane wrote:
On the one hand, I don't see the problem with ASCII here - the
payload is meant as a quick shorthand convenience, not a literal payload
of important information.
Is it not? The notify name itself is already a quick shorthand
On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland j...@mcknight.de wrote:
- do we need to limit the payload to pure ASCII ? I think yes, we need
to. I also think we need to reject other payloads with elog(ERROR...).
Just noticed this...don't you mean UTF8? Are we going to force non
English
Merlin Moncure wrote:
On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland j...@mcknight.de wrote:
- do we need to limit the payload to pure ASCII ? I think yes, we need
to. I also think we need to reject other payloads with elog(ERROR...).
Just noticed this...don't you mean UTF8? Are we going to
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland j...@mcknight.de wrote:
- do we need to limit the payload to pure ASCII ? I think yes, we need
to. I also think we need to reject other payloads with elog(ERROR...).
Just noticed this...don't you mean
On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Jan 8, 2010 at 7:48 AM, Joachim Wieland j...@mcknight.de wrote:
- do we need to limit the payload to pure ASCII ? I think yes, we need
to. I also think we need to reject other
Andrew Chernow wrote:
conversion problems in some circumstances - what about bytea (or why
_do_ we have to limit this to something?).
I agree with bytea. Zero conversions and the most flexible. Payload
encoding/format should be decided by the user.
yeah that is exactly why I think they
conversion problems in some circumstances - what about bytea (or why
_do_ we have to limit this to something?).
I agree with bytea. Zero conversions and the most flexible. Payload
encoding/format should be decided by the user.
--
Andrew Chernow
eSilo, LLC
every bit counts
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, he meant ASCII. Otherwise we're going to have to deal with encoding
conversion issues.
That seems pretty awkward...instead of forcing an ancient, useless to
90% of the world
On Fri, Jan 8, 2010 at 4:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Fri, Jan 8, 2010 at 1:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, he meant ASCII. Otherwise we're going to have to deal with encoding
conversion issues.
That seems pretty
On Wed, Dec 9, 2009 at 5:43 AM, Joachim Wieland j...@mcknight.de wrote:
Hi,
On Mon, Dec 7, 2009 at 5:38 AM, Greg Smith g...@2ndquadrant.com wrote:
JI'm going to mark this one returned with feedback, and I
do hope that work continues on this patch so it's early in the queue for the
final
On Thu, 2010-01-07 at 13:40 -0500, Robert Haas wrote:
Joachim - This no longer applies - please rebase, repost, and add a
link to the new version to the commitfest app.
Jeff - Do you want to continue reviewing this for the next CommitFest,
or hand off to another reviewer?
Sure, I'll review
Jeff Davis wrote:
On Mon, 2009-11-30 at 14:14 +0100, Joachim Wieland wrote:
I have a new version that deals with this problem but I need to clean
it up a bit. I am planning to post it this week.
Are planning to send a new version soon?
As it is, we're 12 days from the end of this
On Mon, 2009-11-30 at 14:14 +0100, Joachim Wieland wrote:
I have a new version that deals with this problem but I need to clean
it up a bit. I am planning to post it this week.
Are planning to send a new version soon?
As it is, we're 12 days from the end of this commitfest, so we don't
have
Hi Jeff,
the current patch suffers from what Heikki recently spotted: If one
backend is putting notifications in the queue and meanwhile another
backend executes LISTEN and commits, then this listening backend
committed earlier and is supposed to receive the notifications of the
notifying backend
On Fri, 2009-11-20 at 10:35 +0100, Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 11:04 PM, Joachim Wieland j...@mcknight.de wrote:
Given your example, what I am proposing now is to stop reading from
the queue once we see a not-yet-committed notification but once the
queue is full, read the
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Note that we don't preserve notifications when the database restarts.
But 2PC can cope with restarts. How would that fit together?
The notifications are written to the state file at prepare. They can
Joachim Wieland wrote:
On Fri, Nov 20, 2009 at 7:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Note that we don't preserve notifications when the database restarts.
But 2PC can cope with restarts. How would that fit together?
The notifications are written to the state
Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 11:04 PM, Joachim Wieland j...@mcknight.de wrote:
Given your example, what I am proposing now is to stop reading from
the queue once we see a not-yet-committed notification but once the
queue is full, read the uncommitted notifications,
On Wed, 18 Nov 2009 22:12:18 -0500 Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
(4) drop *old* notifications if the queue is full.
Since everyone has made the point that LISTEN is not meant to be a full
queueing system, I have no problem dropping notifications LRU-style.
NO,
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
There will now be a nonzero chance
of transactions failing at commit because of queue full. If the
chance is large this will be an issue. (Is it sane to wait for
the queue to be drained?)
Exactly. The whole idea of putting
On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
And in addition i don't like the idea of having the sender sitting
around until there's room for more messages in the queue, because some
very old backends didn't remove the stuff from the same.
The only
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
(4) drop *old* notifications if the queue is full.
Since everyone has made the point that LISTEN is not meant
Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, did we discuss the issue of 2PC transactions versus notify?
The current behavior of 2PC with notify is pretty cheesy and will
become more so if we make this change --- you aren't really
guaranteed
Heikki Linnakangas wrote:
Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Yes, I have been thinking about that also. So what should happen
when you prepare a transaction that has sent a NOTIFY before?
From the user's point of view, nothing should
Florian G. Pflug wrote:
Heikki Linnakangas wrote:
At a quick glance, it doesn't seem hard to support 2PC. Messages should
be put to the queue at prepare, as just before normal commit, but the
backends won't see them until they see that the XID has committed.
Yeah, but if the server is
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A better approach is to do something similar to what we do now: at
prepare, just store the notifications in the state file like we do
already. In notify_twophase_postcommit(), copy the messages to the
shared queue. Although it's
On Thu, 19 Nov 2009 14:23:57 +0100 Joachim Wieland wrote:
On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum
adsm...@wars-nicht.de wrote:
And in addition i don't like the idea of having the sender sitting
around until there's room for more messages in the queue, because some
very
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A better approach is to do something similar to what we do now: at
prepare, just store the notifications in the state file like we do
already. In notify_twophase_postcommit(), copy the messages to the
shared queue.
Florian G. Pflug f...@phlo.org writes:
Tom Lane wrote:
This is still ignoring the complaint: you are creating a clear risk
that COMMIT PREPARED will fail.
I'd see no problem with COMMIT PREPARED failing, as long as it was
possible to retry the COMMIT PREPARED at a later time. There surely
Tom Lane wrote:
Florian G. Pflug f...@phlo.org writes:
Tom Lane wrote:
This is still ignoring the complaint: you are creating a clear
risk that COMMIT PREPARED will fail.
I'd see no problem with COMMIT PREPARED failing, as long as it
was possible to retry the COMMIT PREPARED at a later
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A better approach is to do something similar to what we do now: at
prepare, just store the notifications in the state file like we do
already. In notify_twophase_postcommit(), copy the messages to the
shared queue.
g...@turnstep.com (Greg Sabino Mullane) writes:
BTW, did we discuss the issue of 2PC transactions versus notify?
The current behavior of 2PC with notify is pretty cheesy and will
become more so if we make this change --- you aren't really
guaranteed that the notify will happen, even though the
On Thu, Nov 19, 2009 at 6:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, ignoring 2PC for a moment, I think the patch suffers from a little
race condition:
Session 1: BEGIN;
Session 1: INSERT INTO foo ..;
Session 1: NOTIFY 'foo';
Session 1: COMMIT -- commit begins
Joachim Wieland wrote:
The example you brought up fails if
Session 2 disregards the notifications based on the current set of
channels that it is listening to at this point.
Right. Session 2 might not be listening at all yet.
If I understand you
correctly what you are suggesting is to not
Joachim Wieland j...@mcknight.de writes:
4) Allow readers to read uncommitted notifications as well.
The question that strikes me here is one of timing --- apparently,
readers will now have to check the queue *without* having received
a signal? That could amount to an unpleasant amount of extra
On Mon, Nov 16, 2009 at 2:35 PM, Andrew Chernow a...@esilo.com wrote:
1) drop new notifications if the queue is full (silently or with
rollback)
I like this one best, but not with silence of course. While it's not the
most
polite thing to do, this is for a super extreme edge case. I'd
On Thu, Nov 19, 2009 at 1:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
4) Allow readers to read uncommitted notifications as well.
The question that strikes me here is one of timing --- apparently,
readers will now have to check the queue *without* having
That is, if the queue overflows what you should do is drop the
payloads and condense all the messages for a given class into a single
notification for that class with unknown payload. That way if a
cache which wants to invalidate specific objects gets a queue overflow
condition then at least it
1 - 100 of 113 matches
Mail list logo
