Re: [PATCHES] [HACKERS] Fix PID file location?
Tom Lane wrote: > Bruce Momjian writes: > > Is reading postgresql.conf > > from pg_ctl without a parser really accurate? > > The brute-force solution is to duplicate guc-file.l. > > That seems pretty ugly but in the long run it might be the most > maintainable solution. We eventually gave up trying to have a > cut-rate SQL lexer in psql, and duplicated parser/scan.l. > Might be best to just go for that solution up front in this case. Added to TODO: > * Allow pg_ctl to work properly with configuration files located outside > the PGDATA directory > > pg_ctl can not read the pid file because it isn't located in the > config directory but in the PGDATA directory. The solution is to > allow pg_ctl to read and understand postgresql.conf to find the > data_directory value. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Fix PID file location?
Bruce Momjian writes: > Is reading postgresql.conf > from pg_ctl without a parser really accurate? The brute-force solution is to duplicate guc-file.l. That seems pretty ugly but in the long run it might be the most maintainable solution. We eventually gave up trying to have a cut-rate SQL lexer in psql, and duplicated parser/scan.l. Might be best to just go for that solution up front in this case. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Fix PID file location?
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote: > >> I really think we have only two choices: teach pg_ctl how to dig the > >> data directory location out of postgresql.conf, > > > I don't think this is extremely hard, isn't it? > > One small problem is that I think the current definition allows the data > directory to be specified relative to the original postmaster working > directory. Of course, that's not different from "-D ." on the > postmaster command line, so possibly the answer is "if you want to use > pg_ctl, don't do that". I don't see any way to accurately find the data directory location. Reading postgresql.conf is one way, but what if they set data_directory on the command line using postmaster -o? Is reading postgresql.conf from pg_ctl without a parser really accurate? Shame we can't attach and do "SHOW data_directory" on a backend. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Fix PID file location?
Alvaro Herrera <[EMAIL PROTECTED]> writes: > On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote: >> I really think we have only two choices: teach pg_ctl how to dig the >> data directory location out of postgresql.conf, > I don't think this is extremely hard, isn't it? One small problem is that I think the current definition allows the data directory to be specified relative to the original postmaster working directory. Of course, that's not different from "-D ." on the postmaster command line, so possibly the answer is "if you want to use pg_ctl, don't do that". regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Fix PID file location?
On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote: > I really think we have only two choices: teach pg_ctl how to dig the > data directory location out of postgresql.conf, I don't think this is extremely hard, isn't it? -- Alvaro Herrera () "El realista sabe lo que quiere; el idealista quiere lo que sabe" (Anónimo) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Fix PID file location?
Bruce Momjian writes: > I have generated the following patch that moves postmaster.pid into the > configuration directory. pg_ctl only knows about the configuration > directory because it can't read postgresql.conf, so it seems that is the > right place to move it. Unfortunately, that is *absolutely* unsafe. If we do that it will break the safety property that the lock file is meant to enforce in the first place, namely only one postmaster running in a given data directory. It's not too hard to imagine people getting burnt by that, either: initdb, create new config files in another directory, forget to remove the original postgresql.conf in the data directory, and you have every ingredient needed for disaster. Just start two postmasters with both direct and indirect -D arguments, and kaboom. > This patch does > require that the postgres unix user have write permission in the > configuration directory to create the pid file on startup. That assumption is unacceptable, too. One of the prime reasons for having config files somewhere else is that the somewhere else can be read-only, thus reducing your exposure in case of a security breach. (Otherwise, we could possibly fix this by generating a second postmaster.pid in the config directory.) I really think we have only two choices: teach pg_ctl how to dig the data directory location out of postgresql.conf, or revert the separate-config-file-location patch. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Fix PID file location?
Peter, > Files that are not actually configuration files, to be edited by users, > do not belong in the configuration directory. Do you have an alternate suggestion then? Current behavior is broken. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Fix PID file location?
Bruce Momjian said: > > I have generated the following patch that moves postmaster.pid into the > configuration directory. pg_ctl only knows about the configuration > directory because it can't read postgresql.conf, so it seems that is > the right place to move it. this seems wrong ... wouldn't it be better to teach pg_ctl at least enough about the config file to enable it to find the data dir? cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Fix PID file location?
Bruce Momjian wrote: > I have generated the following patch that moves postmaster.pid into > the configuration directory. pg_ctl only knows about the > configuration directory because it can't read postgresql.conf, so it > seems that is the right place to move it. Files that are not actually configuration files, to be edited by users, do not belong in the configuration directory. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Fix PID file location?
I have generated the following patch that moves postmaster.pid into the configuration directory. pg_ctl only knows about the configuration directory because it can't read postgresql.conf, so it seems that is the right place to move it. I have tested it and it seems to work. I would like to backpatch this to 8.0.X because it is currently broken without it. This patch does require that the postgres unix user have write permission in the configuration directory to create the pid file on startup. --- Josh Berkus wrote: > Hey, folks, > > I've noticed a problem with alternate PGDATA locations. Here's how to > reproduce: > > On 8.0.2 on RHAS4: > > 1) Initdb a directory (on my system, /pgdata/pgdata) > 2) Move the .conf files to an alternate location ( /etc/pgsql/) > 3) Set $PGDATA to the alternate location ( /etc/pgsql ) > 4) Edit postgresql.conf to support this file arrangement > data_directory = '/pgdata/pgdata' > 5) pg_ctl start PostgreSQL > 6) pg_ctl stop PostgreSQL > 7) Get an error: "No PID file found". > > The problem seems to be that pg_ctl expects the PID file to be in $PGDATA, > but > the file actually gets written by the postmaster to the actual data > directory. You can work around this by setting "external_pid_file", but this > then prevents you from using external_pid_file for another purpose. > > Seems like it should be a relatively easy fix, although I'm not sure whether > the postmaster should write the PID to $PGDATA, or whether pg_ctl should be > made to look in the right place. Probably the latter. --- > More about this: due to the PID file not being in the right place, pg_ctl stop > never reports success: > > waiting for postmaster to shut > down... failed > pg_ctl: postmaster does not shut down > > This appears to be because the duplicate PID in the conf directory is not > removed on shutdown. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 Index: doc/src/sgml/runtime.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v retrieving revision 1.321 diff -c -c -r1.321 runtime.sgml *** doc/src/sgml/runtime.sgml 25 May 2005 02:56:15 - 1.321 --- doc/src/sgml/runtime.sgml 27 May 2005 20:46:42 - *** *** 309,318 While the postmaster is running, its PID is stored in the file ! postmaster.pid in the data directory. This is ! used to prevent multiple postmaster processes ! running in the same data directory and can also be used for ! shutting down the postmaster process. --- 309,319 While the postmaster is running, its PID is stored in the file ! postmaster.pid in the data or configuration ! directory. This is used to prevent multiple ! postmaster processes running in the same data ! directory and can also be used for shutting down the ! postmaster process. *** *** 4933,4940 Alternatively, you can send the signal directly using kill. The PID of the postmaster process can be found using the ps program, or from the file !postmaster.pid in the data directory. For !example, to do a fast shutdown: $ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid` --- 4934,4941 Alternatively, you can send the signal directly using kill. The PID of the postmaster process can be found using the ps program, or from the file !postmaster.pid in the data or configuration directory. !For example, to do a fast shutdown: $ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid` Index: src/backend/bootstrap/bootstrap.c === RCS file: /cvsroot/pgsql/src/backend/bootstrap/bootstrap.c,v retrieving revision 1.204 diff -c -c -r1.204 bootstrap.c *** src/backend/bootstrap/bootstrap.c 6 May 2005 17:24:52 - 1.204 --- src/backend/bootstrap/bootstrap.c 27 May 2005 20:46:43 - *** *** 367,373 /* If standalone, create lockfile for data directory */ if (!IsUnderPostmaster) ! CreateDataDirLockFile(DataDir, false); SetProcessingMode(BootstrapProcessing); IgnoreSystemIndexes(true); --- 367,373 /* If standalone, create lockfile for data directory */ if (!IsUnderPostmaster) ! CreateDataDirLockFile(userDoption, false); SetProcessingMode(BootstrapProcessing); IgnoreSystemIndexes(true); In
