Re: 8.3.0 Core with concurrent vacuum fulls - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.3.0 Core with concurrent vacuum fulls
Date
Msg-id 25742.1204731065@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.3.0 Core with concurrent vacuum fulls  ("Gavin M. Roy" <gmr@myyearbook.com>)
Responses Re: 8.3.0 Core with concurrent vacuum fulls  ("Gavin M. Roy" <gmr@myyearbook.com>)
Re: 8.3.0 Core with concurrent vacuum fulls  ("Gavin M. Roy" <gmr@myyearbook.com>)
List pgsql-hackers
"Gavin M. Roy" <gmr@myyearbook.com> writes:
> 2008-03-04 05:45:47 EST [6698]: [1-1] LOG:  process 6698 still waiting for
> AccessShareLock on relation 1247 of database 16385 after 1001.519 ms
> 2008-03-04 05:45:47 EST [6698]: [2-1] STATEMENT:  VACUUM FULL
> autograph.autograph_creators
> 2008-03-04 05:46:28 EST [6730]: [1-1] LOG:  process 6730 still waiting for
> AccessShareLock on relation 1247 of database 16385 after 1000.887 ms
> 2008-03-04 05:46:28 EST [6730]: [2-1] STATEMENT:  VACUUM FULL
> lunchmoney.totals
> 2008-03-04 05:47:55 EST [3809]: [18-1] LOG:  server process (PID 6742) was
> terminated by signal 6: Aborted
> 2008-03-04 05:47:55 EST [3809]: [19-1] LOG:  terminating any other active
> server processes
> 2008-03-04 05:47:55 EST [6741]: [12-1] WARNING:  terminating connection
> because of crash of another server process

How annoying ... the PANIC message doesn't seem to have reached the log.
elog.c is careful to fflush(stderr) before abort(), so that isn't
supposed to happen.  But it looks like you are using syslog for logging
(correct?) so maybe this is a problem with the syslog implementation
you're using.  What's the platform exactly?

I wonder if it'd be reasonable to put a closelog() call just before
the abort() ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Gavin M. Roy"
Date:
Subject: Re: 8.3.0 Core with concurrent vacuum fulls
Next
From: "Gavin M. Roy"
Date:
Subject: Re: 8.3.0 Core with concurrent vacuum fulls