Re: postgresql locks the whole table!
On Sun, 7 Dec 2003, Greg Stark wrote:
[color=blue]
> It's not strictly necessary to have a list of all xids at all. The normal
> "shared read lock" is just "take the write lock, increment the readers
> counter, unlock" Anyone who wants to write has to wait (using, eg, a condition
> variable) until the readers count goes to 0.[/color]
There are some storage/cleanup questions though. If that's stored in the
tuple header, what happens after a crash?
In addition, how should the locks be granted for a sequence like:
T1: get shared lock on row A
T2: get exclusive lock on row A
T3: get shared lock on row A
Does T3 get the lock or not? If it does, then you have the possibility of
freezing out T2 for a very long time and badly hurting update/delete
performance. If it doesn't, then how are you keeping track of the fact
that there are one or more people who want exclusive locks on the same
row that are "in front" of you?
[color=blue]
> This gets the right semantics but without the debugging info of a list of
> lockers. Other than debugging the only advantage I see to having the list of
> lockers is for deadlock detection. Is that absolutely mandatory?[/color]
I think so, yes, especially if we're going to use it for things like
foreign keys. It's too easy to get into a deadlock with foreign keys
(even when implemented through shared locks) and I think having undetected
deadlocks would be even worse than our current behavior. At least with
the current behavior you get an indication that something is wrong.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
On Sun, 7 Dec 2003, Greg Stark wrote:
[color=blue]
> It's not strictly necessary to have a list of all xids at all. The normal
> "shared read lock" is just "take the write lock, increment the readers
> counter, unlock" Anyone who wants to write has to wait (using, eg, a condition
> variable) until the readers count goes to 0.[/color]
There are some storage/cleanup questions though. If that's stored in the
tuple header, what happens after a crash?
In addition, how should the locks be granted for a sequence like:
T1: get shared lock on row A
T2: get exclusive lock on row A
T3: get shared lock on row A
Does T3 get the lock or not? If it does, then you have the possibility of
freezing out T2 for a very long time and badly hurting update/delete
performance. If it doesn't, then how are you keeping track of the fact
that there are one or more people who want exclusive locks on the same
row that are "in front" of you?
[color=blue]
> This gets the right semantics but without the debugging info of a list of
> lockers. Other than debugging the only advantage I see to having the list of
> lockers is for deadlock detection. Is that absolutely mandatory?[/color]
I think so, yes, especially if we're going to use it for things like
foreign keys. It's too easy to get into a deadlock with foreign keys
(even when implemented through shared locks) and I think having undetected
deadlocks would be even worse than our current behavior. At least with
the current behavior you get an indication that something is wrong.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Comment