Peter Eisentraut writes:
> On Sun, 2012-06-24 at 01:26 +0300, Peter Eisentraut wrote:
>> About the new --maintenance-db options:
>>
>> Why was this option not added to createuser and dropuser? In the
>> original discussion[0] they were mentioned, but it apparently never
>> made it into the code.
On Sun, 2012-06-24 at 01:26 +0300, Peter Eisentraut wrote:
> About the new --maintenance-db options:
>
> Why was this option not added to createuser and dropuser? In the
> original discussion[0] they were mentioned, but it apparently never
> made it into the code.
What should we do with this?
On Fri, Jun 29, 2012 at 3:32 PM, Bruce Momjian wrote:
> On Mon, Jun 25, 2012 at 11:57:36AM -0400, Robert Haas wrote:
>> In retrospect, it seems as though it might have been a good idea to
>> make the postgres database read-only and undroppable, so that all
>> client utilities could count on being
On Mon, Jun 25, 2012 at 03:12:00PM -0400, Alvaro Herrera wrote:
>
> Excerpts from Robert Haas's message of lun jun 25 14:58:25 -0400 2012:
> >
> > On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
> > wrote:
> > > Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
> > >> Really
On Mon, Jun 25, 2012 at 02:58:25PM -0400, Robert Haas wrote:
> On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
> >> Really, I think
> >> pg_upgrade needs this option too, unless we're going to kill the
> >> problem
On Mon, Jun 25, 2012 at 11:57:36AM -0400, Robert Haas wrote:
> In retrospect, it seems as though it might have been a good idea to
> make the postgres database read-only and undroppable, so that all
> client utilities could count on being able to connect to it and get a
> list of databases in the c
On Sun, Jun 24, 2012 at 01:26:58AM +0300, Peter Eisentraut wrote:
> About the new --maintenance-db options:
>
> What is the purpose of these options? The initial discussion was
> unclear on this. The documentation contains no explanation of why they
> should be used. If we want to really support
Tom Lane writes:
Amit Kapila writes:
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
>>> The implementation I've wanted to see for some time is that you can
>>> start a standalone backend, but it speaks FE/BE protocol to its caller
>>> (preferably over pipes, so that there is
Amit Kapila writes:
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
>> The implementation I've wanted to see for some time is that you can
>> start a standalone backend, but it speaks FE/BE protocol to its caller
>> (preferably over pipes, so that there is no issue whatsoever o
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Robert Haas writes:
>> From pg_upgrade's perspective, it would
>> be nice to have a flag that starts the server in some mode where
>> nobody but pg_upgrade can connect to it and all connectio
Robert Haas writes:
> From pg_upgrade's perspective, it would
> be nice to have a flag that starts the server in some mode where
> nobody but pg_upgrade can connect to it and all connections are
> automatically allowed, but it's not exactly clear how to implement
> "nobody but pg_upgrade can conne
Excerpts from Robert Haas's message of lun jun 25 14:58:25 -0400 2012:
>
> On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
> >> Really, I think
> >> pg_upgrade needs this option too, unless we're going to kill th
On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
>> Really, I think
>> pg_upgrade needs this option too, unless we're going to kill the
>> problem at its root by providing a reliable way to enumerate database
>> names w
Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
> Really, I think
> pg_upgrade needs this option too, unless we're going to kill the
> problem at its root by providing a reliable way to enumerate database
> names without first knowing the name one that you can connect to.
On Sat, Jun 23, 2012 at 6:26 PM, Peter Eisentraut wrote:
> About the new --maintenance-db options:
>
> Why was this option not added to createuser and dropuser? In the
> original discussion[0] they were mentioned, but it apparently never made
> it into the code.
Oops. That was an oversight.
>
On Saturday, June 23, 2012, Peter Eisentraut wrote:
> About the new --maintenance-db options:
>
> Why was this option not added to createuser and dropuser? In the
> original discussion[0] they were mentioned, but it apparently never made
> it into the code.
>
> I find the name to be unfortunate.
About the new --maintenance-db options:
Why was this option not added to createuser and dropuser? In the
original discussion[0] they were mentioned, but it apparently never made
it into the code.
I find the name to be unfortunate. For example, I think of running
vacuum as "maintenance". So run
17 matches
Mail list logo
