Re: Reducing relation locking overhead

From: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reducing relation locking overhead
Date: 2005-12-08 15:23:57
Message-ID: 1134055437.4779.272.camel@coppola.muc.ecircle.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2005-12-08 at 16:05, Tom Lane wrote:
[SNIP]
> There isn't any way for it to do that (ie, be sure everyone else has
> adjusted to the new state of affairs), short of acquiring some sort of
> short-term exclusive lock on the table, which is a really bad idea.
> The pending lock would block other incoming requests on the table until
> all the current users exited their transactions.
>

But it is an acceptable compromise to lock the table until all current
transactions are over... the alternative for reindexing a big table is
usually to schedule a down-time, which is even worse...

REINDEX is usually used to fix a big tables big index bloat, and that
won't fly without a downtime, or, with this short-term full table lock
in a low-traffic time-slot.

For my usage patterns I would vote with the table lock if it is just a
means of blocking new transactions until the running ones finish. I'll
just make sure there are none long running when I issue the REINDEX...

Cheers,
Csaba.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-12-08 15:26:01 Re: Reducing contention for the LockMgrLock
Previous Message Tom Lane 2005-12-08 15:05:15 Re: Reducing relation locking overhead