From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_group_name_index corrupt? |
Date: | 2000-05-05 14:27:29 |
Message-ID: | 6272.957536849@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <e99re41(at)DoCS(dot)UU(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-05 14:34:23 | Re: client libpq multibyte support |
Previous Message | Bruce Momjian | 2000-05-05 14:08:33 | Re: pg_group_name_index corrupt? |