Re: [HACKERS] pg_ctl -w vs unix_socket_directory
On 19/09/2007, Tom Lane [EMAIL PROTECTED] wrote: Radoslaw Zielinski [EMAIL PROTECTED] writes: pg_ctl -w -D ... start doesn't work when unix_socket_directory is set to somewhere else than the compiled in default (/tmp). pg_ctl not working is going to be the very least of your worries; pretty much nothing else will either. If you want some other socket directory, I strongly recommend setting [...] I don't want any other socket directory. All I want is a way to create a working startup script: able to start/stop the server regardless of changes in postgresql.conf and report the success or failure. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] pg_ctl -w vs unix_socket_directory
On Tue, 2007-09-18 at 19:13 -0400, Tom Lane wrote: Radoslaw Zielinski [EMAIL PROTECTED] writes: pg_ctl -w -D ... start doesn't work when unix_socket_directory is set to somewhere else than the compiled in default (/tmp). pg_ctl not working is going to be the very least of your worries; pretty much nothing else will either. If you mean client applications won't work, that would be expected from such a change to the server configuration. If you want some other socket directory, I strongly recommend setting the path to it at compile time so that it's properly wired into libpq. AFAICS the only value in specifying unix_socket_directory at server start is if you actually *want* a stealth server that won't be found by clients without manual intervention. Those arguments apply almost as well to the server port. The server port is read from the postgresql.conf from pg_ctl, but not the socket directory. It's an annoyance: if you change the default socket directory, you're probably going to break your init script (on FreeBSD you will, because it uses -w). I don't think that's the expected result, and it's not intuitive to find the cause of the problem. I think the inconsistency between server port number and socket directory is less than ideal. However, I also don't feel very strongly about it. It's rare, and a there are plenty of workarounds. Regards, Jeff Davis ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] pg_ctl -w vs unix_socket_directory
Hello, pg_ctl -w -D ... start doesn't work when unix_socket_directory is set to somewhere else than the compiled in default (/tmp). Having this is useful for the startup scripts, so the status DONE actually means success, instead of maybe. Jeff Davis wrote about it a while ago: http://svr5.postgresql.org/pgsql-general/2006-09/msg01141.php Simple hacky patch for v8.2.5; maybe someone finds it useful before the proper config parser is integrated: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/postgresql-pg_ctl-fix.patch?rev=HEAD -- Radosław Zieliński [EMAIL PROTECTED] pgpOSbaPWUgyJ.pgp Description: PGP signature
Re: [HACKERS] pg_ctl -w vs unix_socket_directory
This has a trivial workaround - just set PGHOST for pg_ctl: [EMAIL PROTECTED] inst.codfix.5705]$ PGHOST=/home/andrew/pgl/inst.codfix.5705 bin/pg_ctl -D data/ -l logfile -w start waiting for server to start done server started [EMAIL PROTECTED] inst.codfix.5705]$ cheers andrew Radoslaw Zielinski wrote: Hello, pg_ctl -w -D ... start doesn't work when unix_socket_directory is set to somewhere else than the compiled in default (/tmp). Having this is useful for the startup scripts, so the status DONE actually means success, instead of maybe. Jeff Davis wrote about it a while ago: http://svr5.postgresql.org/pgsql-general/2006-09/msg01141.php Simple hacky patch for v8.2.5; maybe someone finds it useful before the proper config parser is integrated: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/postgresql-pg_ctl-fix.patch?rev=HEAD ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_ctl -w vs unix_socket_directory
Andrew Dunstan [EMAIL PROTECTED] [18-09-2007 23:42]: This has a trivial workaround - just set PGHOST for pg_ctl: [EMAIL PROTECTED] inst.codfix.5705]$ PGHOST=/home/andrew/pgl/inst.codfix.5705 bin/pg_ctl -D data/ -l logfile -w start That would be fine for a particular installation, but isn't really suitable for a startup script shipped with a linux distribution. Sure, a /bin/sh-based postgresql.conf parser could do the trick... but I just don't feel like writing one. :-) -- Radosław Zieliński [EMAIL PROTECTED] pgp0f1LJEqQPz.pgp Description: PGP signature
Re: [HACKERS] pg_ctl -w vs unix_socket_directory
Radoslaw Zielinski [EMAIL PROTECTED] writes: pg_ctl -w -D ... start doesn't work when unix_socket_directory is set to somewhere else than the compiled in default (/tmp). pg_ctl not working is going to be the very least of your worries; pretty much nothing else will either. If you want some other socket directory, I strongly recommend setting the path to it at compile time so that it's properly wired into libpq. AFAICS the only value in specifying unix_socket_directory at server start is if you actually *want* a stealth server that won't be found by clients without manual intervention. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] pg_ctl -w vs unix_socket_directory
Radoslaw Zielinski wrote: Andrew Dunstan [EMAIL PROTECTED] [18-09-2007 23:42]: This has a trivial workaround - just set PGHOST for pg_ctl: [EMAIL PROTECTED] inst.codfix.5705]$ PGHOST=/home/andrew/pgl/inst.codfix.5705 bin/pg_ctl -D data/ -l logfile -w start That would be fine for a particular installation, but isn't really suitable for a startup script shipped with a linux distribution. Sure, a /bin/sh-based postgresql.conf parser could do the trick... but I just don't feel like writing one. :-) I think it's broken for a distro to ship with config files setting a socket dir other than the one they compile in. If you don't like /tmp compile in something else. The you don't need to parse anything. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
