[BUGS] postgresql-[any version] from FreeBSD ports - startup problems after crash
Hello !
Server rebooted occasionally after power failure.
And I have stale postmaster.pid file, so postmaster didn't start with error
bill postgres[600]: [1-1] FATAL: file "postmaster.pid" already exists
I think startup script and/or pg_ctl have to be written to check if that
process really exists
and it is postmaster, so DBMS server starts after any hard reboot.
I changed the startup script block
postgresql_command()
{
su -l ${postgresql_user} -c "exec ${command} ${command_args}
${rc_arg}"
}
to
postgresql_cmd()
{
su -l ${postgresql_user} -c "exec ${command} ${command_args}
${rc_arg}"
}
postgresql_command()
{
if [ ".$1" = ".start" ]; then
pidfile="${postgresql_data}/postmaster.pid"
if [ -e ${pidfile} ]; then
#check if postmaster process really exists
pid_fromfile=`head -1 ${pidfile}`
real_pid=`ps ax | grep -v grep | grep postmaster
| grep ${postgresql_data} | awk '{print $1}'`
if [ "x${pid_fromfile}" = "x${real_pid}" ]; then
echo "Postmater for datadir
${postgresql_data} already run with pid $real_pid"
else
#we have stale pidfile, remove it
unlink $pidfile
#and run postmater safely
postgresql_cmd
fi
else
#.pid file not exists, clean startup
postgresql_cmd
fi
else
postgresql_cmd
fi
}
That I hope satisfy all cases with stale .pid file...
--
Ruslan A Dautkhanov
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [BUGS] SIGSEGV happens over once a day
On Thu, 11 May 2006, Richard Yen wrote: > I'm experiencing signal 11 (segmentation fault) failures on the > master node of a 3-node Slony-I cluster. In the past week, we've > averaged a little more than one segfault per day (11 times in the > past 10, including today). Any ideas what's going on? Looks like hardware error. Failed fan. Processor/RAM/HDD overheating. Try "memtest86" and "cpuburn" testing for several hours. Regards Tometzky -- ...although Eating Honey was a very good thing to do, there was a moment just before you began to eat it which was better than when you were... Winnie the Pooh ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2439: pgAdmin III v1.4.1 fails to compile with GCC 4.1.0
The following bug has been logged online: Bug reference: 2439 Logged by: Jason Kankiewicz Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Gentoo Linux ~amd64 Description:pgAdmin III v1.4.1 fails to compile with GCC 4.1.0 Details: "emerge =pgadmin3-1.4.1" produces the following errors with GCC 4.1.0: pgadmin3-1.4.1/src/include/pgSchema.h:88: error: extra qualification 'pgSchemaObject::' on member 'pgSchemaObject' pgadmin3-1.4.1/xtra/pgagent/include/connection.h:44: extra qualification 'DBConn::' on member 'DBConn' Removing the extra qualifications allows the build to succeed. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2436: cannot --enable-thread-safety on -lpthread host
The following bug has been logged online: Bug reference: 2436 Logged by: Paul Forgey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3 Operating system: Debian stable (sarge) Description:cannot --enable-thread-safety on -lpthread host Details: Linux supplies -lpthread. The configure script seems to only look for -lpthreads and then give up. I'm surprised to not find anything about this on the mailing list archives. configure:16421: checking for the pthreads library -lpthreads configure:16459: gcc -o conftest -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -D_GNU_SOURCEconftest.c -lpth reads -lz -lreadline -lcrypt -lresolv -lnsl -ldl -lm >&5 conftest.c: In function `main': conftest.c:124: warning: `th' might be used uninitialized in this function /usr/bin/ld: cannot find -lpthreads collect2: ld returned 1 exit status configure:16465: $? = 1 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2437: Rules for COPY
The following bug has been logged online: Bug reference: 2437 Logged by: Anton Fedorov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.3-3 Operating system: debian linux Description:Rules for COPY Details: Looks like COPY bypass rules 'ON INSERT INSTEAD'. I think, COPY .. FROM ... should be equal to INSERT INTO ... SELECT * FROM ... and be catched by INSERT rule. Otherwise, need to create new temporary table, load data into, INSERT .. SELECT ..., DROP TABLE, while it seems strange. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2438: error connect with odbc
The following bug has been logged online: Bug reference: 2438 Logged by: MATTASOGLIO DENIS Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: WINDOWS XP Description:error connect with odbc Details: Hello world i work with powerbuilder odbc and postgres i can't manage transaction properly and i got error message with odbc driver is somebody know the : CONN ERROR: func=PGAPI_GetInfo, desc='', errnum=215, errmsg='The buffer was too small for the InfoValue.' Thank's Global Options: Version='08.02.0002', fetch=100, socket=4096, unknown_sizes=0, max_varchar_size=254, max_longvarchar_size=8190 disable_optimizer=1, ksqo=0, unique_index=1, use_declarefetch=0 text_as_longvarchar=1, unknowns_as_longvarchar=0, bools_as_char=1 NAMEDATALEN=64 extra_systable_prefixes='dd_;', conn_settings='' conn_encoding='OTHER' [ PostgreSQL version string = '8.1.2' ] [ PostgreSQL version number = '8.1' ] conn=31a3df8, query='select oid, typbasetype from pg_type where typname = 'lo'' [ fetched 0 rows ] [ Large Object oid = -999 ] [ Client encoding = 'UTF8' (code = 6) ] conn=31a3df8, PGAPI_DriverConnect(out)='DSN=gc_pgsql;DATABASE=gc;SERVER=localhost;PORT=543 2;UID=postgres;PWD=;CA=d;A6=;A7=100;A8=4096;B0=254;B1=8190;BI=0;C2=d d_;;CX=1b50dbb;A1=7.4-1' CONN ERROR: func=PGAPI_GetInfo, desc='', errnum=215, errmsg='The buffer was too small for the InfoValue.' henv=31a3dc0, conn=31a3df8, status=1, num_stmts=16 sock=31a6920, stmts=31a8998, lobj_type=-999 Socket Info --- socket=532, reverse=0, errornumber=0, errormsg='(NULL)' buffer_in=52062600, buffer_out=52066704 buffer_filled_in=77, buffer_filled_out=0, buffer_read_in=77 conn=31a3df8, query='show max_identifier_length' [ fetched 1 rows ] conn=31a9338, PGAPI_DriverConnect( in)='DSN=gc_pgsql;UID=postgres;PWD=;', fDriverCompletion=1 DSN info: DSN='gc_pgsql',server='localhost',port='5432',dbase='gc',user='postgres',pas swd='x' onlyread='0',protocol='7.4',showoid='0',fakeoidindex='0',showsystable='0' conn_settings='',conn_encoding='OTHER' translation_dll='',translation_option='' Global Options: Version='08.02.0002', fetch=100, socket=4096, unknown_sizes=0, max_varchar_size=254, max_longvarchar_size=8190 disable_optimizer=1, ksqo=0, unique_index=1, use_declarefetch=0 text_as_longvarchar=1, unknowns_as_longvarchar=0, bools_as_char=1 NAMEDATALEN=64 extra_systable_prefixes='dd_;', conn_settings='' conn_encoding='OTHER' [ PostgreSQL version string = '8.1.2' ] [ PostgreSQL version number = '8.1' ] conn=31a9338, query='select oid, typbasetype from pg_type where typname = 'lo'' [ fetched 0 rows ] [ Large Object oid = -999 ] [ Client encoding = 'UTF8' (code = 6) ] conn=31a9338, PGAPI_DriverConnect(out)='DSN=gc_pgsql;DATABASE=gc;SERVER=localhost;PORT=543 2;UID=postgres;PWD=;CA=d;A6=;A7=100;A8=4096;B0=254;B1=8190;BI=0;C2=d d_;;CX=1b50dbb;A1=7.4-1' CONN ERROR: func=PGAPI_GetInfo, desc='', errnum=215, errmsg='The buffer was too small for the InfoValue.' henv=31a3dc0, conn=31a9338, status=1, num_stmts=16 sock=31a8ed8, stmts=31aef68, lobj_type=-999 Socket Info --- socket=540, reverse=0, errornumber=0, errormsg='(NULL)' buffer_in=52084320, buffer_out=53411912 buffer_filled_in=77, buffer_filled_out=0, buffer_read_in=77 conn=31a9338, query='show max_identifier_length' [ fetched 1 rows ] conn=31a9338, query='INSERT INTO public.gc_pc ( exr_id, pc_id, pc_typ, statut ) VALUES ( 8, 24312, 'AA', 'O' )' conn=31a9338, query='COMMIT' ---(end of broadcast)--- TIP 1: 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: [BUGS] BUG #2439: pgAdmin III v1.4.1 fails to compile with GCC 4.1.0
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jason Kankiewicz > Sent: 14 May 2006 17:08 > To: pgsql-bugs@postgresql.org > Subject: [BUGS] BUG #2439: pgAdmin III v1.4.1 fails to > compile with GCC 4.1.0 > > > The following bug has been logged online: > > Bug reference: 2439 > Logged by: Jason Kankiewicz > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: Gentoo Linux ~amd64 > Description:pgAdmin III v1.4.1 fails to compile with GCC 4.1.0 > Details: > > "emerge =pgadmin3-1.4.1" produces the following errors with GCC 4.1.0: > > pgadmin3-1.4.1/src/include/pgSchema.h:88: error: extra > qualification 'pgSchemaObject::' on member 'pgSchemaObject' > pgadmin3-1.4.1/xtra/pgagent/include/connection.h:44: extra > qualification 'DBConn::' on member 'DBConn' Thanks - these have been fixed for 1.4.2 and in SVN trunk: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi?rev=4900&view=rev Regards, Dave. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] postgresql-[any version] from FreeBSD ports - startup problems after crash
Ruslan A Dautkhanov <[EMAIL PROTECTED]> writes: > Server rebooted occasionally after power failure. > And I have stale postmaster.pid file, so postmaster didn't start with error > bill postgres[600]: [1-1] FATAL: file "postmaster.pid" already exists You probably need a newer postgres version (you didn't say what you are using) and/or a more carefully written start script. Your proposed change in the start script is useless --- do you think the postmaster doesn't check that already? Furthermore, it's actually dangerous for reasons we need not get into here; suffice to say that automated removal of that lock file is NOT a good idea. The problem comes up when the startup timing is just different enough that the PID belonging to the postmaster in the previous boot cycle now belongs to the shell that's launching it. The postmaster sees a live process of the correct userid (ie, postgres) and has to assume that that's a pre-existing postmaster. We've fixed this in recent releases by having the postmaster also check for a match to its parent process ID (getppid). The care in the start script comes because this only works for one level up. Therefore, you can't "su -c pg_ctl start ..." because that would create three levels of postgres-owned processes (shell, pg_ctl, postmaster) and if the PID count is off by 2 instead of 1 then we still lose. You have to invoke the postmaster directly, "su -c postmaster ...". (Hm, actually it might work to do "su -c 'exec pg_ctl ...'" ... I have not tried that.) regards, tom lane ---(end of broadcast)--- TIP 1: 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: [BUGS] BUG #2436: cannot --enable-thread-safety on -lpthread host
"Paul Forgey" <[EMAIL PROTECTED]> writes: > Linux supplies -lpthread. The configure script seems to only look for > -lpthreads and then give up. Say again? I get this configure trace on Fedora 4: checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking whether pthreads work with -pthreads... no checking whether pthreads work with -mthreads... no checking for the pthreads library -lpthread... yes checking whether pthreads work with --thread-safe... no checking whether pthreads work with -mt... no checking for the pthreads library -lpthreadGC2... no checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2437: Rules for COPY
"Anton Fedorov" <[EMAIL PROTECTED]> writes: > Looks like COPY bypass rules 'ON INSERT INSTEAD'. That's the documented behavior. We're unlikely to change it because it'd slow COPY down substantially, which'd negate its main use of being a bulk data loading mechanism. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2428: ERROR: out of memory, running INSERT SELECT
On Fri, May 12, 2006 at 08:04:20AM +0100, Simon Riggs wrote: > On Thu, 2006-05-11 at 20:14 -0400, Tom Lane wrote: > > Casey Duncan <[EMAIL PROTECTED]> writes: > > > On May 11, 2006, at 4:42 AM, Simon Riggs wrote: > > >> As your database is defined, this SQL statement will return > > >> approximately 4 trillion rows, by my calculation. As you say, it > > >> returns no rows at all when the database is empty. > > > > > *slaps forehead* I totally missed the "!=" in the where clause, Doh! > > > Thanks for hitting me with a clue-stick. > > > > I'm still wondering why you got "out of memory", though. I'd have > > expected that to grind for a really long time, gradually filling your > > disk, until you got an out-of-disk-space kind of error; if you didn't > > notice and stop it first. There aren't (supposed to be) any long-term > > memory leaks in query processing, other than than the known issue of > > pending trigger events, which you say you haven't got on this table. > > Seems broken either way, OOM or OOD. We need a way to stop runaway > queries from happening in the first place. Well, the question still remains, had they been trying this with a 100TB table, would it have actually worked, or is there some kind of overflow? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2431: Error:SELECT query has no destination for result data
On Thu, May 11, 2006 at 05:29:02AM +, bhavani wrote: > > The following bug has been logged online: > > Bug reference: 2431 > Logged by: bhavani > Email address: [EMAIL PROTECTED] > PostgreSQL version: postgresql 8.10 > Operating system: windowsxp > Description:Error:SELECT query has no destination for result data > Details: > > CREATE OR REPLACE FUNCTION insert_adv_exrate(IN comp_id int4, IN advid int4, > IN currid1 int4, OUT exid int4, OUT exrate float8) RETURNS record > AS $$ > /*$BODY$*/ > declare currid integer; > get_exdetails refcursor; > begin > select exid=max(ex_id) from adv_exrate where comp_id=comp_id and > adv_id=advid ; Here's your problem. That SELECT is going to return a boolean indicating if exid is equal to max(ex_id). But there's other issues here... > if(coalesce(exid,0)=0) then Why not just IF exid IS NULL THEN ? > exid:=1; > else > exid:=exid+1; > END if; > > open get_exdetails FOR > > select curr_id,exchange_rate from curr_master where comp_id=comp_id; > > LOOP FOR ... LOOP would be a bit easier to write than this. See http://lnk.nu/postgresql.org/9fr.html. But anytime you see a LOOP anywhere near a database you really need to be asking yourself if you're doing the right thing. See below. >FETCH get_exdetails into currid,exrate; Why are you fetching into an OUT parameter? This will only return the last row you fetched, which doesn't seem like a good idea... or are you sure only one row can come back? > > IF NOT FOUND THEN > EXIT; -- exit loop > END IF; > > >insert into adv_exrate values(exid,comp_id,advid,currid,exrate); > > END LOOP; > > CLOSE get_exdetails; A much more performant example of this would be: -- It can be very difficult to differentiate between plpgsql variables -- and field names, so use a prefix to avoid confusion. Likewise, you -- might want to preface all parameters with p_, or ALIAS them. DECLARE v_current_id int; BEGIN SELECT INTO v_current_id max(ex_id) FROM ... ; exid := COALESCE(v_current_id, 0) + 1; INSERT INTO adv_exrate (field list here) SELECT p_exid, p_comp_id, p_advid, curr_id, exchange_rate FROM curr_master WHERE comp_id = p_comp_id ; END; > select exrate=exchange_rate from curr_master where comp_id=comp_id and > curr_id=currid1; > > end; > > /*$BODY$*/ > $$ LANGUAGE 'plpgsql' VOLATILE; > ALTER FUNCTION insert_adv_exrate(IN comp_id int4, IN advid int4, IN currid1 > int4, OUT exid int4, OUT exrate float8) OWNER TO postgres; > > > - > > > CREATE OR REPLACE FUNCTION insert_adv_exrate(IN comp_id int4, IN advid int4, > IN currid1 int4, OUT exid int4, OUT exrate float8) RETURNS record > AS $$ > /*$BODY$*/ > declare currid integer; > get_exdetails refcursor; > begin > select exid=max(ex_id) from adv_exrate where comp_id=comp_id and > adv_id=advid ; > > if(coalesce(exid,0)=0) then > exid:=1; > else > exid:=exid+1; > END if; > > open get_exdetails FOR > > select curr_id,exchange_rate from curr_master where comp_id=comp_id; > > LOOP >FETCH get_exdetails into currid,exrate; > > IF NOT FOUND THEN > EXIT; -- exit loop > END IF; > > >insert into adv_exrate values(exid,comp_id,advid,currid,exrate); > > END LOOP; > > CLOSE get_exdetails; > > > select exrate=exchange_rate from curr_master where comp_id=comp_id and > curr_id=currid1; > > end; > > /*$BODY$*/ > $$ LANGUAGE 'plpgsql' VOLATILE; > > > i am using the above procedure in postgre sql. > theprocedure is execting successfully.but when i am giving select > insert_adv_exrate(2,1,2); it is giving error as > > > ERROR: SELECT query has no destination for result data > HINT: If you want to discard the results, use PERFORM instead. > CONTEXT: PL/pgSQL function "insert_adv_exrate" line 5 at SQL statement > > > How can i solve this problem > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings > -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 1: 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: [BUGS] BUG #2437: Rules for COPY
On Mon, May 15, 2006 at 09:50:57AM -0400, Tom Lane wrote: > "Anton Fedorov" <[EMAIL PROTECTED]> writes: > > Looks like COPY bypass rules 'ON INSERT INSTEAD'. > > That's the documented behavior. We're unlikely to change it because > it'd slow COPY down substantially, which'd negate its main use of being > a bulk data loading mechanism. http://pgfoundry.org/projects/pgloader/ might allow for using inserts and therefore firing ON INSERT rules. Another option is to COPY into a temporary table, and then to INSERT INTO. The problem with COPY not firing ON INSERT is that COPY is the only convenient way to load data in that doesn't already happen to be formatted as INSERT statements, so it would be nice if there was an option that allowed you to have it follow normal INSERT conventions. Or perhaps if there was a utility that allowed reading from an on-disk file as if it was a table... I know Oracle has that ability, maybe EnterpriseDB has it as well... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] postgresql-[any version] from FreeBSD ports - startup problems after crash
On Mon, May 15, 2006 at 09:23:33AM -0400, Tom Lane wrote:
> We've fixed this in recent releases by having the postmaster also check
> for a match to its parent process ID (getppid). The care in the start
> script comes because this only works for one level up. Therefore, you
> can't "su -c pg_ctl start ..." because that would create three levels of
> postgres-owned processes (shell, pg_ctl, postmaster) and if the PID
> count is off by 2 instead of 1 then we still lose. You have to invoke
> the postmaster directly, "su -c postmaster ...". (Hm, actually it might
> work to do "su -c 'exec pg_ctl ...'" ... I have not tried that.)
Except that the shell that's running su would be root, not pgsql, at
least in the case of FreeBSD. The guts of the current port's rc.d file
are:
su -l ${postgresql_user} -c "exec ${command} ${command_args} ${rc_arg}"
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] postgresql-[any version] from FreeBSD ports - startup problems after crash
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Except that the shell that's running su would be root, not pgsql, at
> least in the case of FreeBSD. The guts of the current port's rc.d file
> are:
> su -l ${postgresql_user} -c "exec ${command} ${command_args} ${rc_arg}"
Yeah, but what's the ${command} ?
If it's pg_ctl then all he's missing is the recent change to check
getppid. If it's execing postmaster directly then maybe we need
another theory.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] postgresql-[any version] from FreeBSD ports - startup problems after crash
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> Except that the shell that's running su would be root, not pgsql, at
>> least in the case of FreeBSD. The guts of the current port's rc.d
>> file are:
>
>> su -l ${postgresql_user} -c "exec ${command} ${command_args}
>> ${rc_arg}"
>
> Yeah, but what's the ${command} ?
>
> If it's pg_ctl then all he's missing is the recent change to check
> getppid. If it's execing postmaster directly then maybe we need
> another theory.
It's pg_ctl
command=${prefix}/bin/pg_ctl
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [BUGS] postgresql-[any version] from FreeBSD ports - startup problems after crash
On Mon, May 15, 2006 at 02:20:51PM -0500, Larry Rosenman wrote:
> > Yeah, but what's the ${command} ?
> >
> > If it's pg_ctl then all he's missing is the recent change to check
> > getppid. If it's execing postmaster directly then maybe we need
> > another theory.
>
> It's pg_ctl
>
> command=${prefix}/bin/pg_ctl
http://lnk.nu/freebsd.org/9fu.tmpl is the file in ports CVS.
http://jim.nasby.net/010.pgsql.sh.txt is the file as it exists on one of
my systems.
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Software http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2436: cannot --enable-thread-safety on -lpthread host
Paul Forgey <[EMAIL PROTECTED]> writes: > As given in my OS info, this isn't FC4. The configure script fails > to enable threading in Debian Sarge. The point is that the configure script clearly does test for -lpthread, so whatever problem you're having, you've not described it correctly. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] postgresql-[any version] from FreeBSD ports - startup
Hello ! Tom Lane wrote: Ruslan A Dautkhanov <[EMAIL PROTECTED]> writes: Server rebooted occasionally after power failure. And I have stale postmaster.pid file, so postmaster didn't start with error bill postgres[600]: [1-1] FATAL: file "postmaster.pid" already exists You probably need a newer postgres version (you didn't say what you are using) and/or a more carefully written start script. I hane FreeBSD 6.0-STABLE and PostgreSQL 8.1.3 on i386-portbld-freebsd6.0, compiled by GCC cc (GCC) 3.4.4 [FreeBSD]. As I said, PostgreSQL was built from freebsd ports, so startup script is also from ports... Your proposed change in the start script is useless --- do you think the postmaster doesn't check that already? Furthermore, it's actually dangerous for reasons we need not get into here; suffice to say that automated removal of that lock file is NOT a good idea. I know that this is not a good idea, but if it'll keep startup process stable, it have rights to exist... The problem comes up when the startup timing is just different enough that the PID belonging to the postmaster in the previous boot cycle now belongs to the shell that's launching it. The postmaster sees a live process of the correct userid (ie, postgres) and has to assume that that's a pre-existing postmaster. We've fixed this in recent releases by having the postmaster also check for a match to its parent process ID (getppid). The care in the start script comes because this only works for one level up. Therefore, you can't "su -c pg_ctl start ..." because that would create three levels of postgres-owned processes (shell, pg_ctl, postmaster) and if the PID count is off by 2 instead of 1 then we still lose. You have to invoke the postmaster directly, "su -c postmaster ...". (Hm, actually it might work to do "su -c 'exec pg_ctl ...'" ... I have not tried that.) Thank you for the information, I'll play with it and try to avoid big if-if-if block in the startup script... -- best regards, Ruslan A Dautkhanov smime.p7s Description: S/MIME Cryptographic Signature
