Re: postgresql locks the whole table! - Mailing list pgsql-general

> As I remember the implementation problem is that we do an exclusive row
> lock right now by putting the transaction id on the row and set a
> special row-lock bit in the tuple.  Shared locks need to store multiple
> transaction ids, and that is where we are stuck.  Shared memory is of
> finite size, and the number of proc/row combinations is infinite, so it
> seems we will need some shared stucture with backing store to disk, and
> that will be slow.
>
> You know the maximum number of backends on startup, but I don't see how
> that helps us.  If we could somehow know the unique combinations of
> those backend ids that would be used for any row, we could reserve a
> range of transactions ids to map them, but the number of combinations is
> too large.
>
> Our xid/command-counter is currently 64 bits, so if we only had a
> maximum of 64 backends, we could use those bits to mark the backends
> holding the locks rather than put the xid in there.  Of course, the
> maximum number backends can change over time, so that isn't really a
> solution but more a brainstorm, but I do think shared memory bitmaps
> might be in the final solution.
>
> One idea would be to allocate 10k of shared memory for a shared lock
> bitmap.  Assuming a max 100 backend, that is 2500 lock combinations,
> numbered 0-2499.  We would put the bitmap number on the rows rather than
> the xid.  Of course, problems are that there are only 2500 combinations
> supported, and transactions have to get an exclusive lock on transaction
> commit to clear their backend bits from the bitmap table so the rows can
> be reused. Another refinement would be to use the row xid to store
> either the xid for single backend locks, and use the bitmap table number
> only when there is sharing of row locks by multiple backends.  That
> might reduce the contention on the bitmap table.  If a backend wasn't
> involved in shared locks, its bit wouldn't be set in the bitmap table
> and it has nothing to do, and it can read the table without a lock.

The way I understand it, is that you're having trouble storing all of
the xids in the row; right now you just store one and mark it "locked".
If you were able to store several, but not necessarily all xids in all
cases, wouldn't that be a big improvement? The xids not in the list
would lock, as they do now, and the ones in the list would show an
improvement by sharing the lock, right?

Otherwise I don't entirely understand what you're saying.

Regards,
    Jeff Davis