Bruce Momjian wrote:
> I think you should just edit the TODO wiki and list all the things
> we agree need fixing:
Done, although with the wealth of opinions and dearth of agreement I
referenced much material and said that more discussion was needed
before starting development. If anyone figur
Bruce Momjian wrote:
> I think you should just edit the TODO wiki and list all the things
> we agree need fixing
Will do. It may take me a while to chase down all the issues from
the LSB script work.
If I recall correctly, some of what I was looking at seems necessary
for a well-behaved LSB
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > Was this ever addressed?
>
> It should probably be on the TODO list. I was going to try to do
> this along with other items which came out of generating an LSB
> conforming init script, but have been pulled in different directions
> for now.
Bruce Momjian wrote:
> Was this ever addressed?
It should probably be on the TODO list. I was going to try to do
this along with other items which came out of generating an LSB
conforming init script, but have been pulled in different directions
for now. When I get the time I've been intendi
Was this ever addressed?
---
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> I'm not sure whether we'd want to provide a function within libpq
> >> for this, or just code it in pg_ctl.
>
> > I'm incli
On Fri, Oct 16, 2009 at 2:04 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> UUIDs throw away 6 bits?
>
> http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29
How about that. You learn something new every day.
...Robert
--
Sent via pgsql-bugs mailing list (pg
Robert Haas wrote:
> UUIDs throw away 6 bits?
http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Oct 16, 2009 at 11:08 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Well, then Tom's idea of using a random number seems pretty solid no
>> matter how you slice it. Maybe a UUID.
>
> A random number is looking like the best option. I'm not sure why I'd
> want to generate a perfect
Tom Lane wrote:
> Alternatively, do the postmaster support and make the
> presumably-minor pg_ctl mods to use it, and then a standalone
> pg_ping utility could come later. I'm not sure how big the utility
> would be, but surely bigger than the delta in pg_ctl.
Bigger than the delta for *just
"Kevin Grittner" writes:
> It seems like pg_ping (client utility and related postmaster support)
> should be a discrete patch. Improvements to pg_ctl and init scripts
> would come later, as separate patches?
Sounds sane to me. Alternatively, do the postmaster support and make
the presumably-min
Tom Lane wrote:
> I was envisioning just using PostmasterRandom() (after initializing
> the seed from time(NULL) as we do now). I don't think we need a
> super-wide random number.
Fine with me. Just that and CanAcceptConnections in the response?
It seems like pg_ping (client utility and re
"Kevin Grittner" writes:
> Robert Haas wrote:
>> Well, then Tom's idea of using a random number seems pretty solid no
>> matter how you slice it. Maybe a UUID.
> A random number is looking like the best option. I'm not sure why I'd
> want to generate a perfectly good 128 bit random number and
Robert Haas wrote:
> Well, then Tom's idea of using a random number seems pretty solid no
> matter how you slice it. Maybe a UUID.
A random number is looking like the best option. I'm not sure why I'd
want to generate a perfectly good 128 bit random number and then throw
away six of the bits
On Fri, Oct 16, 2009 at 10:33 AM, Kevin Grittner
wrote:
> Pedro Gimeno wrote:
>> Tom Lane wrote:
>>
>>> This could be addressed by having the postmaster report its $PGDATA
>>> value in the pg_ping response, but I would be against that on
>>> security grounds. We don't let nonprivileged users kno
Pedro Gimeno wrote:
> Tom Lane wrote:
>
>> This could be addressed by having the postmaster report its $PGDATA
>> value in the pg_ping response, but I would be against that on
>> security grounds. We don't let nonprivileged users know where
>> PGDATA is, why would we make the information availab
Tom Lane wrote:
This could be addressed by having the postmaster report its $PGDATA
value in the pg_ping response, but I would be against that on security
grounds. We don't let nonprivileged users know where PGDATA is, why
would we make the information available without any authentication at
al
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I'm not sure whether we'd want to provide a function within libpq
>> for this, or just code it in pg_ctl.
> I'm inclined to think there would be value to a pg_ping utility to
> support automated monitoring by unprivileged users on other boxes.
True
Tom Lane wrote:
> I'm not sure whether we'd want to provide a function within libpq
> for this, or just code it in pg_ctl.
I'm inclined to think there would be value to a pg_ping utility to
support automated monitoring by unprivileged users on other boxes.
That both suggests libpq as the locat
"Kevin Grittner" writes:
> Tom Lane wrote:
>> [ thinks... ] Maybe we could have the postmaster generate a random
>> number at start and include that in both the postmaster.ports file
>> and its pg_ping responses.
> Unless two postmasters could open the same server socket within a
> microsecond
"Kevin Grittner" writes:
> Sounds good to me, other than it stalls pg_ctl revamp until pg_ping is
> done. I don't remember a clear design of what pg_ping should look
> like. Does anyone have a clear plan in their head?
I don't think anyone's written down a full spec, but it seems like a
relativ
Tom Lane wrote:
> [ thinks... ] Maybe we could have the postmaster generate a random
> number at start and include that in both the postmaster.ports file
> and its pg_ping responses. That would have a substantially lower
> collision probability than PID, if the number generation process
> were
I wrote:
> "Kevin Grittner" writes:
>> ... This would allow pg_ctl or a script to
>> connect to a port and see if it is the expected postmaster process.
> I would rather see us implement the hypothetical pg_ping protocol
> and remember to include the postmaster's PID in the response.
Although on
Tom Lane wrote:
> I would rather see us implement the hypothetical pg_ping protocol
> and remember to include the postmaster's PID in the response. One
> of the worst misfeatures of pg_ctl is the need to be able to
> authenticate itself to the postmaster, and having it rely on being
> able to a
"Kevin Grittner" writes:
> Hmmm... On review, I see that I assumed that the -w switch on pg_ctl
> start would cover this. I see that the problem is that this uses psql
> to connect to the specified port. Besides the problems Tom mentioned
> with its heuristics to find the right port number for
"Kevin Grittner" wrote:
> I neglected that point in my recently proposed LSB conforming script
Hmmm... On review, I see that I assumed that the -w switch on pg_ctl
start would cover this. I see that the problem is that this uses psql
to connect to the specified port. Besides the problems To
Kevin Grittner wrote:
> This seems likely to overlap the review I was soon going to do of the
> differences between pg_ctl behavior and what is required for LSB
> conformance. I'll make sure to test this behavior along with others.
> One of my current complaints is that pg_ctl doesn't wait until
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Suppose that after the postmaster is fully up, it writes a file
>> $PGDATA/postmaster.ports, with contents along the lines of
>>
>> 5432
>> /tmp/.s.PGSQL.5432
> The listen_addresses setting would need to figure in, too.
Yeah, I'm not entirely sure
Tom Lane wrote:
> Well, it's arguably a start-script bug
OK.
> While mulling that it occurred to me that some additional output
> from the postmaster would help to solve another thing that's an
> acknowledged shortcoming of pg_ctl, namely that it can't parse
> postgresql.conf to find out whe
"Kevin Grittner" writes:
> "Gerhard Leykam" wrote:
>> I am using a start script to set up my PostgreSQL database: it runs
>> initdb, if not done yet, starts the instance with pg_ctl start and
>> checks everything is fine by pg_ctl status.
>>
>> If there is another PostgreSQL database on the sam
"Gerhard Leykam" wrote:
> I am using a start script to set up my PostgreSQL database: it runs
> initdb, if not done yet, starts the instance with pg_ctl start and
> checks everything is fine by pg_ctl status.
>
> If there is another PostgreSQL database on the same machine
> listening to the sa
The following bug has been logged online:
Bug reference: 5118
Logged by: Gerhard Leykam
Email address: gel...@sealsystems.de
PostgreSQL version: 8.4.0
Operating system: linux
Description:start-status-insert-fatal
Details:
Hi!
I am using a start script to set up my
31 matches
Mail list logo
