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

From Qingqing Zhou
Subject Re: Reducing relation locking overhead
Date
Msg-id dmto9l$1h38$1@news.hub.org
Whole thread Raw
In response to Re: Reducing relation locking overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing relation locking overhead
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> wrote
>
> The real situation is that you must hold at least AccessShareLock on the
> table throughout the entire operation, else you have no defense against
> (say) someone dropping the index or the entire table out from under you.
> And when you add onto this lock in order to lock out writers
> temporarily, you are engaging in a lock upgrade, which can deadlock
> against any sort of exclusive lock request.  The fact that you've been
> holding the AccessShareLock for quite a long time means that the window
> for deadlock problems is very wide.
>

Maybe the deadlock problem is solvable, our current deadlock removal 
mechanism is like this:
/* who wakes up first who removes himself -- quite unfair :-( */RemoveFromWaitQueue(MyProc);

What if we change to cost-based removal, i.e., remove the one whose cost is 
smaller. In this case, an two-days-to-be-done reindex should never get 
killed.

Regards,
Qingqing






pgsql-hackers by date:

Previous
From: Qingqing Zhou
Date:
Subject: Re: [PERFORM] Network permormance under windows (fwd)
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] snprintf() argument reordering not working under