Re: [HACKERS] Vacuum analyze bug CAUGHT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
Date: 1999-09-10 14:28:06
Message-ID: 10085.936973686@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Simms <grim(at)argh(dot)demon(dot)co(dot)uk> writes:
> 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?

Yup, could happen. (I think it would take several hundred create/
drop cycles, but that's certainly possible during a long vacuum.)
That's why there's code to deal with the possibility of SI buffer
overrun.

But as I said, I'm not convinced you are dealing with an SI overrun
--- and the lack of messages about it seems to point away from that
theory. I brought it up because it was a possible area for trouble.

regards, tom lane

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-09-10 15:01:51 Re: [HACKERS] Postgres Performance
Previous Message Oleg Broytmann 1999-09-10 14:24:09 Re: [HACKERS] Re: Query about postgres medical database