"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> In other words, after doing a select user_write_lock_oid(t.oid) from
> big_table t;
> It's server restart time.
User locks are not released at transaction failure. Quitting that
backend should have got you out of it, however.
> What's really interesting about this is that the pg_locks view (after
> the offending disconnects) reports nothing out of the ordinary even
> though no backends can acquire locks after that point.
User locks are not shown in pg_locks, either.
There is a secondary issue here, which is that we don't have provision
to recycle hash table entries back into the general shared memory pool
(mainly because there *is* no "shared memory pool", only never-yet-
allocated space). So when you do release these locks, the freed space
only goes back to the lock hash table's freelist. That means there
won't be any space for expansion of the buffer hash table, nor any other
shared data structures. This could lead to problems if you hadn't been
running the server long enough to expand the buffer table to full size.
I don't think it's practical to introduce a real shared memory
allocator, but maybe we could alleviate the worst risks by forcing the
buffer hash table up to full size immediately at startup. I'll look at
this.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
