Tom Lane wrote:
> Bruce Momjian writes:
> > Discussion seems to have ended on this thread without a clear direction.
>
> I still think the right thing is to just use a non-default port number.
> That gets 90% of the benefit for 10% of the work of any other approach
> (except for the ones for whic
Bruce Momjian writes:
> Discussion seems to have ended on this thread without a clear direction.
I still think the right thing is to just use a non-default port number.
That gets 90% of the benefit for 10% of the work of any other approach
(except for the ones for which the ratio is even worse).
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > I meant the PGPASSWORD environment variable:
> >
> >
> >PGPASSWORD
> >
> > PGPASSWORD behaves the same as the > linkend="libpq-connect-password"> connection parameter.
> > Use of this environment variable
> >
Bruce Momjian wrote:
> I meant the PGPASSWORD environment variable:
>
>
>PGPASSWORD
>
> PGPASSWORD behaves the same as thelinkend="libpq-connect-password"> connection parameter.
> Use of this environment variable
> is not recommended for security rea
Andrew Dunstan wrote:
>
>
> On 06/17/2011 06:59 PM, Bruce Momjian wrote:
> >
> > (FYI, I think we would need to use PGPASSWORD for the password file
> > option, and we don't recommend PGPASSWORD use in our docs.)
> >
>
> er what?
>
> did you mean PGPASSFILE?
I meant the PGPASSWORD environment
On 06/17/2011 06:59 PM, Bruce Momjian wrote:
(FYI, I think we would need to use PGPASSWORD for the password file
option, and we don't recommend PGPASSWORD use in our docs.)
er what?
did you mean PGPASSFILE?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Peter Eisentraut wrote:
> On non-Windows servers you could get this even safer by disabling the
> TCP/IP socket altogether, and placing the Unix-domain sock
Peter Eisentraut writes:
> On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Peter Eisentraut wrote:
On non-Windows servers you could get this even safer by disabling the
TCP/IP socket altogether, and placing the Unix-domain socket in a
private tempora
On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> On non-Windows servers you could get this even safer by disabling the
> >> TCP/IP socket altogether, and placing the Unix-domain socket in a
> >> private temporary directory. The "port" wou
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Thu, Jun 16, 2011 at 11:47 PM, Bruce Momjian wrote:
> > > Robert Haas wrote:
> > >> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
> > >> > probably only #1 is appropriate.)
> > >>
> > >> I don't like any of these options as wel
Robert Haas wrote:
> On Thu, Jun 16, 2011 at 11:47 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
> >> > probably only #1 is appropriate.)
> >>
> >> I don't like any of these options as well as what I already proposed.
> >>
On Thu, Jun 16, 2011 at 11:47 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
>> > probably only #1 is appropriate.)
>>
>> I don't like any of these options as well as what I already proposed.
>> I proposed a complicated approach
Robert Haas wrote:
> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
> > probably only #1 is appropriate.)
>
> I don't like any of these options as well as what I already proposed.
> I proposed a complicated approach that actually fixes the problem for
> real; you're proposing
On Thu, Jun 16, 2011 at 5:16 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian wrote:
>> > I now believe we are overthinking all this. ?pg_upgrade has always
>> > supported specification of a port number. ?Why not just tell users to
>> > specify an un
Robert Haas wrote:
> On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian wrote:
> > I now believe we are overthinking all this. ?pg_upgrade has always
> > supported specification of a port number. ?Why not just tell users to
> > specify an unused port number > 1023, and not to use the default value?
>
On Wed, Jun 15, 2011 at 1:35 PM, Bruce Momjian wrote:
> I now believe we are overthinking all this. pg_upgrade has always
> supported specification of a port number. Why not just tell users to
> specify an unused port number > 1023, and not to use the default value?
1. Because it shouldn't be t
On Thu, Jun 16, 2011 at 1:48 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> "Ross J. Reedstrom" writes:
>> > As an operations guy, the idea of an upgrade using a random,
>> > non-repeatable port selection gives me the hebejeebees.
>>
>> Yeah, I agree. The latest version of the patch doesn't appea
On Thu, Jun 16, 2011 at 09:48:12AM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > "Ross J. Reedstrom" writes:
> > > As an operations guy, the idea of an upgrade using a random,
> > > non-repeatable port selection gives me the hebejeebees.
> >
> > Yeah, I agree. The latest version of the patch
Tom Lane wrote:
> "Ross J. Reedstrom" writes:
> > As an operations guy, the idea of an upgrade using a random,
> > non-repeatable port selection gives me the hebejeebees.
>
> Yeah, I agree. The latest version of the patch doesn't appear to have
> any random component to it, though --- it just ex
* Bruce Momjian (br...@momjian.us) wrote:
> Right, we will re-check at the time they do the actual upgrade. This
> was requested so people can prepare for the real upgrade without having
> to stop their live server.
Exactly. A very good thing to have, and something which I needed and
would hav
"Ross J. Reedstrom" writes:
> As an operations guy, the idea of an upgrade using a random,
> non-repeatable port selection gives me the hebejeebees.
Yeah, I agree. The latest version of the patch doesn't appear to have
any random component to it, though --- it just expects the user to
provide po
On Wed, Jun 15, 2011 at 09:14:16PM -0400, Stephen Frost wrote:
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > I have researched this and need feedback.
>
> In general, I like the whole idea of using random/special ports for the
> duration of the upgrade. I agree that we need to kee
Tom Lane wrote:
> Bruce Momjian writes:
> > I have researched this and need feedback. Initially I wanted to use a
> > single -p port flag to be used by the old and new clusters. However,
> > pg_upgrade allows --check mode while the old server is running, so we
> > need to allow you to use the cu
Bruce Momjian writes:
> I have researched this and need feedback. Initially I wanted to use a
> single -p port flag to be used by the old and new clusters. However,
> pg_upgrade allows --check mode while the old server is running, so we
> need to allow you to use the current old postmaster port
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian (br...@momjian.us) wrote:
> > Having long options mean different than short options seems very
> > confusing.
>
> Err, that wasn't what I was proposing.. Just having:
> --old-port-during-upgrade
>
> and similar would have to
* Bruce Momjian (br...@momjian.us) wrote:
> Having long options mean different than short options seems very
> confusing.
Err, that wasn't what I was proposing.. Just having:
--old-port-during-upgrade
and similar would have to be used if they want to specify the ports to
be used during the upgra
Stephen Frost wrote:
-- Start of PGP signed section.
> Bruce,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > I have researched this and need feedback.
>
> In general, I like the whole idea of using random/special ports for the
> duration of the upgrade. I agree that we need to keep the abil
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> I have researched this and need feedback.
In general, I like the whole idea of using random/special ports for the
duration of the upgrade. I agree that we need to keep the ability to
check the existing clusters. My gut feeling is this: keep t
Tom Lane wrote:
> Christopher Browne writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort.
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> On non-Windows servers you could get this even safer by disabling the
>> TCP/IP socket altogether, and placing the Unix-domain socket in a
>> private temporary directory. The "port" wouldn't actually matter then.
> Yes, it would be nice to just
Peter Eisentraut wrote:
> On ons, 2011-06-15 at 13:35 -0400, Bruce Momjian wrote:
> > I now believe we are overthinking all this. pg_upgrade has always
> > supported specification of a port number. Why not just tell users to
> > specify an unused port number > 1023, and not to use the default
> >
Tom Lane wrote:
> Christopher Browne writes:
> > On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> >> [ just recommend using a different port number during pg_upgrade ]
>
> > +1... That seems to have lots of nice properties.
>
> Yeah, that seems like an appropriate expenditure of effort.
On ons, 2011-06-15 at 13:35 -0400, Bruce Momjian wrote:
> I now believe we are overthinking all this. pg_upgrade has always
> supported specification of a port number. Why not just tell users to
> specify an unused port number > 1023, and not to use the default
> value? Both old and new clusters
Christopher Browne writes:
> On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
>> [ just recommend using a different port number during pg_upgrade ]
> +1... That seems to have lots of nice properties.
Yeah, that seems like an appropriate expenditure of effort. It's surely
not bulletproof,
On Wed, Jun 15, 2011 at 5:35 PM, Bruce Momjian wrote:
> This requires no new backend code. We could even _require_ the port
> number to be specified in pg_upgrade.
+1... That seems to have lots of nice properties.
--
When confronted by a difficult problem, solve it by reducing it to the
questi
Robert Haas wrote:
> > Also, a standalone backend does not have libpq either so how do you get
> > values into application variables? ?Parse the text output? ?That seems
> > like a much larger kludge.
>
> Maybe we could do something like this.
>
> 1. pg_upgrade invokes the postmaster with --binar
Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of mi?? jun 15 12:52:30 -0400 2011:
> > Alvaro Herrera writes:
> > > Excerpts from Robert Haas's message of mi?? jun 15 08:45:21 -0400 2011:
> > >> As a separate issue, I tend to agree with Tom that using psql as part
> > >> of the pg_upgrad
On Wed, Jun 15, 2011 at 1:13 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié jun 15 12:51:29 -0400 2011:
>> On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
>> wrote:
>
>> > Agreed on both counts ... but ... does this mean that we need a
>> > different program for programma
Excerpts from Tom Lane's message of mié jun 15 12:52:30 -0400 2011:
> Alvaro Herrera writes:
> > Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> >> As a separate issue, I tend to agree with Tom that using psql as part
> >> of the pg_upgrade process is a lousy idea and we n
Excerpts from Robert Haas's message of mié jun 15 12:51:29 -0400 2011:
> On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
> wrote:
> > Agreed on both counts ... but ... does this mean that we need a
> > different program for programmable tasks as opposed to interactive
> > ones? Dealing with sta
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
>> As a separate issue, I tend to agree with Tom that using psql as part
>> of the pg_upgrade process is a lousy idea and we need a better
>> solution. But let's fix one thing at a time.
> Agreed on
On Wed, Jun 15, 2011 at 12:12 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> Seems good, except that passing the password as a command line argument
> is obviously broken from a privacy perspective -- anyone could see the
> process list and get
Excerpts from Robert Haas's message of mié jun 15 08:45:21 -0400 2011:
> 1. pg_upgrade invokes the postmaster with --binary-upgrade=:
>
> 2. postmaster starts up into multi-user mode, but it does not start
> autovacuum and ignores pg_hba.conf, listen_addresses, and port.
> Instead it listens only
On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan wrote:
> What I actually had in mind was rather different: an HBA mechanism based on
> appname. But on second thoughts maybe the protocol wouldn't support that.
Ah, a similar thought struck me.
Independent of this particular feature, it would be r
On Wed, Jun 15, 2011 at 10:05 AM, Andrew Dunstan wrote:
> What I actually had in mind was rather different: an HBA mechanism based on
> appname. But on second thoughts maybe the protocol wouldn't support that.
Ah, a similar thought struck me.
Independent of this particular feature, it would be r
On 06/14/2011 11:01 PM, Bruce Momjian wrote:
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This
On Wed, Jun 15, 2011 at 8:05 AM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Tom Lane wrote:
>> > Bruce Momjian writes:
>> > > You might remember we added a postmaster/postgres -b switch to indicate
>> > > binary upgrade mode. The attached patch prevents any client without an
>> > > applicati
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > You might remember we added a postmaster/postgres -b switch to indicate
> > > binary upgrade mode. The attached patch prevents any client without an
> > > application_name of 'binary-upgrade' from connecting to the cluster
> >
Jesper Krogh wrote:
> On 2011-06-15 05:01, Bruce Momjian wrote:
> > You might remember we added a postmaster/postgres -b switch to indicate
> > binary upgrade mode. The attached patch prevents any client without an
> > application_name of 'binary-upgrade' from connecting to the cluster
> > while i
On 2011-06-15 05:01, Bruce Momjian wrote:
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This help
Tom Lane wrote:
> Bruce Momjian writes:
> > You might remember we added a postmaster/postgres -b switch to indicate
> > binary upgrade mode. The attached patch prevents any client without an
> > application_name of 'binary-upgrade' from connecting to the cluster
> > while it is binary upgrade mod
Bruce Momjian writes:
> You might remember we added a postmaster/postgres -b switch to indicate
> binary upgrade mode. The attached patch prevents any client without an
> application_name of 'binary-upgrade' from connecting to the cluster
> while it is binary upgrade mode. This helps prevent una
You might remember we added a postmaster/postgres -b switch to indicate
binary upgrade mode. The attached patch prevents any client without an
application_name of 'binary-upgrade' from connecting to the cluster
while it is binary upgrade mode. This helps prevent unauthorized users
from connecting
53 matches
Mail list logo
