On 2013-01-17 10:19:23 -0500, Tom Lane wrote:
> Pavan Deolasee writes:
> > On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane 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)
Pavan Deolasee writes:
> On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane 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 that.
> I thought since FATAL will for
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
On Thu, Jan 17, 2013 at 12:08 PM, Tom Lane 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;
> but ereport(FA
Abhijit Menon-Sen 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 branches of the
if/else
On Thu, Jan 17, 2013 at 9:26 AM, Abhijit Menon-Sen wrote:
> 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:
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
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee
> wrote:
> > 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
On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee wrote:
>
>
> 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 commented in the
> original
On Tue, Dec 4, 2012 at 1:44 PM, Andres Freund wrote:
>
> >
> > 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 connection du
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
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, rechec
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
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 us
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
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 read
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 o
The FATAL and ERROR cancellation modes are quite different. In FATAL
mode, you just want to kill the backend. The target connection doesn't
need to know the LSN.
In ERROR mode, you don't really want to interrupt the target backend. In
ReadBuffer, you're checking a global variable,
BufferRecov
18 matches
Mail list logo
