[BUGS] psql: FATAL: the database system is in recovery mode
Bhushan Verma
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hi All,
I am doing some database related queries and this is working fine at fedora
core 4.
But the same database queries giving the FATAL error on fedora 9.
If I restarts the database on fedora core 9 then this is perfectlry working
without giving any error.
My postgres version is
On Fedora core-9[FC9] Machine:
$ rpm -qa|grep postgres
postgresql-server-8.3.1-1.fc9.i386
postgresql-devel-8.3.1-1.fc9.i386
postgresql-python-8.3.1-1.fc9.i386
postgresql-8.3.1-1.fc9.i386
postgresql-libs-8.3.1-1.fc9.i386
On Fedora core-4[FC49] Machine:
$ rpm -qa|grep postgres
postgresql-server-8.0.3-1
postgresql-libs-8.0.3-1
postgresql-odbc-08.00.0100-1
postgresql-jdbc-8.0.3-1
postgresql-docs-8.0.3-1
postgresql-tcl-8.0.3-1
postgresql-test-8.0.3-1
postgresql-devel-8.0.3-1
postgresql-8.0.3-1
gnucash-backend-postgres-1.8.11-3
freeradius-postgresql-1.0.2-2
postgresql-python-8.0.3-1
postgresql-contrib-8.0.3-1
postgresql-pl-8.0.3-1
Problem is:
----------------
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
psql: FATAL: the database system is in recovery mode
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost
psql: FATAL: the database system is in recovery mode
--------------
Is this database bug or there is any versioning incopatability.
Can anyone please help me in this regards.
--
With Regards,
Bhushan
--000e0cd1e6a676000b046d11ce91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi All,<br>
<br>
<br>
I am doing some database related queries and this is working fine at fedora=
core 4.<br>
But the same database queries giving the FATAL error on fedora 9.<br>
<br>
If I restarts the database on fedora core 9 then this is perfectlry working=
without giving any error.<br>
<br>
My postgres version is <br>
On Fedora core-9[FC9] Machine:<br>
$ rpm -qa|grep postgres<br>
postgresql-server-8.3.1-1.fc9.i386<br>
postgresql-devel-8.3.1-1.fc9.i386<br>
postgresql-python-8.3.1-1.fc9.i386<br>
postgresql-8.3.1-1.fc9.i386<br>
postgresql-libs-8.3.1-1.fc9.i386<br>
<br>
<br>
<br>
On Fedora core-4[FC49] Machine:<br>
$ rpm -qa|grep postgres<br>
postgresql-server-8.0.3-1<br>
postgresql-libs-8.0.3-1<br>
postgresql-odbc-08.00.0100-1<br>
postgresql-jdbc-8.0.3-1<br>
postgresql-docs-8.0.3-1<br>
postgresql-tcl-8.0.3-1<br>
postgresql-test-8.0.3-1<br>
postgresql-devel-8.0.3-1<br>
postgresql-8.0.3-1<br>
gnucash-backend-postgres-1.8.11-3<br>
freeradius-postgresql-1.0.2-2<br>
postgresql-python-8.0.3-1<br>
postgresql-contrib-8.0.3-1<br>
postgresql-pl-8.0.3-1<br>
<br>
Problem is:<br>
----------------<br>
server closed the connection unexpectedly<br>
This probably means the server terminated abnormally<br>
before or while processing the request.<br>
<br>
connection to server was lost<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
server closed the connection unexpectedly<br>
This probably means the server terminated abnormally<br>
before or while processing the request.<br>
connection to server was lost<br>
psql: FATAL:=A0 the database system is in recovery mode<br>
<br>
--------------<br>
<br>
Is this database bug or there is any versioning incopatability.<br>
Can anyone please help me in this regards.<br>
<br>
<br>-- <br>With Regards,<br>Bhushan
--000e0cd1e6a676000b046d11ce91--
Heikki Linnakangas
> I am doing some database related queries and this is working fine at fedora
> core 4.
> But the same database queries giving the FATAL error on fedora 9.
>
> If I restarts the database on fedora core 9 then this is perfectlry working
> without giving any error.
>
> My postgres version is
> On Fedora core-9[FC9] Machine:
> $ rpm -qa|grep postgres
> postgresql-server-8.3.1-1.fc9.i386
> postgresql-devel-8.3.1-1.fc9.i386
> postgresql-python-8.3.1-1.fc9.i386
> postgresql-8.3.1-1.fc9.i386
> postgresql-libs-8.3.1-1.fc9.i386
It probably won't solve this problem, but you need to upgrade. The
latest 8.3 release is 8.3.7. See
http://www.postgresql.org/support/versioning
> On Fedora core-4[FC49] Machine:
> $ rpm -qa|grep postgres
> postgresql-server-8.0.3-1
> ...
Same here. Latest 8.0 minor release is 8.0.21
> Problem is:
> ----------------
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
>
> connection to server was lost
>
> psql: FATAL: the database system is in recovery mode
> ...
>
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> connection to server was lost
> psql: FATAL: the database system is in recovery mode
>
> --------------
>
> Is this database bug or there is any versioning incopatability.
You'll have to give more details or no-one will be able to help you.
Please share the query that caused the crash, and CREATE statements of
all the tables involved in the query. Is there any triggers or anything
else involved?
Can you get a core dump and post stack trace from it? Something along
the lines of:
1. ulimit -c unlimited
2. pg_ctl start
3. <induce crash>
4. gdb /usr/bin/postgres <datadir>/core
5. bt
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Craig Ringer
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> connection to server was lost
Look in the PostgreSQL server logs for more information. It's probably
in /var/log/postgresql or something like that - it depends on exactly
how the distro packaged PostgreSQL.
--
Craig Ringer
Bhushan Verma
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Thanks for your response.
As follows is log details
ERROR: table "transactionrecord_5917" does not exist
STATEMENT: drop table TransactionRecord_5917;
ERROR: table "pagerecord_5917" does not exist
STATEMENT: drop table PageRecord_5917;
ERROR: table "urlrecord_5917" does not exist
STATEMENT: drop table URLRecord_5917;
LOG: server process (PID 29225) was terminated by signal 11: Segmentation
fault
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
FATAL: the database system is in recovery mode
LOG: database system was interrupted; last known up at 2009-06-23 12:49:49
IST
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
LOG: database system was not properly shut down; automatic recovery in
progress
FATAL: the database system is in recovery mode
LOG: redo starts at 0/185239F8
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
LOG: record with zero length at 0/185A67FC
LOG: redo done at 0/185A67D0
LOG: last completed transaction was at log time 2009-06-23
14:49:10.37602+05:30
FATAL: the database system is in recovery mode
LOG: autovacuum launcher started
LOG: database system is ready to accept connections
With Regards,
Bhushan
On 6/24/09, Craig Ringer <cr...@postnewspapers.com.au> wrote:
>
> Bhushan Verma wrote:
>
> > server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > connection to server was lost
>
>
> Look in the PostgreSQL server logs for more information. It's probably
> in /var/log/postgresql or something like that - it depends on exactly
> how the distro packaged PostgreSQL.
>
> --
>
> Craig Ringer
>
--
With Regards,
Bhushan
--0015174c43203c3537046d13d709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Thanks for your response.<br>
As follows is log details<br>
<br>
ERROR:=A0 table "transactionrecord_5917" does not exist<br>
STATEMENT:=A0 drop table TransactionRecord_5917;<br>
ERROR:=A0 table "pagerecord_5917" does not exist<br>
STATEMENT:=A0 drop table PageRecord_5917;<br>
ERROR:=A0 table "urlrecord_5917" does not exist<br>
STATEMENT:=A0 drop table URLRecord_5917;<br>
LOG:=A0 server process (PID 29225) was terminated by signal 11: Segmentatio=
n fault<br>
LOG:=A0 terminating any other active server processes<br>
LOG:=A0 all server processes terminated; reinitializing<br>
FATAL:=A0 the database system is in recovery mode<br>
LOG:=A0 database system was interrupted; last known up at 2009-06-23 12:49:=
49 IST<br>
FATAL:=A0 the database system is in recovery mode<br>
FATAL:=A0 the database system is in recovery mode<br>
LOG:=A0 database system was not properly shut down; automatic recovery in p=
rogress<br>
FATAL:=A0 the database system is in recovery mode<br>
LOG:=A0 redo starts at 0/185239F8<br>
FATAL:=A0 the database system is in recovery mode<br>
FATAL:=A0 the database system is in recovery mode<br>
FATAL:=A0 the database system is in recovery mode<br>
LOG:=A0 record with zero length at 0/185A67FC<br>
LOG:=A0 redo done at 0/185A67D0<br>
LOG:=A0 last completed transaction was at log time 2009-06-23 14:49:10.3760=
2+05:30<br>
FATAL:=A0 the database system is in recovery mode<br>
LOG:=A0 autovacuum launcher started<br>
LOG:=A0 database system is ready to accept connections<br>
<br><br>
With Regards,<br>
Bhushan<br><div><span class=3D"gmail_quote">On 6/24/09, <b class=3D"gmail_s=
endername">Craig Ringer</b> <<a href=3D"mailto:cr...@postnewspapers.com.=
au">cr...@postnewspapers.com.au</a>> wrote:</span><blockquote class=3D"g=
mail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
0pt 0pt 0.8ex; padding-left: 1ex;">
Bhushan Verma wrote:<br> <br> > server closed the connection unexpectedl=
y<br> > This probably means the server terminated abnormally<br> > be=
fore or while processing the request.<br> > connection to server was los=
t<br>
<br> <br>Look in the PostgreSQL server logs for more information. It's=
probably<br> in /var/log/postgresql or something like that - it depends on=
exactly<br> how the distro packaged PostgreSQL.<br> <br> --<br> <br>Craig =
Ringer<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>With Regards,<br>Bhush=
an
--0015174c43203c3537046d13d709--
Bhushan Verma
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hi,
Thanks for your response.
I am not able to find out the core file.
but in log file its giving the message like:
LOG: server process (PID 29225) was terminated by signal 11: Segmentation
fault
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
FATAL: the database system is in recovery mode
LOG: database system was interrupted; last known up at 2009-06-23 12:49:49
IST
FATAL: the database system is in recovery mode
FATAL: the database system is in recovery mode
I have searched for the core file for this pid.
Is there any spcefic path for the postgres executable?
I have already checked for ulimit -c unlimited etc.
On my system core file for some other application are generating properly.
With Regards,
Bhushan
> > server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> >
> > connection to server was lost
> >
> > psql: FATAL: the database system is in recovery mode
>
> > ...
>
> >
> > server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> > connection to server was lost
> > psql: FATAL: the database system is in recovery mode
> >
> > --------------
> >
> > Is this database bug or there is any versioning incopatability.
>
>
> You'll have to give more details or no-one will be able to help you.
> Please share the query that caused the crash, and CREATE statements of
> all the tables involved in the query. Is there any triggers or anything
> else involved?
>
> Can you get a core dump and post stack trace from it? Something along
> the lines of:
> 1. ulimit -c unlimited
> 2. pg_ctl start
> 3. <induce crash>
> 4. gdb /usr/bin/postgres <datadir>/core
> 5. bt
>
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
--
With Regards,
Bhushan
--0015174c10d024ff74046d13f423
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,<br>
<br>
Thanks for your response.<br>
<br>
I am not able to find out the core file.<br>
but in log file its giving the message like:<br>
<br>
LOG:=A0 server process (PID 29225) was terminated by signal 11: Segmentatio=
n fault<br>
LOG:=A0 terminating any other active server processes<br>
LOG:=A0 all server processes terminated; reinitializing<br>
FATAL:=A0 the database system is in recovery mode<br>
LOG:=A0 database system was interrupted; last known up at 2009-06-23 12:49:=
49 IST<br>
FATAL:=A0 the database system is in recovery mode<br>
FATAL:=A0 the database system is in recovery mode<br>
<br>
I have searched for the core file for this pid.<br>
Is there any spcefic path for the postgres executable?<br>
<br>
I have already checked for ulimit -c unlimited etc.<br>
On my system core file for some other application are generating properly.<=
br>
<br>
<br>
With Regards,<br>
Bhushan<br><br><div><span class=3D"gmail_quote">On 6/24/09, <b class=3D"gma=
il_sendername">Heikki Linnakangas</b> <<a href=3D"mailto:heikki.linnakan=
g...@enterprisedb.com">heikki.li...@enterprisedb.com</a>> wrote:</s=
pan><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bhushan Verma wrote:<br> > I am doing some database related queries and =
this is working fine at fedora<br> > core 4.<br> > But the same datab=
ase queries giving the FATAL error on fedora 9.<br> ><br> > If I rest=
arts the database on fedora core 9 then this is perfectlry working<br>
> without giving any error.<br> ><br> > My postgres version is<br=
> > On Fedora core-9[FC9] Machine:<br> > $ rpm -qa|grep postgres<br> =
> postgresql-server-8.3.1-1.fc9.i386<br> > postgresql-devel-8.3.1-1.f=
c9.i386<br>
> postgresql-python-8.3.1-1.fc9.i386<br> > postgresql-8.3.1-1.fc9.i3=
86<br> > postgresql-libs-8.3.1-1.fc9.i386<br> <br> <br>It probably won&#=
39;t solve this problem, but you need to upgrade. The<br> latest 8.3 releas=
e is 8.3.7. See<br>
<a href=3D"http://www.postgresql.org/support/versioning">http://www.postgr=
esql.org/support/versioning</a><br> <br><br> > On Fedora core-4[FC49] Ma=
chine:<br> > $ rpm -qa|grep postgres<br> > postgresql-server-8.0.3-1<=
br>
<br>> ...<br> <br> Same here. Latest 8.0 minor release is 8.0.21<br> <b=
r><br> > Problem is:<br> > ----------------<br> > server closed th=
e connection unexpectedly<br> > This probably means the server terminate=
d abnormally<br>
> before or while processing the request.<br> ><br> > connection =
to server was lost<br> ><br> > psql: FATAL:=A0=A0the database system =
is in recovery mode<br> <br>> ...<br> <br>><br> > server closed th=
e connection unexpectedly<br>
> This probably means the server terminated abnormally<br> > before =
or while processing the request.<br> > connection to server was lost<br>=
> psql: FATAL:=A0=A0the database system is in recovery mode<br> ><br=
>
> --------------<br> ><br> > Is this database bug or there is any=
versioning incopatability.<br> <br> <br>You'll have to give more detai=
ls or no-one will be able to help you.<br> Please share the query that caus=
ed the crash, and CREATE statements of<br>
all the tables involved in the query. Is there any triggers or anything<br=
> else involved?<br> <br> Can you get a core dump and post stack trace from=
it? Something along<br> the lines of:<br> 1. ulimit -c unlimited<br> 2. pg=
_ctl start<br>
3. <induce crash><br> 4. gdb /usr/bin/postgres <datadir>/core<=
br> 5. bt<br> <br><br> --<br>=A0=A0Heikki Linnakangas<br>=A0=A0EnterpriseDB=
=A0=A0 <a href=3D"http://www.enterprisedb.com">http://www.enterprisedb.com<=
/a><br> </blockquote>
</div><br><br clear=3D"all"><br>-- <br>With Regards,<br>Bhushan
--0015174c10d024ff74046d13f423--
Heikki Linnakangas
> I have searched for the core file for this pid.
> Is there any spcefic path for the postgres executable?
>
> I have already checked for ulimit -c unlimited etc.
> On my system core file for some other application are generating properly.
The core file is generated in the data directory. I believe the default
location on Fedora is /var/lib/pgsql/data
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Bhushan Verma
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
>The core file is generated in the data directory. I believe the default
>location on Fedora is /var/lib/pgsql/dat
Yes I also think the same.
But there is no core file in /var/lib/pgsql/dat on my system.
I am trying to find out why this is not generating core while log message
"LOG: server process (PID 14255) was terminated by signal 11: Segmentation
fault" is wriiten in the log file.
With Regards,
Bhushan
On 6/24/09, Heikki Linnakangas <heikki.li...@enterprisedb.com> wrote:
>
> Bhushan Verma wrote:
> > I have searched for the core file for this pid.
> > Is there any spcefic path for the postgres executable?
> >
> > I have already checked for ulimit -c unlimited etc.
> > On my system core file for some other application are generating
> properly.
>
>
> The core file is generated in the data directory. I believe the default
> location on Fedora is /var/lib/pgsql/data
>
>
> --
>
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
--
With Regards,
Bhushan
--0015174c0f1256afb2046d14c0f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
>The core file is generated in the data directory. I believe the default=
<br>
>location on Fedora is /var/lib/pgsql/dat<br>
<br>
Yes I also think the same.<br>
But there is no core file in /var/lib/pgsql/dat on my system.<br>
I am trying to find out why this is not generating core while log
message=A0 "LOG:=A0 server process (PID 14255) was terminated by
signal 11: Segmentation fault" is wriiten in the log file.<br>
<br>
<br>
<br>
With Regards,<br>
Bhushan<br><br><div><span class=3D"gmail_quote">On 6/24/09, <b class=3D"gma=
il_sendername">Heikki Linnakangas</b> <<a href=3D"mailto:heikki.linnakan=
g...@enterprisedb.com">heikki.li...@enterprisedb.com</a>> wrote:</s=
pan><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2=
04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bhushan Verma wrote:<br> > I have searched for the core file for this pi=
d.<br> > Is there any spcefic path for the postgres executable?<br> >=
<br> > I have already checked for ulimit -c unlimited etc.<br> > On m=
y system core file for some other application are generating properly.<br>
<br> <br>The core file is generated in the data directory. I believe the d=
efault<br> location on Fedora is /var/lib/pgsql/data<br> <br><br> --<br> <b=
r>=A0=A0Heikki Linnakangas<br>=A0=A0EnterpriseDB=A0=A0 <a href=3D"http://ww=
w.enterprisedb.com">http://www.enterprisedb.com</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>With Regards,<br>Bhush=
an
--0015174c0f1256afb2046d14c0f4--
Heikki Linnakangas
>> The core file is generated in the data directory. I believe the default
>> location on Fedora is /var/lib/pgsql/dat
>
> Yes I also think the same.
> But there is no core file in /var/lib/pgsql/dat on my system.
> I am trying to find out why this is not generating core while log message
> "LOG: server process (PID 14255) was terminated by signal 11: Segmentation
> fault" is wriiten in the log file.
Perhaps the ulimit is not in effect after all? Try starting postmaster
directly, without pg_ctl:
ulimit -c unlimited
postmaster -D /var/lib/pgsql/data
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Heikki Linnakangas
>>> postmaster -D /var/lib/pgsql/data
> I am using the same command as you said.
I'm afraid I'm out of ideas on how to get the core dump then.
You could also try attaching gdb to the backend process before it
crashes, and get the backtrace from there. Something along the lines of:
postmaster -D /var/lib/pgsql/data
psql postgres ...
ps ax | grep postgres # check the PID of the backend process psql is
connected to.
gdb
gdb> attach <pid of backend>
gdb> cont
<run the query in psql that crashes>
gdb> bt
You still haven't posted the offending query, BTW. Is it a particular
one, or does it crash at random?
Bhushan Verma
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Hi
Thanks one again for your response.
>>You still haven't posted the offending query,
I am running on shell script that contains various select statment,
one of the example is as follows;
----------
SELECT PageIndex,
(SUM(ConnectDoneTime - StartTime) * 100) / SUM(EndTime - StartTime)
AS "ConnectTimePct",
(SUM(WriteCompleTime - ConnectDoneTime) * 100) / SUM(EndTime -
StartTime) AS "RequestSentTimePct",
(SUM(FirstByteRcdTime - WriteCompleTime) * 100) / SUM(EndTime -
StartTime) AS "FirstByteTimePct",
(SUM(EndTime - FirstByteRcdTime) * 100) / SUM(EndTime - StartTime) AS
"DownloadTimePct"
FROM UrlRecord_$1
WHERE EndTime <> 0
AND ConnectDoneTime <> 0
AND WriteCompleTime <> 0
AND FirstByteRcdTime <> 0
GROUP By PageIndex
ORDER By PageIndex;
-----------
I want to tell you that its happening after sometime ie at random. time is
not fixed.
>>Is it a particular one, or does it crash at random?
its crash at random.
On 6/24/09, Heikki Linnakangas <heikki.li...@enterprisedb.com> wrote:
>
> Bhushan Verma wrote:
> >>> postmaster -D /var/lib/pgsql/data
> > I am using the same command as you said.
>
>
> I'm afraid I'm out of ideas on how to get the core dump then.
>
> You could also try attaching gdb to the backend process before it
> crashes, and get the backtrace from there. Something along the lines of:
>
>
> postmaster -D /var/lib/pgsql/data
>
> psql postgres ...
> ps ax | grep postgres # check the PID of the backend process psql is
> connected to.
> gdb
> gdb> attach <pid of backend>
> gdb> cont
> <run the query in psql that crashes>
> gdb> bt
>
>
> You still haven't posted the offending query, BTW. Is it a particular
> one, or does it crash at random?
>
>
> --
>
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
--
With Regards,
Bhushan
--001517478be8b562ae046d17fe19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi <br>
<br>
Thanks one again for your response.<br>
<br>
>>You still haven't posted the offending query,<br>
I am running on shell script that contains various select statment,<br>
one of the example is as follows;<br>
----------<br>
SELECT PageIndex,<br>
=A0=A0=A0=A0=A0=A0 (SUM(ConnectDoneTime - StartTime) * 100) / SUM(EndTime -=
StartTime) AS "ConnectTimePct",<br>
=A0=A0=A0=A0=A0=A0 (SUM(WriteCompleTime -
ConnectDoneTime) * 100) / SUM(EndTime - StartTime) AS
"RequestSentTimePct",<br>
=A0=A0=A0=A0=A0=A0 (SUM(FirstByteRcdTime -
WriteCompleTime) * 100) / SUM(EndTime - StartTime) AS
"FirstByteTimePct",<br>
=A0=A0=A0=A0=A0=A0 (SUM(EndTime - FirstByteRcdTime) * 100) / SUM(EndTime - =
StartTime) AS "DownloadTimePct"<br>
FROM UrlRecord_$1<br>
WHERE EndTime <> 0<br>
=A0=A0=A0=A0=A0 AND ConnectDoneTime <> 0<br>
=A0=A0=A0=A0=A0 AND WriteCompleTime <> 0<br>
=A0=A0=A0=A0=A0 AND FirstByteRcdTime <> 0<br>
GROUP By PageIndex<br>
ORDER By PageIndex;<br>
<br>
-----------<br>
<br>
I want to tell you that its happening after sometime ie at random. time is =
not fixed.<br>
<br>
>>Is it a particular one, or does it crash at random?<br>
=A0<br>
its crash at random.<br>
<br><br><div><span class=3D"gmail_quote">On 6/24/09, <b class=3D"gmail_send=
ername">Heikki Linnakangas</b> <<a href=3D"mailto:heikki.linnakangas@ent=
erprisedb.com">heikki.li...@enterprisedb.com</a>> wrote:</span><bl=
ockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204=
, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bhushan Verma wrote:<br> >>> postmaster -D /var/lib/pgsql/data<br>=
> I am using the same command as you said.<br> <br> <br>I'm afraid =
I'm out of ideas on how to get the core dump then.<br> <br> You could a=
lso try attaching gdb to the backend process before it<br>
crashes, and get the backtrace from there. Something along the lines of:<b=
r> <br><br> postmaster -D /var/lib/pgsql/data<br> <br>psql postgres ...<br>=
ps ax | grep postgres # check the PID of the backend process psql is<br>
connected to.<br> gdb<br> gdb> attach <pid of backend><br> gdb>=
; cont<br> <run the query in psql that crashes><br> gdb> bt<br> <b=
r> <br> You still haven't posted the offending query, BTW. Is it a part=
icular<br>
one, or does it crash at random?<br> <br><br> --<br> <br>=A0=A0Heikki Linn=
akangas<br>=A0=A0EnterpriseDB=A0=A0 <a href=3D"http://www.enterprisedb.com"=
>http://www.enterprisedb.com</a><br> </blockquote></div><br><br clear=3D"al=
l"><br>-- <br>
With Regards,<br>Bhushan
--001517478be8b562ae046d17fe19--
Craig Ringer
>>> Is it a particular one, or does it crash at random?
>
> its crash at random.
Random segfaults easily by application bugs ( memory corruption,
accessing uninitialized memory and dereferencing pointers there, etc )
or hardware issues like bad CPU/CPU cache/memory, overheating, etc.
Are you having issues with any other applications?
If you can afford the load, consider running something quite CPU/memory
intensive for a while - say, a big compile job - and make sure it all
goes smoothly.
It'd also be interesting to know whether a separate PostgreSQL instance
with a fresh database had issues, but that's probably not practical for
you to test.
Most likely it's some kind of corrupt database triggering a subtle bug
somewhere in Pg, anyway...
--
Craig Ringer