Re: pg_ctl and port number detection

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_ctl and port number detection
Date: 2010-12-21 00:51:36
Message-ID: 201012210051.oBL0paA00448@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> No. If it goes in, it should go in as the third line. The shmem key
> >> data is private to the server --- we do not want external programs
> >> assuming anything at all about the private part of postmaster.pid.
>
> > OK, so you are suggesting having it as a third value on the third line?
>
> > 10231
> > /u/pgsql/data
> > 5432001 45481984 port_here
> > ^^^^^^^^^
>
> I'm not sure why you're having such a hard time grasping this concept.
> We do not want pg_ctl looking at the shmem key information, not even to
> the extent of assuming a particular format for it. Therefore the port
> number has to go before it not after it. What I'm thinking of is
>
> pid
> datadir
> port
> ... here be dragons ...
>
> Actually, if we're going to do this at all, we should do
>
> pid
> datadir
> port
> socketdir
> ... here be dragons ...
>
> so that pg_ctl doesn't have to assume the server is running with a
> default value of unix_socket_dir. Not sure what to put in the fourth
> line on Windows though ... maybe just leave it empty?

OK. I was hesitant to modify the existing postmaster.pid format and was
trying to just add on the end. It is certainly easier to put it before
the shared memory stuff. I will work on a patch.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2010-12-21 01:16:30 Re: Extensions, patch 22 (cleanup, review, cleanup)
Previous Message Florian Pflug 2010-12-21 00:19:57 Re: serializable lock consistency