Re: Reducing relation locking overhead - Mailing list pgsql-hackers

From Csaba Nagy
Subject Re: Reducing relation locking overhead
Date
Msg-id 1134055437.4779.272.camel@coppola.muc.ecircle.de
Whole thread Raw
In response to Re: Reducing relation locking overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing relation locking overhead  (Simon Riggs <simon@2ndquadrant.com>)
List 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.






pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Reducing contention for the LockMgrLock
Next
From: Darcy Buskermolen
Date:
Subject: Re: HOOKS for Synchronous Replication?