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
11 matches
Mail list logo
