Re: [HACKERS] Vacuum analyze bug CAUGHT

From: Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: grim(at)argh(dot)demon(dot)co(dot)uk (Michael Simms), pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
Date: 1999-09-09 19:42:36
Message-ID: 199909091942.UAA25753@argh.demon.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-09-09 19:44:44 Re: [HACKERS] pgindent
Previous Message Bernard Frankpitt 1999-09-09 19:21:07 pgindent