Hi all,
On Fri, May 27, 2011 at 2:13 AM, Robert Haas wrote:
> On Thu, May 26, 2011 at 12:28 PM, Ross J. Reedstrom
> 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 datallow
On Thu, May 26, 2011 at 12:28 PM, Ross J. Reedstrom 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
On Thu, May 19, 2011 at 04:13:12PM -0400, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of jue may 19 15:32:57 -0400 2011:
> >
> > That's a bit of a self-defeating argument though, since it implies
> > that the effect of taking an exclusive lock via LockSharedObject()
> > will not si
Excerpts from Robert Haas's message of jue may 19 15:32:57 -0400 2011:
> On Thu, May 19, 2011 at 1:48 PM, Alvaro Herrera
> > The following things acquire a lock on database:
> >
> > ALTER DATABASE SET
> > ALTER DATABASE OWNER
> > COMMENT ON DATABASE
> >
> > So as far as features that would caus
On Thu, May 19, 2011 at 1:48 PM, Alvaro Herrera
wrote:
>> 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
On Thu, May 19, 2011 at 12:57 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
>> On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
>> wrote:
>> >> 1. I suggested that this looks a lot like the controls of pg_hba.conf
>> >>
>> >> When our DBAs are
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue may 19 13:34:13 -0400 2011:
>> 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
Excerpts from Tom Lane's message of jue may 19 13:34:13 -0400 2011:
> Alvaro Herrera 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.
>
> > Y
Alvaro Herrera 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 whateve
Excerpts from Robert Haas's message of jue may 19 10:18:20 -0400 2011:
> On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
> wrote:
> >> 1. I suggested that this looks a lot like the controls of pg_hba.conf
> >>
> >> When our DBAs are doing major management of replication, they are
> >> known to re
On Wed, May 18, 2011 at 7:11 PM, Alvaro Herrera
wrote:
>> 1. I suggested that this looks a lot like the controls of pg_hba.conf
>>
>> When our DBAs are doing major management of replication, they are
>> known to reconfigure pg_hba.conf to lock out all users save for the
>> one used by Slony.
>
>
On Thursday, May 19, 2011 06:55:36 AM David Christensen wrote:
> On May 18, 2011, at 6:11 PM, Alvaro Herrera wrote:
> > Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400
2011:
> >> On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova
wrote:
> >>> So we the lock will be released
Excerpts from David Christensen's message of jue may 19 00:55:36 -0400 2011:
> How would this differ from just UPDATE pg_database SET datallowconn = FALSE
> for the databases in question?
Several ways actually. First, it is automatically gone when the locking
session disconnects (so it clean up
On May 18, 2011, at 6:11 PM, Alvaro Herrera wrote:
> Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400 2011:
>> On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova
>> wrote:
>>> So we the lock will be released at end of the session or when the
>>> UNLOCK DATABASE command is in
Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400 2011:
> On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova wrote:
> > So we the lock will be released at end of the session or when the
> > UNLOCK DATABASE command is invoked, right?
> > A question: why will we beign so rude by k
On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova wrote:
> So we the lock will be released at end of the session or when the
> UNLOCK DATABASE command is invoked, right?
> A question: why will we beign so rude by killing other sessions
> instead of avoid new connections and wait until the current se
On Tue, May 17, 2011 at 10:21 PM, Alvaro Herrera
wrote:
>
> So we would have a new command LOCK DATABASE [FOR SESSION] or something
> like that; the pooler software would call that and then kill other
> existing application connections (using pg_terminate_backend() perhaps),
> then drop the databa
One of the things that came out of the clustering session is a need for
a LOCK DATABASE command. Primarily to be able to drop databases across
nodes in a cluster, but later chats lead to ideas about upgrading
databases' schemas and such operations that need to ensure that no one
else is accessing
18 matches
Mail list logo
