| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: ALTER DATABASE RENAME with HS/SR |
| Date: | 2010-10-04 18:42:12 |
| Message-ID: | 5120.1286217732@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I understand that we need to disconnect users if the database is
> dropped (it's kind of hard to access a database that's not there any
> more...) but I'm fuzzy on why we'd need to do that if it is merely
> renamed.
I think that modern backends might survive that okay (though they didn't
use to; we once had global variable(s) containing the DB name). But
it's much less clear that clients would cope sanely. "I'm connected to
database foo". "No you're not". Connection poolers in particular are
likely to get bent out of shape by this.
OTOH, we don't have a similar interlock to prevent renaming users
who have active sessions, so maybe we are being overprotective here.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2010-10-04 18:49:43 | Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance |
| Previous Message | Dan Ports | 2010-10-04 18:35:42 | Re: MIT benchmarks pgsql multicore (up to 48)performance |