Обсуждение: Is it possible to run multiple postmasters?
About 2 weeks ago, I reported a problem with 6.5.3 on Linux version 2.2.7-1.23smp (VA-Research). Basically, we have one gigabyte scale table that will not index on the text field, although it does index on a char(1) and a date field. We been unable to find the cause of the problem ourselves, and the user community and developers have not yet come up with a solution. So, as a work-around we contemplated running two postmasters on the same machine, with different ports and data directories - one would be 6.5.3 which has recent bug fixes that we like alot and a second which would be 6.5.1 which can successfully create the index that 6.5.3 cannot. I've been able to get both postmasters running, but the second one to start seems to interfere with operation of the first. So my quation is, can I run two postmasters simultaneously on the same machine? And if so, how? Kark DeBisschop
> > About 2 weeks ago, I reported a problem with 6.5.3 on Linux version > 2.2.7-1.23smp (VA-Research). Basically, we have one gigabyte scale > table that will not index on the text field, although it does index on > a char(1) and a date field. Sorry, I don't remember this. > > We been unable to find the cause of the problem ourselves, and the user > community and developers have not yet come up with a solution. > > So, as a work-around we contemplated running two postmasters on the > same machine, with different ports and data directories - one would be > 6.5.3 which has recent bug fixes that we like alot and a second which > would be 6.5.1 which can successfully create the index that 6.5.3 > cannot. It is very strange something would work on 6.5.1 and not on 6.5.3. The changes are _very_ small between the two releases, and I would doubt anything that would show up as a bug. > I've been able to get both postmasters running, but the second one to > start seems to interfere with operation of the first. So my quation > is, can I run two postmasters simultaneously on the same machine? > And if so, how? Yes you can. Use a postmaster parameter to specify a different port number, and use that port number in your connections. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
> From: Bruce Momjian <pgman@candle.pha.pa.us> > > KD> About 2 weeks ago, I reported a problem with 6.5.3 on Linux version > KD> 2.2.7-1.23smp (VA-Research). Basically, we have one gigabyte scale > KD> table that will not index on the text field, although it does index on > KD> a char(1) and a date field. > > Sorry, I don't remember this. I checked psql-bugs to be sure: >o From: Karl DeBisschop <kdebisschop@range.infoplease.com> >o To: pgsql-bugs@postgresql.org >o Subject: problem creating index in 6,5,3 >o Date: Fri, 17 Dec 1999 12:41:20 -0500 Tom Lane responded, but I've had no comments since I did what he recommended and posted results. Also (though this one is somehow not in the archive): >Date: Tue, 21 Dec 1999 08:16:11 -0500 >From: Karl DeBisschop <kdebisschop@alert.infoplease.com> >To: pgsql-general@postgresql.org >In-reply-to: <8703.945457153@sss.pgh.pa.us> (message from Tom Lane on Fri, 17 > Dec 1999 13:59:13 -0500) >Subject: [GENERAL] Cannot index large table in 6.5.3 on Linux >Reply-to: kdebisschop@alert.infoplease.com >Sender: owner-pgsql-general@postgresql.org I can send the complete text of these to you if you are interested, but I don't want to hit the mailing lists with somewhat lengthy messages that have already been posted once. > > We been unable to find the cause of the problem ourselves, and the user > > community and developers have not yet come up with a solution. > > > > So, as a work-around we contemplated running two postmasters on the > > same machine, with different ports and data directories - one would be > > 6.5.3 which has recent bug fixes that we like alot and a second which > > would be 6.5.1 which can successfully create the index that 6.5.3 > > cannot. > > It is very strange something would work on 6.5.1 and not on 6.5.3. The > changes are _very_ small between the two releases, and I would doubt > anything that would show up as a bug. Yes, it is strange. Nonetheless, it seems to be so. > > I've been able to get both postmasters running, but the second one to > > start seems to interfere with operation of the first. So my quation > > is, can I run two postmasters simultaneously on the same machine? > > And if so, how? > > Yes you can. Use a postmaster parameter to specify a different port > number, and use that port number in your connections. I have done that, but once the second postmaster is running, frontends (e.g., psql) seem to be unable to connect to the original postmaster: # sudo /etc/rc.d/init.d/postgresql start Checking postgresql installation: looks good! Starting postgresql service: postmaster [25125] # ps -fu postgres UID PID PPID C STIME TTY TIME CMD postgres 25125 1 0 13:52 ? 00:00:00 /usr/bin/postmaster -i -S -D/var/lib/pgsql # psql -l datname |datdba|encoding|datpath ---------+------+--------+--------- template1| 10002| 0|template1 test | 5313| 0|test regdb | 5313| 0|regdb biobase | 5313| 0|biobase task | 5313| 0|task feature | 5313| 0|feature id | 5313| 0|id (7 rows) # sudo /etc/rc.d/init.d/postgresql651 start Checking postgresql installation: looks good! Starting postgresql service: failed. # ps -fu postgres UID PID PPID C STIME TTY TIME CMD postgres 25125 1 0 13:52 ? 00:00:00 /usr/bin/postmaster -i -S -D/var/lib/pgsql postgres 27007 1 0 15:17 ? 00:00:00 /opt/postgresql/bin/postmaster -p 5433 -S -D/opt/postgresql/data # psql -l Connection to database 'template1' failed. connectDB() -- connect() failed: Connection refused Is the postmaster running at 'localhost' and accepting connections on Unix socket '5432'? # psql -p 5432 -l Connection to database 'template1' failed. connectDB() -- connect() failed: Connection refused Is the postmaster running at 'localhost' and accepting connections on Unix socket '5432'? # psql -p 5433 -l datname |datdba|encoding|datpath ---------+------+--------+--------- template1| 10002| 0|template1 (1 row) So I seem to be missing something (note that 'Starting postgresql service: failed.' is actually a failure of the RedHat-based init script, postmaster itself actually does start up as shown by the `ps ` output. Karl DeBisschop
> Yes you can. Use a postmaster parameter to specify a different port
> number, and use that port number in your connections.
What I was missing was that:
rm -f /tmp/.s.PGSQL.* > /dev/null
must be removed from thr redhat init script in order for the sockcts
to work correctly. The 6.5.1/6.5.3 workarond now seems viable.
Thanks.
Karl DeBisschop
Karl DeBisschop wrote: > > > Yes you can. Use a postmaster parameter to specify a different port > > number, and use that port number in your connections. > > What I was missing was that: > > rm -f /tmp/.s.PGSQL.* > /dev/null > > must be removed from thr redhat init script in order for the sockcts > to work correctly. The 6.5.1/6.5.3 workarond now seems viable. As a note, the RedHat init scripts shipped with the RPM's are not intended for 'special' applications such as this one -- however, I am working on a more generalized setup in the RPM's where multiple postmasters, etc, could be started. That rm -f is for cleanup purposes -- assuming a single postmaster, it works correctly. For multiple postmasters, it would need to be changed (assuming PGPORT= postmaster listen port): rm -f /tmp/.s.PGSQL.$(PGPORT) > /dev/null This way, the init script allows a postmaster to startup even if the restart is due to a system crash that would leave the .s.PGSQL.* files laying around. I'm assuming that you have all the paths set correctly for each copy of the postmaster, so that the 6.5.1 postmaster isn't trying to start a 6.5.3 backend, right? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> As a note, the RedHat init scripts shipped with the RPM's are not > intended for 'special' applications such as this one -- however, I am > working on a more generalized setup in the RPM's where multiple > postmasters, etc, could be started. Yup. I had to do slightly more than trivial mods to get the init script to work for the second postmaster. > That rm -f is for cleanup purposes -- assuming a single postmaster, it > works correctly. For multiple postmasters, it would need to be changed > (assuming PGPORT= postmaster listen port): > rm -f /tmp/.s.PGSQL.$(PGPORT) > /dev/null Once I saw it, it's purpose was relatively clear - One big plus about the redhat scripts is that their logic is pretty understandable. > This way, the init script allows a postmaster to startup even if the > restart is due to a system crash that would leave the .s.PGSQL.* files > laying around. Yup. > I'm assuming that you have all the paths set correctly for each copy of > the postmaster, so that the 6.5.1 postmaster isn't trying to start a > 6.5.3 backend, right? Hmmm. Very good point. Thanks. Karl DeBisschop
> Karl DeBisschop wrote: > > > > > Yes you can. Use a postmaster parameter to specify a different port > > > number, and use that port number in your connections. > > > > What I was missing was that: > > > > rm -f /tmp/.s.PGSQL.* > /dev/null > > > > must be removed from thr redhat init script in order for the sockcts > > to work correctly. The 6.5.1/6.5.3 workarond now seems viable. > > As a note, the RedHat init scripts shipped with the RPM's are not > intended for 'special' applications such as this one -- however, I am > working on a more generalized setup in the RPM's where multiple > postmasters, etc, could be started. snip snip... > I'm assuming that you have all the paths set correctly for each copy of > the postmaster, so that the 6.5.1 postmaster isn't trying to start a > 6.5.3 backend, right? For anyone following this topic, testing shows that postmaster invokes the postgres binary in the expected directory, even without explicitly setting the path. I'm not sure if this is always the case, or is an artifact of the fact that the init script specifies the full path. I see it as just another illustration of how much thought and effort has gone into making this a good product. Karl DeBisschop