> > (2) If it's autovacuum we're talking about, it will get kicked off the
> > table if anyone else comes along and wants a conflicting lock.
>
> Not on 8.2 though.
That is also nice to know. One more reason to upgrade to 8.3.
Thank you very much, both Alvaro and Tom, for the very insightful
dis
Tom Lane wrote:
> (2) If it's autovacuum we're talking about, it will get kicked off the
> table if anyone else comes along and wants a conflicting lock.
Not on 8.2 though.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, In
Alvaro Herrera wrote:
> Peter Schuller wrote:
> > Actually, while on the topic:
> >
> > > date: 2007-09-10 13:58:50 -0400; author: alvherre; state: Exp;
> > > lines: +6 -2;
> > > Remove the vacuum_delay_point call in count_nondeletable_pages,
> > > because we hold
> > > an exclusi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Peter Schuller wrote:
>> Even with the fix the lock is held. Is the operation expected to be
>> "fast" (for some definition of "fast") and in-memory, or is this
>> something that causes significant disk I/O and/or scales badly with
>> table size or simil
Peter Schuller wrote:
> Actually, while on the topic:
>
> > date: 2007-09-10 13:58:50 -0400; author: alvherre; state: Exp;
> > lines: +6 -2;
> > Remove the vacuum_delay_point call in count_nondeletable_pages, because
> > we hold
> > an exclusive lock on the table at this point, wh
Actually, while on the topic:
> date: 2007-09-10 13:58:50 -0400; author: alvherre; state: Exp; lines:
> +6 -2;
> Remove the vacuum_delay_point call in count_nondeletable_pages, because
> we hold
> an exclusive lock on the table at this point, which we want to release as
> soon
>
Hello,
> No. VACUUM takes an exclusive lock at the end of the operation to
> truncate empty pages. (If it cannot get the lock then it'll just skip
> this step.) In 8.2.4 there was a bug that caused it to sleep
> according to vacuum_delay during the scan to identify possibly empty
> pages. This
Peter Schuller wrote:
> Does anyone have input on why this could be happening? The PostgreSQL
> version is 8.2.4[1]. Am I correct in that it *should* not be possible
> for this to happen?
No. VACUUM takes an exclusive lock at the end of the operation to
truncate empty pages. (If it cannot get t
Hello,
my understanding, and generally my experience, has been that VACUUM
and VACUUM ANALYZE (but not VACUUM FULL) are never supposed to block
neither SELECT:s nor UPDATE:s/INSERT:s/DELETE:s to a table.
This is seemingly confirmed by reading the "explicit locking"
documentation, in terms of the
