On 2013-01-17 01:38:31 -0500, Tom Lane wrote:
But having said that ... are we sure this code is not actually broken?
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
but ereport(FATAL) will try exactly
Pavan Deolasee pavan.deola...@gmail.com writes:
On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
but ereport(FATAL) will try exactly
On 2013-01-17 10:19:23 -0500, Tom Lane wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the
At 2012-12-29 14:23:45 -0500, sfr...@snowman.net wrote:
Regarding the actual comment, here's the wording that I'd use:
Sorry for nitpicking, but we can't long jumps made me cringe.
Here's a slightly more condensed version:
/*
* We can't use ereport(ERROR) here, because any longjmps
On Thu, Jan 17, 2013 at 9:26 AM, Abhijit Menon-Sen a...@2ndquadrant.comwrote:
At 2012-12-29 14:23:45 -0500, sfr...@snowman.net wrote:
Regarding the actual comment, here's the wording that I'd use:
Sorry for nitpicking, but we can't long jumps made me cringe.
Here's a slightly more
Abhijit Menon-Sen a...@2ndquadrant.com writes:
Sorry for nitpicking, but we can't long jumps made me cringe.
Agreed :-(
Here's a slightly more condensed version:
I find this still not quite right, because where it's placed, it applies
to both the DoingCommandRead and !DoingCommandRead
On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
But having said that ... are we sure this code is not actually broken?
I'm not.
ISTM that if we dare not interrupt for fear of confusing OpenSSL, we
cannot safely attempt to send an error message to the client either;
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee
pavan.deola...@gmail.comwrote:
Thanks Andres. I also read the original thread and I now understand why we
are using FATAL here, at least until we have a better solution. Obviously
the
Hi,
On 2012-12-04 12:30:43 +0530, Pavan Deolasee wrote:
I was trying some simple queries on a Hot Standby with streaming
replication.
On standby, I do this:
postgres=# begin transaction isolation level repeatable read;
BEGIN
postgres=# explain verbose select count(b) from test WHERE a
On Tue, Dec 4, 2012 at 1:44 PM, Andres Freund and...@2ndquadrant.comwrote:
After max_standby_streaming_delay, the standby starts cancelling the
queries. I get an error like this on the standby:
postgres=# explain verbose select count(b) from test WHERE a 10;
FATAL: terminating
On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee pavan.deola...@gmail.comwrote:
Thanks Andres. I also read the original thread and I now understand why we
are using FATAL here, at least until we have a better solution. Obviously
the connection reset is no good either because as someone
On Sun, 2009-01-25 at 16:19 +, Simon Riggs wrote:
On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
Ok, then I think we have a little race condition. The startup process
doesn't get any reply indicating that the target backend has
processed
the SIGINT and set the
Simon Riggs wrote:
Rather than signalling, we could use a hasconflict boolean for each proc
in a shared data structure. It can be read without spinlock, but should
only be written while holding spinlock.
Each time we read a block we check if hasconflict is set. If it is, we
grab spinlock,
On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
Ok, then I think we have a little race condition. The startup process
doesn't get any reply indicating that the target backend has
processed
the SIGINT and set the cached conflict LSN. The target backend might
move ahead using
On Fri, 2009-01-23 at 17:51 +0200, Heikki Linnakangas wrote:
In ERROR mode, you don't really want to interrupt the target backend. In
ReadBuffer, you're checking a global variable,
BufferRecoveryConflictPending on each call, and if it's set, you check
the buffer's LSN against the LSN of
Simon Riggs wrote:
On Fri, 2009-01-23 at 17:51 +0200, Heikki Linnakangas wrote:
ISTM that if ReadBuffer read the value directly from the PGPROC entry,
there would be no need for the signaling (in the ERROR mode).
That is possible and I considered it. If we did it that way we would
need to
On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
Correct me if I'm wrong, but I thought the idea of this new conflict
resolution was that the startup process doesn't need to wait for the
target backend to die. Instead, the target backend knows to commit
suicide if it
17 matches
Mail list logo
