Re: [HACKERS] v10 pg_ctl compatibility
On Tue, Sep 26, 2017 at 4:31 PM, Tom Lane wrote: > Jeff Janes writes: > > I was not using -l. Instead I set logging_collector=on in > postgresql.conf, > > but I suppose that that is not sufficent? > > No, because initial stderr is still connected to whatever. > > > But I just retried with -l, and it still gets the fast shutdown. > > Hmph. Doesn't work that way for me on RHEL6, which surely oughta > behave the same as your CentOS. > > regards, tom lane > I happened to have a virgin install of CentOS7 here, so I tried it on that. I installed 9.2 and 10rc1 from repositories (CentOS and PGDG, respectively) rather than from source, and repeated it and still got the fast shutdown when hitting ctrl-C when 10rc1 has restarted the 9.2 server. I did the initdb, start, and restart from pg_ctl, not from whatever management tool comes with the packages. I did it both with the database running as OS user jjanes, and separately running as OS user 'postgres', so it doesn't seem to matter whether uid is high or low. And with '-l logfile'. So, I don't know. Cheers, Jeff
Re: [HACKERS] v10 pg_ctl compatibility
Jeff Janes writes: > I was not using -l. Instead I set logging_collector=on in postgresql.conf, > but I suppose that that is not sufficent? No, because initial stderr is still connected to whatever. > But I just retried with -l, and it still gets the fast shutdown. Hmph. Doesn't work that way for me on RHEL6, which surely oughta behave the same as your CentOS. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] v10 pg_ctl compatibility
On Tue, Sep 26, 2017 at 3:54 PM, Tom Lane wrote: > Jeff Janes writes: > > On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote: > >> Really? The server should have detached itself from your terminal > >> group long before that. What platform is this? > > > CentOS release 6.9 (Final) > > Hm, same as here. Are you perhaps not using pg_ctl's -l option? > If not, the postmaster's stderr would remain attached to your tty, > which might be the reason why a terminal ^C affects it. > I was not using -l. Instead I set logging_collector=on in postgresql.conf, but I suppose that that is not sufficent? But I just retried with -l, and it still gets the fast shutdown. Cheers, Jeff
Re: [HACKERS] v10 pg_ctl compatibility
On 2017-09-26 18:54:17 -0400, Tom Lane wrote: > Jeff Janes writes: > > On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote: > >> Really? The server should have detached itself from your terminal > >> group long before that. What platform is this? > > > CentOS release 6.9 (Final) > > Hm, same as here. Are you perhaps not using pg_ctl's -l option? > If not, the postmaster's stderr would remain attached to your tty, > which might be the reason why a terminal ^C affects it. Doesn't make a difference here (Debian sid), I see postgres get SIGTERMed either way. GDBing in and doing a setsid() in postmaster before ctrl-c'ing pg_ctl "fixes" it. Is there a reason we're not doing so after the fork in pg_ctl? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] v10 pg_ctl compatibility
Jeff Janes writes: > On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote: >> Really? The server should have detached itself from your terminal >> group long before that. What platform is this? > CentOS release 6.9 (Final) Hm, same as here. Are you perhaps not using pg_ctl's -l option? If not, the postmaster's stderr would remain attached to your tty, which might be the reason why a terminal ^C affects it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] v10 pg_ctl compatibility
On 2017-09-26 15:15:39 -0700, Jeff Janes wrote: > On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote: > > > Jeff Janes writes: > > > To add insult to injury, when v10 pg_ctl does restart a pre-10 server and > > > it sits there for a long time waiting for it to start up even though it > > has > > > already started up, if I hit ctrl-C because I assume something is > > horribly > > > wrong, it then goes ahead and kills the successfully started-and-running > > > server. > > > > Really? The server should have detached itself from your terminal > > group long before that. What platform is this? > > > > > CentOS release 6.9 (Final) > > The sever log file (9.6) says: > > >64926 2017-09-26 13:56:38.284 PDT LOG: database system was shut down > at 2017-09-26 13:56:37 PDT >64926 2017-09-26 13:56:38.299 PDT LOG: MultiXact member wraparound > protections are now enabled >64930 2017-09-26 13:56:38.311 PDT LOG: autovacuum launcher started >64924 2017-09-26 13:56:38.313 PDT LOG: database system is ready to > accept connections > ... hit ctrl-C >64924 2017-09-26 13:56:47.237 PDT LOG: received fast shutdown request >64924 2017-09-26 13:56:47.237 PDT LOG: aborting any active transactions >64930 2017-09-26 13:56:47.244 PDT LOG: autovacuum launcher shutting > down >64927 2017-09-26 13:56:47.261 PDT LOG: shutting down > ... It's reproducible here. Postmaster never calls setsid() for itself, nor does pg_ctl for it, therefore ctrl-c's SIGTERM to pg_ctl also go to its children, namely postmaster. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] v10 pg_ctl compatibility
On Tue, Sep 26, 2017 at 1:10 PM, Tom Lane wrote: > Jeff Janes writes: > > To add insult to injury, when v10 pg_ctl does restart a pre-10 server and > > it sits there for a long time waiting for it to start up even though it > has > > already started up, if I hit ctrl-C because I assume something is > horribly > > wrong, it then goes ahead and kills the successfully started-and-running > > server. > > Really? The server should have detached itself from your terminal > group long before that. What platform is this? > CentOS release 6.9 (Final) The sever log file (9.6) says: 64926 2017-09-26 13:56:38.284 PDT LOG: database system was shut down at 2017-09-26 13:56:37 PDT 64926 2017-09-26 13:56:38.299 PDT LOG: MultiXact member wraparound protections are now enabled 64930 2017-09-26 13:56:38.311 PDT LOG: autovacuum launcher started 64924 2017-09-26 13:56:38.313 PDT LOG: database system is ready to accept connections ... hit ctrl-C 64924 2017-09-26 13:56:47.237 PDT LOG: received fast shutdown request 64924 2017-09-26 13:56:47.237 PDT LOG: aborting any active transactions 64930 2017-09-26 13:56:47.244 PDT LOG: autovacuum launcher shutting down 64927 2017-09-26 13:56:47.261 PDT LOG: shutting down ... I can try a different platform (ubuntu 16.04, probably) tonight and see if it does the same thing. Cheers, Jeff
Re: [HACKERS] v10 pg_ctl compatibility
Jeff Janes writes: > To add insult to injury, when v10 pg_ctl does restart a pre-10 server and > it sits there for a long time waiting for it to start up even though it has > already started up, if I hit ctrl-C because I assume something is horribly > wrong, it then goes ahead and kills the successfully started-and-running > server. Really? The server should have detached itself from your terminal group long before that. What platform is this? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] v10 pg_ctl compatibility
On Tue, Sep 26, 2017 at 12:29 PM, Andres Freund wrote: > Hi, > > On 2017-09-26 11:59:42 -0700, Jeff Janes wrote: > > Should the release notes have a compatibility entry about pg_ctl restart, > > being used against a running pre-10 server, no longer being able to > detect > > when startup is complete? > > > > I don't know if cross-version use of pg_ctl restart was ever officially > > supported, but the current behavior is rather confusing (waiting for a > long > > time, and then reporting failure, even though it started successfully). > > I'm actually tempted to just make pg_ctl verify the right version of > postgres is being used. Maybe I'm missing something, but what's the > use-case for allowing it, and every couple releases have some breakage? > The use case for me is that I have multiple versions of postgres running on the same machine, and don't want check which pg_ctl is in my path each time I change one of their configurations and need to restart it. Or at least, I never had to check before, as pg_ctl goes out of its way to restart it with the same bin/postgres that the server is currently running with, rather than restarting with the bin/postgres currently in the path, or whichever bin/postgres is in the same directory as the bin/pg_ctl. (Which is itself not an unmitigated win, but it is what I'm used to). Admittedly, this is a much bigger problem with hacking/testing than it is with production use, but still I do have production machines with mixed versions running, and can see myself screwing this up a few times once one of them gets upgraded to v10, even with an incompatibility warning in the release notes. But at least I had fair warning. To add insult to injury, when v10 pg_ctl does restart a pre-10 server and it sits there for a long time waiting for it to start up even though it has already started up, if I hit ctrl-C because I assume something is horribly wrong, it then goes ahead and kills the successfully started-and-running server. If we do want to do a version check and fail out, I think it should check before shutting it down, rather than shutting it down and then refusing to start. Cheers, Jeff
Re: [HACKERS] v10 pg_ctl compatibility
On 2017-09-26 15:40:39 -0400, Tom Lane wrote: > I'm not really feeling the need to insert a version check though. It's only a mild preference here. > Also, what would you check exactly? Inquiring into what > "postgres --version" returns is not very conclusive about what is > actually running in the data directory pg_ctl has been pointed at. Reading PG_VERSION ought to do the trick. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] v10 pg_ctl compatibility
Andres Freund writes: > On 2017-09-26 11:59:42 -0700, Jeff Janes wrote: >> I don't know if cross-version use of pg_ctl restart was ever officially >> supported, but the current behavior is rather confusing (waiting for a long >> time, and then reporting failure, even though it started successfully). > I'm actually tempted to just make pg_ctl verify the right version of > postgres is being used. Maybe I'm missing something, but what's the > use-case for allowing it, and every couple releases have some breakage? At a high level the use case is yum upgrade postgresql service postgresql restart In practice, that wouldn't work across a major-version upgrade anyway, because of data directory incompatibility. It should work for minor versions though, so the version check couldn't be strict. I'm not really feeling the need to insert a version check though. It seems like it's more likely to reject cases that would have worked than to do anything helpful. The API that pg_ctl relies on is one that we don't change very often, viz the contents of postmaster.pid. The fact that we did change it this time is the source of Jeff's surprise. Also, what would you check exactly? Inquiring into what "postgres --version" returns is not very conclusive about what is actually running in the data directory pg_ctl has been pointed at. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] v10 pg_ctl compatibility
Hi, On 2017-09-26 11:59:42 -0700, Jeff Janes wrote: > Should the release notes have a compatibility entry about pg_ctl restart, > being used against a running pre-10 server, no longer being able to detect > when startup is complete? > > I don't know if cross-version use of pg_ctl restart was ever officially > supported, but the current behavior is rather confusing (waiting for a long > time, and then reporting failure, even though it started successfully). I'm actually tempted to just make pg_ctl verify the right version of postgres is being used. Maybe I'm missing something, but what's the use-case for allowing it, and every couple releases have some breakage? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] v10 pg_ctl compatibility
Should the release notes have a compatibility entry about pg_ctl restart, being used against a running pre-10 server, no longer being able to detect when startup is complete? I don't know if cross-version use of pg_ctl restart was ever officially supported, but the current behavior is rather confusing (waiting for a long time, and then reporting failure, even though it started successfully). Cheers, Jeff