Re: TODO item for pg_ctl and server detection - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TODO item for pg_ctl and server detection
Date
Msg-id 5396.1293483768@sss.pgh.pa.us
Whole thread Raw
In response to TODO item for pg_ctl and server detection  (Bruce Momjian <bruce@momjian.us>)
Responses Re: TODO item for pg_ctl and server detection
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> While I am working on pg_ctl, I saw this TODO item:
>     Have the postmaster write a random number to a file on startup that
>     pg_ctl checks against the contents of a pg_ping response on its initial
>     connection (without login)
>         This will protect against connecting to an old instance of the
>     postmaster in a different or deleted subdirectory. 

>     http://archives.postgresql.org/pgsql-bugs/2009-10/msg00110.php
>     http://archives.postgresql.org/pgsql-bugs/2009-10/msg00156.php

> Based on our new PQPing(), do we ever want to implement this or should I
> remove the TODO item?  It seems this would require a server connection,
> which is something we didn't want to force pg_ctl -w to do in case
> authentication is broken.

Well, rereading that old thread makes me realize that what you just
implemented is still pretty far short of what was discussed.  In
particular, this implementation entirely fails to cope with the
possibility that a Windows postmaster is using a specialized
listen_addresses setting that has to be taken into account in order to
get a TCP connection.  I wonder whether we should revert this patch and
have another go at the idea of a separate postmaster.ports status file
with a line for each active port.

The business with a magic number can't be implemented unless we actually
add a new separate pg_ping protocol.  PQping() has removed a lot of the
pressure to have that, namely all the authentication-failure problem
cases.  I'm not sure that the case where you're looking at an inactive
data directory but there's a live postmaster someplace else with the
same port number is important enough to justify new protocol all by
itself.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Николай Ижиков
Date:
Subject: Re: Archlinux, ossp-uuid
Next
From: Magnus Hagander
Date:
Subject: Re: Streaming replication as a separate permissions