| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: LOCK DATABASE |
| Date: | 2011-05-19 17:34:13 |
| Message-ID: | 23349.1305826453@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
>> Second, it relies on the fact that a new connection briefly grabs a
>> lock on the database that is then released.
> Yes. This is well known and it's not going away.
>> If we happened (for whatever reason) to want to change that to a
>> session lock, or get rid of it entirely, then this would break.
> That would break other things too, so I don't see it as a problem.
I can't see getting rid of that lock, since we'd simply have to invent
some other interlock for new connections vs. DROP DATABASE. However,
I do think that we might sometime need to convert it to a session lock
that's held for the life of the backend. If this feature can't cope
with that, that'd be a potential problem.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2011-05-19 17:37:35 | some config options do not have defaults documented |
| Previous Message | Alvaro Herrera | 2011-05-19 16:57:21 | Re: LOCK DATABASE |