Re: [HACKERS] Vacuum analyze bug CAUGHT - Mailing list pgsql-hackers

From Michael Simms
Subject Re: [HACKERS] Vacuum analyze bug CAUGHT
Date
Msg-id 199909091942.UAA25753@argh.demon.co.uk
Whole thread Raw
In response to Re: [HACKERS] Vacuum analyze bug CAUGHT  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Vacuum analyze bug CAUGHT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> The first thing you can do is look to see what the error message is ---
> it should be in the postmaster's stderr logfile, even though 6.5.* libpq
> omits to display it because of the crash.

Woops, I only redirected stdout. I will redirect stderr too. *2 minutes and
one crash later* Hmmm, nothing appears in the logs.

/usr/bin/postmaster -S -N 128 -B 256 -D/var/lib/pgsql/data > /tmp/postmasterout 2> /tmp/postmastererr

And nothing was in either log.

> Another useful thing would be
> to set a breakpoint at elog() so that you can examine the context of the
> error report.  (Actually, since vacuum generates lots of elog(NOTICE)
> and elog(DEBUG), the breakpoint had better be further down in elog,
> perhaps where it's about to longjmp back to PostgresMain.)
> 
> BTW, VACUUM runs a separate transaction for each table it works on,
> so although most of its work is done inside a transaction, there are
> short intervals between tables where it's not in one.  The error must
> be getting reported during one of these intervals.  That narrows things
> down a lot.
> 

<snip SI information>

Now, let me think for a moment:

Vacuum works on each table inside a transaction

The backend only reads the SI buffer when it starts a new transaction

What then happens if vacuum is vacuuming a BIG table (such as 300,000
lines) whilst another process is doing create and drop tables a lot.

Wouldnt the buffer fill up, as it was never starting a transaction
when vacuuming that big table?

However those were the only two backends active, it is a test
database on my home machine.

> an SI overflow condition.  I think that would take longer than "3-5
> seconds", though, unless your machine is way faster than mine.

Ive got an AMD K62-400 with 128 MB mmeory, not slow but not roastingly
fast either.

> I hope this gives you enough info to poke at the problem more
> intelligently.
> 
> Lastly, did you build with --enable-cassert?  The assert checks slow things
> down a little, but are often real helpful when looking for backend bugs.

Nope, I will recompile the new beta with this option, and post on the
progress. Thanks
                M Simms


pgsql-hackers by date:

Previous
From: Bernard Frankpitt
Date:
Subject: pgindent
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] pgindent