Re: [HACKERS] vacuum analyze

>
> Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk> writes:
> > But after 4 days of frustration, I just want to be sure - nobody else
> > has found the problem and solved it have they? I just dont want to
> > waste my time on this if someone else has found the cause...
>
> Let's see ... I know that removing pg_vlock while vacuum is running
> will lead to a coredump after vacuum finishes (it doesn't recover
> cleanly after its attempt to unlink pg_vlock fails). I think I know
> how to fix that but it's not done yet. The same problem could affect
> any error that is detected between vacuum's internal transactions.
> Do you get any error reports in the postmaster log when there is a
> crash?

ahem, well, to be honest, Ive never found any documentation on how to
read the logs *embarrassed smile*.

template1=> select * from pg_log;
ERROR: pg_log cannot be accessed by users

That happens with any account.

It COULD be a problem with that, as I have a crontab process that vacuums
everything every 24 hours, but also I perform some minor vacuums in the
meantime, some of which may occur when the main vacuum is happening. I didnt
notice that as a pattern, but it certainly COULD be that. I'll check into it.

> Beyond that, I don't recall having heard of any recent fixes that affect
> vacuum.
>
> If you can create a reproducible example then more people could poke
> at it, so that seems like the avenue to focus on.

Yup, well, if I could get it to happen *at all* any more, I could poke around,
as I am running the backend that is handling the vacuum under gdb. If I
find a reproducable way I will certainly report it here.

Thanx

M Simms