Re: pg_group_name_index corrupt?

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
>> After further looking, I notice that users.c is one of the few places
>> that will drop AccessExclusiveLock at heap_close time rather than
>> holding it till xact commit.  I wonder whether this is a bug...

> Well it was you who did it while introducing that second argument in the
> first place. I think the safest thing to do is definitely to hold any lock
> until transaction end. I'm not sure, shouldn't the transaction isolation
> level apply here as well? In the end, is there ever a good reason for
> releasing a lock in heap_close?

I provided that hook because of stuff like the LISTEN/NOTIFY support,
which grabs and releases locks on pg_listener --- as it's presently
designed, not releasing the lock at end of statement could hang the
entire system until you commit your transaction.  (Probably
LISTEN/NOTIFY should be re-examined to see if it couldn't use a less
drastic lock than AccessExclusiveLock.  That code hasn't been gone over
since before MVCC.)  Also, I still think that in general it's OK to
release a read lock on a system table early.  Write locks, maybe not.

>> I also notice that there definitely is a glaring bug there:
>> write_password_file() leaks one kernel file descriptor each time it runs
>> (note the creat() call).

> Wow, this has been there for over two years.

Yeah, a long time :-(.  It's not the first resource leak we've found
in the password-related code, too.  I wonder if there are more...
        regards, tom lane