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
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 |