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 which have been recompiled o
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
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 (amd
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
: [GENERAL] segmentation fault postgres 9.3.5 core dump perlu
related ?
On Feb 12, 2015, at 3:21 PM, Day, David
mailto: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
> On Feb 12, 2015, at 3:21 PM, Day, David 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 Feb 11.
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 th
On Fri, Jan 30, 2015 at 9:54 AM, Day, David 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.
>
> The
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 ?
On
On Thu, Jan 29, 2015 at 1:54 PM, Day, David 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 plperlu proced
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
On Thu, Jan 29, 2015 at 8:40 AM, Tom Lane wrote:
> "Day, David" 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 i
"Day, David" 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 there are no
int
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
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
On Wed, Jan 28, 2015 at 1:23 PM, Day, David 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 relate to some
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 THREADS
"Day, David" 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 to
use that
Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 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" writes:
> We are developing on and runnin
"Day, David" 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 something to
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
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:
http
On 03/04/2014 07:39 AM, Adrian Klaver wrote:
CCing list:
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 try
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
er
ajay 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 in Solaris , it
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 m
Alan Nilsson 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 diagnose where it is
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 m
Alan Nilsson 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 code:
>
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) ==
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 --for
On Sun, Sep 15, 2013 at 8:02 PM, Robert Nix 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 you be all
>
> 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 provid
On Sun, Sep 15, 2013 at 5:06 PM, Robert Nix 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 you drop th
> 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?
>
On Sat, Sep 14, 2013 at 6:40 PM, 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=cust
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" >> "pg_upgrade
(2013/06/12 0:03), Tom Lane wrote:
> Hiroshi Inoue 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.
1. Implement
Hiroshi Inoue 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 subscription:
h
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 has
| 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 12GB
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
On 2013-04-10 19:29:06 -0400, Tom Lane wrote:
> Andres Freund 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
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 ,
rStartup = 0x459550 ,
rShutdown = 0x458a20 ,
rDestroy = 0x458a10 , mydest = DestRemoteExec
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
Andres Freund 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)
>> created to e
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
> 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) p
Andres Freund 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 time, right?
It loo
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
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,
> i
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
Andres Freund 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 PreCommit_Portals() got rid of it when
> 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,
complet
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
> save_co
Hi Andres!
On Wed, Apr 10, 2013 at 4:49 PM, Andres Freund wrote:
> 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 < owner->maxcatrefs)
(gdb) bt
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: som
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 ResourceOwnerEnla
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 12
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.
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 proce
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
0
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
postgres[40+49500
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
--enable-debug
neral@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 of different reasons,
I will try produce one and submit to here.
- Original Message -
From: "Craig Ringer"
To: "Benson Jin"
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 wrot
2012/6/11 Benson Jin :
> 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 1
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?
http://wiki.pos
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 signa
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
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 (SIGS
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 wrote:
> Craig Ringer writes:
> > I ask in particular because there have been big problems caused by
> > building PostgreSQL as a universa
Craig Ringer 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 x86_64 as well as ppc32/p
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
Sulman Sarwar 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 ... gets_fromFile certainly looks
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.
---
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.
On Thu, 2009-01-22 at 23:42 -0500, Tom Lane wrote:
> Nick Withers 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
> > p
Nick Withers 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 query accessing a t
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 6
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 sym
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
> 'pg_valid_ser
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 bind
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 versi
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
thi
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 feet).
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
princ
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
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 col
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 a
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
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
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 t
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
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 / pr
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
-
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.
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 ri
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)
Welcom
=?ISO-8859-1?Q?Poul_M=F8ller_Hansen?= <[EMAIL PROTECTED]> writes:
>> Given that you're using duration logging and JDBC, I wonder whether you
>> didn't trip over this recently-identified bug:
>> http://archives.postgresql.org/pgsql-hackers/2006-08/msg00815.php
>> Patch is here:
>> http://archives.po
1 - 100 of 114 matches
Mail list logo
