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