Re: autovacuum process (PID ...) was terminated by signal 11 - Mailing list pgsql-bugs

From Brian Hirt
Subject Re: autovacuum process (PID ...) was terminated by signal 11
Date
Msg-id AC3E7F38-D3F6-44D0-8667-237BF79D70DF@mobygames.com
Whole thread Raw
In response to Re: autovacuum process (PID ...) was terminated by signal 11  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: autovacuum process (PID ...) was terminated by signal 11
Re: autovacuum process (PID ...) was terminated by signal 11
List pgsql-bugs
Cool,

I was just writing to let you know I created an easily reproducible
test case too, but I guess you don't need that now.

Let me know if there is anything else I can do to help.

Also, if a patch is produced, I'd love to get a copy of it. We just
upgraded our production servers to 8.1.1 this morning (this issue
never came up during testing) and I'l like to get this in there
because it's likely to happen again.

--brian

On Jan 4, 2006, at 11:31 AM, Tom Lane wrote:

> Brian Hirt <bhirt@mobygames.com> writes:
>> I can analyze that table without problems.  I don't know if it's the
>> same table every time.   I'm trying to set up a development
>> environment where i can test this stuff better without messing up our
>> production systems. The table does have an expresional index.
>
> I've managed to reproduce this: the triggering condition is that a
> single autovac iteration has to VACUUM one table and then ANALYZE
> (no vac) another table that has an expressional index with a plpgsql
> function.  It looks like we missed a path of control where
> ActiveSnapshot has to be re-set-up, but I'm not clear where.
>
>             regards, tom lane

--------------------------------------------
MobyGames
http://www.mobygames.com
The world's largest and most comprehensive
gaming database project

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: autovacuum process (PID ...) was terminated by signal 11
Next
From: Robert Osowiecki
Date:
Subject: Re: BUG #2143: Indexes incorrectly created from database dump