| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-26 17:13:40 |
| Message-ID: | BANLkTi=hmTe_ufJ_ZEq4uG6WknQJ9qzmPA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, May 26, 2011 at 12:28 PM, Ross J. Reedstrom <reedstrm(at)rice(dot)edu> wrote:
> Perhaps the approach to restricting connections should not be a database
> object lock, but rather an admin function that does the equivalent of
> flipping datallowconn in pg_database?
To me, that seems like a better approach, although it's a little hard
to see how we'd address Alvaro's desire to have it roll back
automatically when the session disconnected. The disconnect might be
caused by a FATAL error, for example.
I'm actually all in favor of doing more things via SQL rather than
configuration files. The idea of some ALTER SYSTEM command seems very
compelling to me. I just don't really like this particular
implementation, which to me seems far too bound up in implementation
details I'd rather not rely on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-05-26 17:14:03 | Re: Pre-alloc ListCell's optimization |
| Previous Message | Robert Haas | 2011-05-26 17:08:46 | Re: [ADMIN] pg_class reltuples/relpages not updated by autovacuum/vacuum |