Re: [GENERAL] Segmentation fault calling shared object file

Martin Moore writes: > Hi, I have a ‘C’ shared object that has been running on postgres since 8.3 > and maybe before – on 32 bit Debian. Currently on 9.3. > I’m trying to migrate to Google cloud (64 bit Debian) and get a seg fault > when calling one of the functions

[GENERAL] Segmentation fault calling shared object file

Hi, I have a ‘C’ shared object that has been running on postgres since 8.3 and maybe before – on 32 bit Debian. Currently on 9.3. I’m trying to migrate to Google cloud (64 bit Debian) and get a seg fault when calling one of the functions which have been recompiled on the Google instance. This

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

this out. Best Regards Dave From: Day, David Sent: Wednesday, February 18, 2015 8:07 AM To: 'Guy Helmer' Cc: 'pgsql-general@postgresql.org' Subject: RE: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ? Update/Information sharing: ( FreeBSD 10.0 (amd64) – Postgres 9.3.5

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

the 13th. Regards Dave Day From: Guy Helmer [mailto:ghel...@palisadesystems.com] Sent: Thursday, February 12, 2015 6:19 PM To: Day, David Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ? On Feb 12, 2015, at 3:21 PM, Day

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

On Feb 12, 2015, at 3:21 PM, Day, David d...@redcom.com wrote: Update/Information sharing on my pursuit of segmentation faults FreeBSD 10.0-RELEASE-p12 amd64 Postgres version 9.3.5 Below are three postgres core files generated from two different machine ( Georgia and Alabama ) on

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ? On Feb 12, 2015, at 3:21 PM, Day, David d...@redcom.commailto:d...@redcom.com wrote: Update/Information sharing on my pursuit of segmentation faults FreeBSD 10.0-RELEASE-p12 amd64 Postgres version 9.3.5 Below are three

[GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

Update/Information sharing on my pursuit of segmentation faults FreeBSD 10.0-RELEASE-p12 amd64 Postgres version 9.3.5 Below are three postgres core files generated from two different machine ( Georgia and Alabama ) on Feb 11. These cores would not be caused from an environment update issue

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

segmentation fault Thanks for your assistance on this matter. Dave From: Alex Hunsaker [mailto:bada...@gmail.com] Sent: Thursday, January 29, 2015 6:10 PM To: Day, David Cc: pgsql-general@postgresql.org; Tom Lane Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

On Fri, Jan 30, 2015 at 9:54 AM, Day, David d...@redcom.com wrote: Alan, I tried as you suggested, I believe the gdb debugger is giving some false indication about threads. Whether I attach to a newly launched backend or a backend that has been executing the suspect perlu function.

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

the infrequency of the segmentation fault puzzling. Regards Dave From: Alex Hunsaker [mailto:bada...@gmail.com] Sent: Thursday, January 29, 2015 12:58 AM To: Day, David Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ? On Wed

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

of the segmentation fault puzzling. Regards Dave From: Alex Hunsaker [mailto:bada...@gmail.com] Sent: Thursday, January 29, 2015 12:58 AM To: Day, David Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ? On Wed, Jan 28, 2015 at 1:23

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

Day, David d...@redcom.com writes: I am amending the info threads info there are two threads. Well, that's your problem right there. There should never, ever be more than one thread in a Postgres backend process: none of the code in the backend is meant for a multithreaded situation, and so

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

On Thu, Jan 29, 2015 at 8:40 AM, Tom Lane t...@sss.pgh.pa.us wrote: Day, David d...@redcom.com writes: I am amending the info threads info there are two threads. Well, that's your problem right there. There should never, ever be more than one thread in a Postgres backend process: none of

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

Thanks for the inputs, I’ll attempt to apply it and will update when I have some new information. Thanks Dave From: Alex Hunsaker [mailto:bada...@gmail.com] Sent: Thursday, January 29, 2015 3:30 PM To: Day, David Cc: pgsql-general@postgresql.org; Tom Lane Subject: Re: [GENERAL] segmentation

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

On Thu, Jan 29, 2015 at 1:54 PM, Day, David d...@redcom.com wrote: Thanks for the inputs, I’ll attempt to apply it and will update when I have some new information. BTW a quick check would be to attach with gdb right after you connect, check info threads (there should be none), run the

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

It has been some time since we have seen this problem. See earlier message on this subject/thread for the suspect plperl function executing at the time of the core. Someone on our development team suggested it might relate to some build options of perl. In particular MULTIPLICITY or

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

On Wed, Jan 28, 2015 at 1:23 PM, Day, David d...@redcom.com wrote: It has been some time since we have seen this problem. See earlier message on this subject/thread for the suspect plperl function executing at the time of the core. Someone on our development team suggested it might

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

: Wednesday, December 03, 2014 3:57 PM To: Day, David Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ? Day, David d...@redcom.com writes: We are developing on and running Postgres 9.3.5 on FreeBsd 10.0-p12. We have been

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

Day, David d...@redcom.com writes: It is very likely that the date of the core was 'touched' to make the rebuilt Postgres binary with symbols play nice with gdb. Apparently, that was not a great idea based on your comments. Oh, so you rebuilt with debug enabled and then retrospectively tried

Re: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

Day, David d...@redcom.com writes: We are developing on and running Postgres 9.3.5 on FreeBsd 10.0-p12. We have been experiencing a intermittent postgres core dump which Seems primarily to be associated with the the 2 functions below. Given the onset of this problem, we suspect it has

[GENERAL] segmentation fault postgres 9.3.5 core dump perlu related ?

We are developing on and running Postgres 9.3.5 on FreeBsd 10.0-p12. We have been experiencing a intermittent postgres core dump which Seems primarily to be associated with the the 2 functions below. The area of interest is based on the content of the postgres log file which often indicates

[GENERAL] Segmentation fault

hello team , i am trying to enter this insert command in postgres insert into mmsuper.notification values('101','12','13','حب|welcome|आपकास्वागतहै','bye','goodbye','low balance',5); now when i am trying to paste this in postgres in Solaris , it is giving me error fm_db_Server1-# insert into

Re: [GENERAL] Segmentation fault

ajay akmani1...@gmail.com writes: hello team , i am trying to enter this insert command in postgres insert into mmsuper.notification values('101','12','13','حب|welcome|आपकास्वागतहै','bye','goodbye','low balance',5); now when i am trying to paste this in postgres

Re: [GENERAL] Segmentation fault

On 03/04/2014 03:03 AM, ajay wrote: hello team , i am trying to enter this insert command in postgres insert into mmsuper.notification values('101','12','13','حب|welcome|आपकास्वागतहै','bye','goodbye','low balance',5); now when i am trying to paste this in postgres in Solaris , it is giving me

Re: [GENERAL] Segmentation fault

On 03/04/2014 07:39 AM, Adrian Klaver wrote: CCing list: quote author='Adrian Klaver-4' On 03/04/2014 03:03 AM, ajay wrote: hello team , i am trying to enter this insert command in postgres insert into mmsuper.notification values('101','12','13','حب|welcome|आपकास्वागतहै','bye','goodbye','low

Re: [GENERAL] Segmentation fault

thanks for the reply ,.. When i am trying to enter anything else other then some Arabic , Hindi .. that case it does not give this error. like if i enter.. insert into table values('welcome',1); then it does not give any error and get successfully Thanks -- View this message in context:

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

Alan Nilsson anils...@apple.com writes: What I am saying is that something changed in 90300 that causes libpq to spew to stdout where it had not in libpq 90102 90203. Well, that's interesting, but the issue is not in libpq, and you've still provided no information that would help anyone

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

I ran into something tonight that seems relevant here, or certainly related: I recently updated my app(s) libpq version from 9.1 to 9.3 and immediately I starting seeing: row number 0 is out of range 0..-1 spewed to stdout. I traced it down to this code: if (PQresultStatus(result) ==

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

Alan Nilsson anils...@apple.com writes: I ran into something tonight that seems relevant here, or certainly related: I recently updated my app(s) libpq version from 9.1 to 9.3 and immediately I starting seeing: row number 0 is out of range 0..-1 spewed to stdout. I traced it down to this

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

oops sorry to be unclear, the code below is my code in my app. What I am saying is that something changed in 90300 that causes libpq to spew to stdout where it had not in libpq 90102 90203. I guess i am blaming the messenger because there should be no messenger. Regardless of how badly I

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

On Sat, Sep 14, 2013 at 09:40:01PM -0400, Robert Nix wrote: Running a pg_upgrade task is causing Segmentation fault: command: /usr/lib/postgresql/9.3/bin/pg_dump --host /var/lib/postgresql --port 50432 --username postgres --schema-only --quote-all-identifiers --binary-upgrade --format=custom

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

On Sun, Sep 15, 2013 at 8:02 PM, Robert Nix rob...@urban4m.com wrote: If you do the dump using 9.1's pg_dump without --binary-upgrade, and then load that dump file into a new empty 9.1 server, then does it crash if you take a dump against *that* server? I'll give it a try. If so, would

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

On Sat, Sep 14, 2013 at 6:40 PM, Robert Nix rob...@urban4m.com wrote: Running a pg_upgrade task is causing Segmentation fault: command: /usr/lib/postgresql/9.3/bin/pg_dump --host /var/lib/postgresql --port 50432 --username postgres --schema-only --quote-all-identifiers --binary-upgrade

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

What happens if you manually run the pg_dump command quoted above against a running 9.1 server, outside of the context of pg_upgrade? (Your port will be probably be different from 50432) If that still crashes, What if you drop the --binary-upgrade option? The --format=custom option? I

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

On Sun, Sep 15, 2013 at 5:06 PM, Robert Nix rob...@urban4m.com wrote: What happens if you manually run the pg_dump command quoted above against a running 9.1 server, outside of the context of pg_upgrade? (Your port will be probably be different from 50432) If that still crashes, What if

Re: [GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

If you do the dump using 9.1's pg_dump without --binary-upgrade, and then load that dump file into a new empty 9.1 server, then does it crash if you take a dump against *that* server? I'll give it a try. If so, would you be allowed to post that dump file? I will not be able to provide the

[GENERAL] Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1

Running a pg_upgrade task is causing Segmentation fault: command: /usr/lib/postgresql/9.3/bin/pg_dump --host /var/lib/postgresql --port 50432 --username postgres --schema-only --quote-all-identifiers --binary-upgrade --format=custom --file=pg_upgrade_dump_6064585.custom u

Re: [GENERAL] Segmentation fault with core dump

Hi, (2013/05/09 1:39), Joshua Berry wrote: | I'm using PG 9.1.9 with a client application using various versions of the | pgsqlODBC driver on Windows. Cursors are used heavily, as well as some pretty | heavy trigger queries on db writes which update several materialized views. | | The server

Re: [GENERAL] Segmentation fault with core dump

Hiroshi Inoue in...@tpf.co.jp writes: It's also better to fix the crash at backend side. Yeah, definitely. Do we have a self-contained test case for this? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your

Re: [GENERAL] Segmentation fault with core dump

(2013/06/12 0:03), Tom Lane wrote: Hiroshi Inoue in...@tpf.co.jp writes: It's also better to fix the crash at backend side. Yeah, definitely. Do we have a self-contained test case for this? Unfortunately no. I'm testing with a modified psqlodbc driver. The simplest way may be as follows.

Re: [GENERAL] Segmentation fault with core dump

| I'm using PG 9.1.9 with a client application using various versions of the | pgsqlODBC driver on Windows. Cursors are used heavily, as well as some pretty | heavy trigger queries on db writes which update several materialized views. | | The server has 48GB RAM installed, PG is configured for

Re: [GENERAL] Segmentation fault with core dump

On 2013-04-10 19:06:12 -0400, Tom Lane wrote: I wrote: (Wanders away wondering just how much the regression tests exercise holdable cursors.) And the answer is they're not testing this code path at all, because if you do DECLARE c CURSOR WITH HOLD FOR ... FETCH ALL FROM c;

[GENERAL] Segmentation fault with core dump

Hi Group, I'm using PG 9.1.9 with a client application using various versions of the pgsqlODBC driver on Windows. Cursors are used heavily, as well as some pretty heavy trigger queries on db writes which update several materialized views. The server has 48GB RAM installed, PG is configured for

Re: [GENERAL] Segmentation fault with core dump

Joshua Berry escribió: gdb /usr/pgsql-9.1/bin/postmaster -c core.17356 [...loading/reading symbols...] Core was generated by `postgres: [username] [databasename] [client_ipaddress](1500) SELECT '. Program terminated with signal 11, Segmentation fault. #0

Re: [GENERAL] Segmentation fault with core dump

Hi, On 2013-04-10 16:34:40 -0500, Joshua Berry wrote: Below are the relevant details. I'm not terribly savvy with gdb, so please let me know what else I could/should examine from the core dump, as well as anything else about the system/configuration. Kind Regards, -Joshua #NB: some info

Re: [GENERAL] Segmentation fault with core dump

Hi Andres! On Wed, Apr 10, 2013 at 4:49 PM, Andres Freund and...@2ndquadrant.comwrote: Could you show the output of 'bt full'? Program terminated with signal 11, Segmentation fault. #0 ResourceOwnerEnlargeCatCacheRefs (owner=0x0) at resowner.c:605 605 if (owner-ncatrefs

Re: [GENERAL] Segmentation fault with core dump

On 2013-04-10 16:53:12 -0500, Joshua Berry wrote: #7 0x00638c78 in PortalRun (portal=0x2aa9360, count=10, isTopLevel=1 '\001', dest=0x2a50c40, altdest=0x2a50c40, completionTag=0x7fffd193d0f0 ) at pquery.c:787 save_exception_stack = 0x7fffd193cfe0

Re: [GENERAL] Segmentation fault with core dump

Ok, so while we have a valid resource owner up to here, portal-resonwer is NULL. Could you 'up' until youre in this frame and then do 'print *portal'? #7 0x00638c78 in PortalRun (portal=0x2aa9360, count=10, isTopLevel=1 '\001', dest=0x2a50c40, altdest=0x2a50c40,

Re: [GENERAL] Segmentation fault with core dump

Andres Freund and...@2ndquadrant.com writes: Ok, so while we have a valid resource owner up to here, portal-resonwer is NULL. Yeah, that's what I'm guessing. Given the exposed reference to a cursor WITH HOLD, it seems likely that the reason the portal has no resowner is that

Re: [GENERAL] Segmentation fault with core dump

I wrote: (Wanders away wondering just how much the regression tests exercise holdable cursors.) And the answer is they're not testing this code path at all, because if you do DECLARE c CURSOR WITH HOLD FOR ... FETCH ALL FROM c; then the second query executes with a portal (and

Re: [GENERAL] Segmentation fault with core dump

On 2013-04-10 17:31:09 -0500, Joshua Berry wrote: Ok, so while we have a valid resource owner up to here, portal-resonwer is NULL. Could you 'up' until youre in this frame and then do 'print *portal'? #7 0x00638c78 in PortalRun (portal=0x2aa9360, count=10, isTopLevel=1

Re: [GENERAL] Segmentation fault with core dump

On 2013-04-10 19:06:12 -0400, Tom Lane wrote: I wrote: (Wanders away wondering just how much the regression tests exercise holdable cursors.) And the answer is they're not testing this code path at all, because if you do DECLARE c CURSOR WITH HOLD FOR ... FETCH ALL FROM c;

Re: [GENERAL] Segmentation fault with core dump

Andres Freund and...@2ndquadrant.com writes: Tom: It looks to me like printtup_prepare_info won't normally be called in an held cursor. But if some concurrent DDL changed the number of columns in typeinfo vs thaose in the the receiver that could explain the issue and why its not seen all the

Re: [GENERAL] Segmentation fault with core dump

Ok, I might be seeing whats going on here. Could you go to 'printtup' and print *myState, *myState-attrinfo, *typpeinfo? #4 0x004593c4 in printtup (slot=0x2d14618, self=0x2a50c40) at printtup.c:297 297 printtup_prepare_info(myState, typeinfo, natts); (gdb)

Re: [GENERAL] Segmentation fault with core dump

On 2013-04-10 18:25:24 -0500, Joshua Berry wrote: Ok, I might be seeing whats going on here. Could you go to 'printtup' and print *myState, *myState-attrinfo, *typpeinfo? #4 0x004593c4 in printtup (slot=0x2d14618, self=0x2a50c40) at printtup.c:297 297

Re: [GENERAL] Segmentation fault with core dump

Andres Freund and...@2ndquadrant.com writes: On 2013-04-10 19:06:12 -0400, Tom Lane wrote: And the answer is they're not testing this code path at all, because if you do DECLARE c CURSOR WITH HOLD FOR ... FETCH ALL FROM c; then the second query executes with a portal (and resource owner)

Re: [GENERAL] Segmentation fault with core dump

On 2013-04-10 19:06:12 -0400, Tom Lane wrote: I wrote: (Wanders away wondering just how much the regression tests exercise holdable cursors.) And the answer is they're not testing this code path at all, because if you do DECLARE c CURSOR WITH HOLD FOR ... FETCH ALL FROM c;

Re: [GENERAL] Segmentation fault with core dump

Hm. Make that a print *(DR_printtup *) self print *((DR_printtup *) self)-attrinfo print *slot-tts_tupleDescriptor (gdb) print *(DR_printtup *) self $2 = {pub = {receiveSlot = 0x459390 printtup, rStartup = 0x459550 printtup_startup, rShutdown = 0x458a20 printtup_shutdown, rDestroy

Re: [GENERAL] Segmentation fault with core dump

On 2013-04-10 19:29:06 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2013-04-10 19:06:12 -0400, Tom Lane wrote: And the answer is they're not testing this code path at all, because if you do DECLARE c CURSOR WITH HOLD FOR ... FETCH ALL FROM c; then the second

Re: [GENERAL] Segmentation fault

On 07/19/2012 01:52 PM, Amod Pandey wrote: Thank you Craig for explaining in such a detail. I am adding more information and would see what more I can add, $ulimit -a core file size (blocks, -c) 0 So I assume there to be no core dump file. Quite likely. Limits are inherited down

Re: [GENERAL] Segmentation fault

Thank you Craig for explaining in such a detail. I am adding more information and would see what more I can add, $ulimit -a core file size (blocks, -c) 0 So I assume there to be no core dump file. If I set 'ulimit -c unlimited' will it generate core dump if there is another occurrence.

[GENERAL] Segmentation fault

Server stopped due to Segmentation Fault. Server was running successfully for an year. PostgreSQL: 9.0.3 from /var/log/messages Jul 18 19:00:03 ip-10-136-22-193 kernel: [18643442.660032] postgres[6818]: segfault at 170a8c6f ip 0044c94d sp 7fff9fee5b80 error 4 in

Re: [GENERAL] Segmentation fault

On 07/19/2012 12:37 AM, Amod Pandey wrote: Server stopped due to Segmentation Fault. Server was running successfully for an year. PostgreSQL: 9.0.3 from /var/log/messages Jul 18 19:00:03 ip-10-136-22-193 kernel: [18643442.660032] postgres[6818]: segfault at 170a8c6f ip 0044c94d sp

Re: [GENERAL] Segmentation Fault

On 06/12/2012 03:15 AM, Benson Jin wrote: Hi All, A silly question how do I get install external symbols for postgresql, if compiled it myself previously? Do I recompile it with --enable-debug option? If you didn't strip the executable then the cores produced even without

Re: [GENERAL] Segmentation Fault

On 06/11/2012 11:34 AM, Benson Jin wrote: Hi All, We are having a problem with our streaming replication read only node. It has crashed a few times with a couple of different reasons, mostly segmentation fault. Any chance of examining a core dump and getting a stack trace?

Re: [GENERAL] Segmentation Fault

2012/6/11 Benson Jin benson@troo.com: Hi All, We are having a problem with our streaming replication read only node. It has crashed a few times with a couple of different reasons, mostly segmentation fault. The latest log are listed below: 2012-05-30 23:56:37.385 UTC::: LOG:  server

Re: [GENERAL] Segmentation Fault

I will try produce one and submit to here. - Original Message - From: Craig Ringer ring...@ringerc.id.au To: Benson Jin benson@troo.com Cc: pgsql-general@postgresql.org Sent: Monday, June 11, 2012 3:49:41 AM Subject: Re: [GENERAL] Segmentation Fault On 06/11/2012 11:34 AM

Re: [GENERAL] Segmentation Fault

Cc: pgsql-general@postgresql.org Sent: Monday, June 11, 2012 3:49:41 AM Subject: Re: [GENERAL] Segmentation Fault On 06/11/2012 11:34 AM, Benson Jin wrote: Hi All, We are having a problem with our streaming replication read only node. It has crashed a few times with a couple

[GENERAL] Segmentation Fault

Hi All, We are having a problem with our streaming replication read only node. It has crashed a few times with a couple of different reasons, mostly segmentation fault. The latest log are listed below: 2012-05-30 23:56:37.385 UTC::: LOG: server process (PID 19476) was terminated by signal

Re: [GENERAL] Segmentation fault during restoration of compressed(.gz) database

sulmansarwar wrote: Hi, I am new to PostgreSQL. I have been trying to restore a compressed(.gz) database using gunzip -c filename.gz | psql dbname After some 8 or 9 tables are restored the program exists giving error: Segmentation Fault. Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Re: [GENERAL] Segmentation fault during restoration of compressed(.gz) database

Ignore me - I missed the previous thread with the same question. -- Richard Huxton Archonet Ltd -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Segmentation Fault during database restoration

Hi, I am new to PostgreSQL. I have been trying to restore a compressed(.gz) database using gunzip -c *filename*.gz | psql *dbname* After some 8 or 9 tables are restored the program exists giving error: Segmentation Fault. I have attached the crash report below.

[GENERAL] Segmentation fault during restoration of compressed(.gz) database

Hi, I am new to PostgreSQL. I have been trying to restore a compressed(.gz) database using gunzip -c filename.gz | psql dbname After some 8 or 9 tables are restored the program exists giving error: Segmentation Fault. I have attached the crash report below.

Re: [GENERAL] Segmentation Fault during database restoration

Sulman Sarwar sulmansar...@gmail.com writes: I am new to PostgreSQL. I have been trying to restore a compressed(.gz) database using gunzip -c *filename*.gz | psql *dbname* After some 8 or 9 tables are restored the program exists giving error: Segmentation Fault. That's weird ...

Re: [GENERAL] Segmentation Fault during database restoration

On Wed, 2009-09-16 at 23:32 +0100, Sulman Sarwar wrote: Hi, I am new to PostgreSQL. I have been trying to restore a compressed(.gz) database using Just out of interest, how did you install PostgreSQL? Did you install a pre-built binary? If so, from where? Guessing from the paths, it

Re: [GENERAL] Segmentation Fault during database restoration

Craig Ringer cr...@postnewspapers.com.au writes: I ask in particular because there have been big problems caused by building PostgreSQL as a universal binary. It seems to be important to configure it and build it only for the architecture you're actually using. That probably goes for ia32 vs

Re: [GENERAL] Segmentation Fault during database restoration

I used one click installer for Mac OSX from EnterpriseDB. http://www.enterprisedb.com/products/pgdownload.do#osx On Thu, Sep 17, 2009 at 4:10 AM, Tom Lane t...@sss.pgh.pa.us wrote: Craig Ringer cr...@postnewspapers.com.au writes: I ask in particular because there have been big problems

[GENERAL] Segmentation fault in backend/access/heap/pruneheap.c: heap_page_prune_opt() calling PageIsPrunable () with NULL page on FreeBSD / PowerPC

Hi y'all, I've been experiencing segfaults of PostgreSQL for quite a quite now (since July 2008, PostgreSQL 8.3.3, perhaps?) on a FreeBSD 7 PowerPC (7400) system (not sure if anyone really cares about this particular platform, but I'll try :-)): internal# gdb postgres postgres.core GNU gdb

Re: [GENERAL] Segmentation fault in backend/access/heap/pruneheap.c: heap_page_prune_opt() calling PageIsPrunable () with NULL page on FreeBSD / PowerPC

Nick Withers n...@nickwithers.com writes: I've been experiencing segfaults of PostgreSQL for quite a quite now (since July 2008, PostgreSQL 8.3.3, perhaps?) on a FreeBSD 7 PowerPC (7400) system (not sure if anyone really cares about this particular platform, but I'll try :-)): Hmm, is this

Re: [GENERAL] Segmentation fault in backend/access/heap/pruneheap.c: heap_page_prune_opt() calling PageIsPrunable () with NULL page on FreeBSD / PowerPC

On Thu, 2009-01-22 at 23:42 -0500, Tom Lane wrote: Nick Withers n...@nickwithers.com writes: I've been experiencing segfaults of PostgreSQL for quite a quite now (since July 2008, PostgreSQL 8.3.3, perhaps?) on a FreeBSD 7 PowerPC (7400) system (not sure if anyone really cares about this

[GENERAL] Segmentation fault (core dumped) loading data on 8.3 upgrade: undefined symbol 'pg_valid_server_encoding_id',lazy binding failed!

Hello pgsql-general, I exported an 8.2.6 database and am trying to load it on 8.3.0. I get this error: [EMAIL PROTECTED]:/var/postgres]$ ql -d postgres bak/dump.bak /usr/local/bin/psql:/usr/local/bin/psql: undefined symbol 'pg_valid_server_encoding_id' lazy

Re: [GENERAL] Segmentation fault (core dumped) loading data on 8.3 upgrade: undefined symbol 'pg_valid_server_encoding_id',lazy binding failed!

Chris Paul [EMAIL PROTECTED] writes: I exported an 8.2.6 database and am trying to load it on 8.3.0. I get this error: [EMAIL PROTECTED]:/var/postgres]$ ql -d postgres bak/dump.bak /usr/local/bin/psql:/usr/local/bin/psql: undefined symbol

Re: [GENERAL] Segmentation fault (core dumped) loading data on 8.3 upgrade: undefined symbol 'pg_valid_server_encoding_id',lazy binding failed!

Tom Lane wrote: Chris Paul [EMAIL PROTECTED] writes: I exported an 8.2.6 database and am trying to load it on 8.3.0. I get this error: [EMAIL PROTECTED]:/var/postgres]$ ql -d postgres bak/dump.bak /usr/local/bin/psql:/usr/local/bin/psql: undefined symbol

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Fixes are committed to CVS, hope, they will help you. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 9: In

[GENERAL] Segmentation fault with 8.3 FTS ISpell

Crash happens about 7 minutes after issuing the UPDATE statement with current CVS HEAD. The table has around 5 million rows. It's always reproducible. ISpell dict used: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/dicts/ispell/ispell-german-compound.tar.gz (iconved to UTF-8)

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Hannes Dorbath wrote: test=# UPDATE test SET tsv = to_tsvector(text); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. Jan 15 11:32:50 brainchild postmaster[14815] general protection

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

It'd be nice to have text string which cause segfault and sql script for configuration. Oleg On Tue, 15 Jan 2008, Hannes Dorbath wrote: Crash happens about 7 minutes after issuing the UPDATE statement with current CVS HEAD. The table has around 5 million rows. It's always reproducible.

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Alvaro Herrera wrote: Can you please provide a backtrace from gdb? I hope that contains it: http://theendofthetunnel.de/backtrace.log It'd be nice to have text string which cause segfault and sql script for configuration. Yes, I'll try to catch the row. -- Best regards, Hannes Dorbath

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Hannes Dorbath wrote: Yes, I'll try to catch the row. I just slammed a BEFORE UPDATE FOR EACH ROW trigger with RAISE NOTICE on the table to catch the row ID where it fails. The row ID is never the same. Neither can I reproduce it when I use the last reported row ID. Is NOTICE logging /

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Hannes Dorbath wrote: Hannes Dorbath wrote: Yes, I'll try to catch the row. I just slammed a BEFORE UPDATE FOR EACH ROW trigger with RAISE NOTICE on the table to catch the row ID where it fails. The row ID is never the same. Neither can I reproduce it when I use the last reported row ID.

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Hannes Dorbath [EMAIL PROTECTED] writes: Hannes Dorbath wrote: Yes, I'll try to catch the row. I just slammed a BEFORE UPDATE FOR EACH ROW trigger with RAISE NOTICE on the table to catch the row ID where it fails. The row ID is never the same. Neither can I reproduce it when I use the

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

I tryed to reproduce the bug but without success. Could you provide a dump of text column? Hannes Dorbath wrote: Crash happens about 7 minutes after issuing the UPDATE statement with current CVS HEAD. The table has around 5 million rows. It's always reproducible. -- Teodor Sigaev

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Hannes Dorbath [EMAIL PROTECTED] writes: Crash happens about 7 minutes after issuing the UPDATE statement with current CVS HEAD. The table has around 5 million rows. It's always reproducible. This is not the same test data as in your previous concurrent-index problem, then? I still had a

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Hannes Dorbath [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Can you please provide a backtrace from gdb? I hope that contains it: http://theendofthetunnel.de/backtrace.log Hmmm --- one thing that jumps out at me is that SplitToVariants assumes (in four places) that the SplitVar.stem arrays

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

Tom Lane wrote: This is not the same test data as in your previous concurrent-index problem, then? I still had a copy of that, so I tried the case, and it doesn't crash on that data ... Teodor Sigaev wrote: I tryed to reproduce the bug but without success. Could you provide a dump of text

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

I think I found at least one part of the problem. I was able to reproduce a crash similar to yours by running the german_ispell dictionary against long random words, and what I found out is that it's possible to overrun the fixed-length buf buffer declared at line 1542 of spell.c. Run till exit

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

believe that matters were reversed? In short, as we often dream that we dream, heaping dream upon dream, may it not be that this half of our life, wherein we think ourselves awake, is itself only a dream on which the others are grafted, from which we wake at death, during which we have as few

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

to the rich, that, if they do it not in the sight of God, they depart from the command of religion. SECTION VI: THE PHILOSOPHERS 339. I can well conceive a man without hands, feet, head (for it is only experience which teaches us that the head is more necessary than

Re: [GENERAL] Segmentation fault with 8.3 FTS ISpell

with the imagination that it is, therefore, obscure and, on the contrary, that what is to prove it is clear, and so we understand it easily. 41. Epigrams of Martial.--Man loves malice, but not against one-eyed men nor the unfortunate, but against the fortunate and proud. People are mistaken in

[GENERAL] Segmentation Fault

Last night one of my databases broke down temporary because of a segmentation fault. It has only happended this time and the database was fully recovered afterwards, but I was wondering what I can do anything to prevent it from happening again It happened while the backup was running (pg_dump

  1   2   >