"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Nailed it -- this is the actual bug that causes the abort. But I am
>> surprised that it doesn't print the error message in Stefan machine's;
>
> Hm, maybe we need an fflush(stderr) in ExceptionalCondition?
st
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Nailed it -- this is the actual bug that causes the abort. But I am
> surprised that it doesn't print the error message in Stefan machine's;
Hm, maybe we need an fflush(stderr) in ExceptionalCondition?
regards, tom lane
--
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Stefan Kaltenbrunner wrote:
> >
> > > well - i now have a core file but it does not seem to be much worth
> > > except to prove that autovacuum seems to be the culprit:
> > >
> > > Core was generated by `postgres: autovacuum worker process
> > >
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>
> > well - i now have a core file but it does not seem to be much worth
> > except to prove that autovacuum seems to be the culprit:
> >
> > Core was generated by `postgres: autovacuum worker process
> > '.
> > Pro
Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I'm wondering if there is some code path that invokes a PG_TRY deep in
>>> the bowels of the system.
> Huh, hang on ... there is one caller, which is to set client_encoding
> (call_string_assign_hook uses a PG_TRY block), but it is
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > I agree that that would be a bug and we should fix it, but I don't think
> > > it explains the problem we're seeing because there is no PG_TRY block
> > > in the autovac startup code that I can see :-(
> >
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I agree that that would be a bug and we should fix it, but I don't think
> > it explains the problem we're seeing because there is no PG_TRY block
> > in the autovac startup code that I can see :-(
>
> I'm wondering if there is some
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I agree that that would be a bug and we should fix it, but I don't think
> it explains the problem we're seeing because there is no PG_TRY block
> in the autovac startup code that I can see :-(
I'm wondering if there is some code path that invokes a PG_
Tom Lane wrote:
> I wrote:
> > Hmm ... I was about to say that the postmaster never sets
> > PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW
> > could do it? Does the postmaster ever execute PG_TRY?
>
> Doh, I bet that's it, and it's not the postmaster that's at issue
> but PG_
I wrote:
> Hmm ... I was about to say that the postmaster never sets
> PG_exception_stack, but maybe an error out of a PG_TRY/PG_RE_THROW
> could do it? Does the postmaster ever execute PG_TRY?
Doh, I bet that's it, and it's not the postmaster that's at issue
but PG_TRY blocks executed during sub
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm wondering if it wouldn't be more robust to define a longjmp target
> block before calling BaseInit(), and have it exit cleanly in case of
> failure (which is what you say elog.c should be doing if there is no
> target block).
No, because elog is alr
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Oh, another thing that I think may be happening is that the stack is
> > restored in longjmp, so it is trying to report an error elsewhere but
> > it crashes because something got overwritten or something; i.e. a
> > bug in the error
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Oh, another thing that I think may be happening is that the stack is
> restored in longjmp, so it is trying to report an error elsewhere but
> it crashes because something got overwritten or something; i.e. a
> bug in the error recovery code.
Hm, someth
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>
> > well - i now have a core file but it does not seem to be much worth
> > except to prove that autovacuum seems to be the culprit:
> >
> > Core was generated by `postgres: autovacuum worker process
> > '.
> > Pro
Stefan Kaltenbrunner wrote:
> well - i now have a core file but it does not seem to be much worth
> except to prove that autovacuum seems to be the culprit:
>
> Core was generated by `postgres: autovacuum worker process
> '.
> Program terminated with signal 6, Aborted
Alvaro Herrera wrote:
> Tom Lane wrote:
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>> Stefan Kaltenbrunner wrote:
two of my buildfarm members had different but pretty weird looking
failures lately:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:
Alvaro Herrera wrote:
> Tom Lane wrote:
>> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>>> Stefan Kaltenbrunner wrote:
two of my buildfarm members had different but pretty weird looking
failures lately:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> > Stefan Kaltenbrunner wrote:
> >> two of my buildfarm members had different but pretty weird looking
> >> failures lately:
> >> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:03:03
> >> and
> >>
> >>
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Stefan Kaltenbrunner wrote:
>> two of my buildfarm members had different but pretty weird looking
>> failures lately:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:03:03
>> and
>>
>> http://www.pgbuildfarm.org/cgi-
Stefan Kaltenbrunner wrote:
> two of my buildfarm members had different but pretty weird looking
> failures lately:
>
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:03:03
>
> and
>
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emu&dt=2007-04-24%2014:35:02
>
two of my buildfarm members had different but pretty weird looking
failures lately:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-04-25%2002:03:03
and
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=emu&dt=2007-04-24%2014:35:02
any ideas on what might causing those ?
Ste
21 matches
Mail list logo
