Re: [HACKERS] Vacuum analyze bug CAUGHT
От | Michael Simms |
---|---|
Тема | Re: [HACKERS] Vacuum analyze bug CAUGHT |
Дата | |
Msg-id | 199909091942.UAA25753@argh.demon.co.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] Vacuum analyze bug CAUGHT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Vacuum analyze bug CAUGHT
|
Список | 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 по дате отправления: