Re: LWLock contention: I think I understand the problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Hannu Krosing <hannu(at)krosing(dot)net>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, jwbaker(at)acm(dot)org
Subject: Re: LWLock contention: I think I understand the problem
Date: 2002-01-07 16:39:35
Message-ID: 9390.1010421575@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-odbc

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> Was it not the case that instead of locking whole tables the new
> vacuum locks only one page at a time. If it can't lock that page it
> just moves to next one instead of waiting for other backend to release
> its lock.

No, it just waits till it can get the page lock.

The only conditional part of the new vacuum algorithm is truncation of
the relation file (releasing empty end pages back to the OS). That
requires exclusive lock on the relation, which it will not be able to
get if there are any other users of the relation. In that case it
forgets about truncation and just leaves the empty pages as free space.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-01-07 17:28:12 Re: Why MemoryContextSwitch in ExecRelCheck ?
Previous Message Michael Meskes 2002-01-07 16:29:05 Re: ecpg compile error on AIX

Browse pgsql-odbc by date

  From Date Subject
Next Message Gilles DAROLD 2002-01-07 17:51:19 Problem with view and fetch_fields
Previous Message Hannu Krosing 2002-01-07 07:01:15 Re: LWLock contention: I think I understand the problem