Re: [HACKERS] Backend crash on non-exclusive backup cancel
On Fri, Mar 24, 2017 at 7:58 PM, Teodor Sigaev wrote: > Thank you all, pushed. Thanks. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
Thank you all, pushed Michael Paquier wrote: On Fri, Mar 24, 2017 at 1:45 AM, Teodor Sigaev wrote: I believe patch looks good and it's ready to commit. Thanks for the review! As I understand, it fixes bug introduced by commit 7117685461af50f50c03f43e6a622284c8d54694 Date: Tue Apr 5 20:03:49 2016 +0200 Implement backup API functions for non-exclusive backups Indeed. And, suppose, it should be backpatched to 9.6? Yes, that's where non-exclusive backups have been introduced. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
On Fri, Mar 24, 2017 at 1:45 AM, Teodor Sigaev wrote: > I believe patch looks good and it's ready to commit. Thanks for the review! > As I understand, it fixes bug introduced by > commit 7117685461af50f50c03f43e6a622284c8d54694 > Date: Tue Apr 5 20:03:49 2016 +0200 > > Implement backup API functions for non-exclusive backups Indeed. > And, suppose, it should be backpatched to 9.6? Yes, that's where non-exclusive backups have been introduced. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
Hi! I believe patch looks good and it's ready to commit. As I understand, it fixes bug introduced by commit 7117685461af50f50c03f43e6a622284c8d54694 Date: Tue Apr 5 20:03:49 2016 +0200 Implement backup API functions for non-exclusive backups And, suppose, it should be backpatched to 9.6? -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
On Thu, Mar 16, 2017 at 12:46 AM, Andres Freund wrote: > Hi, > > On 2017-03-15 15:28:03 +0900, Michael Paquier wrote: >> diff --git a/src/backend/access/transam/xlog.c >> b/src/backend/access/transam/xlog.c >> index 64335f909e..eaf8e32fe1 100644 >> --- a/src/backend/access/transam/xlog.c >> +++ b/src/backend/access/transam/xlog.c >> --- a/src/backend/access/transam/xlogfuncs.c >> +++ b/src/backend/access/transam/xlogfuncs.c >> diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h >> index 104ee7dd5e..d4abf94862 100644 >> --- a/src/include/access/xlog.h >> +++ b/src/include/access/xlog.h >> @@ -288,8 +288,26 @@ extern void assign_max_wal_size(int newval, void >> *extra); >> extern void assign_checkpoint_completion_target(double newval, void *extra); > > This seems like something easy enough to exercise in a tap test, could > we get one? The first problem needs to have a cancel request sent when pg_stop_backup() is running, the second needs to have a session held to see an the inconsistent status of the session lock, which are two concepts foreign to the TAP tests without being able to run the queries asynchronously and keep the sessions alive. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
Hi, On 2017-03-15 15:28:03 +0900, Michael Paquier wrote: > diff --git a/src/backend/access/transam/xlog.c > b/src/backend/access/transam/xlog.c > index 64335f909e..eaf8e32fe1 100644 > --- a/src/backend/access/transam/xlog.c > +++ b/src/backend/access/transam/xlog.c > --- a/src/backend/access/transam/xlogfuncs.c > +++ b/src/backend/access/transam/xlogfuncs.c > diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h > index 104ee7dd5e..d4abf94862 100644 > --- a/src/include/access/xlog.h > +++ b/src/include/access/xlog.h > @@ -288,8 +288,26 @@ extern void assign_max_wal_size(int newval, void *extra); > extern void assign_checkpoint_completion_target(double newval, void *extra); This seems like something easy enough to exercise in a tap test, could we get one? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
On 3/15/17 2:28 AM, Michael Paquier wrote:
> On Wed, Mar 15, 2017 at 12:27 AM, Anastasia Lubennikova
> wrote:
>> As far as I understand, in this thread were discussed two bugs of
>> pg_stop_backup().
>> Thanks to the clear descriptions above, I easily reproduced both of them.
>>
>> BUG#1:
>> Server crashes on assertion on call of pg_stop_backup(false) after
>> interrupted call of pg_stop_backup(false).
>> TRAP: FailedAssertion("!(XLogCtl->Insert.nonExclusiveBackups > 0)", File:
>> "xlog.c", Line: 10747)
>>
>> BUG#2:
>> Failure to start an exclusive backup with the same name, if previous
>> exclusive backup was stopped in another session.
>>
>> Both problems seem to be fixed with patch "backup-session-locks-fixes.patch".
>> Speaking of the patch itself, I have a question: shouldn't we also update
>> sessionBackupState
>> in pg_stop_backup_callback() along with XLogCtl->Insert.exclusiveBackupState?
>
> No, that's not necessary. sessionBackupState is not changed until the
> code path where pg_stop_backup_callback() is active, and remains
> unchanged until it gets deactivated.
>
>> And couple of minor notes:
>> 1) + * Routines to starting stop, and get status of a base backup
>> Probably should be: + * Routines to start, stop and get status of a base
>> backup
>> And also this comment should be moved below the enum.
>>
>> 2) This is used in parallel of the shared memory status
>> s/ in parallel of/ in parallel with
>
> Agreed on both points.
I have tested this patch and it behaves as expected and fixes the
original issue I reported. One nit, I think:
+* SESSION_BACKUP_EXCLUSIVE in this one. Actual verification that an
Would be better phrased as:
+* SESSION_BACKUP_EXCLUSIVE in this function. Actual verification that
an
Thanks,
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed As I see, this bugfix works as expected and the patch is small and clear, so I marked it "Ready for committer". Anyway, it would be great if David could also have a look at the patch. And again, thank you for fixing this issue! The new status of this patch is: Ready for Committer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
On Wed, Mar 15, 2017 at 12:27 AM, Anastasia Lubennikova
wrote:
> As far as I understand, in this thread were discussed two bugs of
> pg_stop_backup().
> Thanks to the clear descriptions above, I easily reproduced both of them.
>
> BUG#1:
> Server crashes on assertion on call of pg_stop_backup(false) after
> interrupted call of pg_stop_backup(false).
> TRAP: FailedAssertion("!(XLogCtl->Insert.nonExclusiveBackups > 0)", File:
> "xlog.c", Line: 10747)
>
> BUG#2:
> Failure to start an exclusive backup with the same name, if previous
> exclusive backup was stopped in another session.
>
> Both problems seem to be fixed with patch "backup-session-locks-fixes.patch".
> Speaking of the patch itself, I have a question: shouldn't we also update
> sessionBackupState
> in pg_stop_backup_callback() along with XLogCtl->Insert.exclusiveBackupState?
No, that's not necessary. sessionBackupState is not changed until the
code path where pg_stop_backup_callback() is active, and remains
unchanged until it gets deactivated.
> And couple of minor notes:
> 1) + * Routines to starting stop, and get status of a base backup
> Probably should be: + * Routines to start, stop and get status of a base
> backup
> And also this comment should be moved below the enum.
>
> 2) This is used in parallel of the shared memory status
> s/ in parallel of/ in parallel with
Agreed on both points.
--
Michael
backup-session-locks-fixes-v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash on non-exclusive backup cancel
As far as I understand, in this thread were discussed two bugs of
pg_stop_backup().
Thanks to the clear descriptions above, I easily reproduced both of them.
BUG#1:
Server crashes on assertion on call of pg_stop_backup(false) after interrupted
call of pg_stop_backup(false).
TRAP: FailedAssertion("!(XLogCtl->Insert.nonExclusiveBackups > 0)", File:
"xlog.c", Line: 10747)
BUG#2:
Failure to start an exclusive backup with the same name, if previous exclusive
backup was stopped in another session.
Both problems seem to be fixed with patch "backup-session-locks-fixes.patch".
Speaking of the patch itself, I have a question: shouldn't we also update
sessionBackupState
in pg_stop_backup_callback() along with XLogCtl->Insert.exclusiveBackupState?
And couple of minor notes:
1) + * Routines to starting stop, and get status of a base backup
Probably should be: + * Routines to start, stop and get status of a base backup
And also this comment should be moved below the enum.
2) This is used in parallel of the shared memory status
s/ in parallel of/ in parallel with
The new status of this patch is: Waiting on Author
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Backend crash during explain
Grant Finnemore <[EMAIL PROTECTED]> writes: > The query with no EXPLAIN (ANALYSE) completes fine. > The query with EXPLAIN ANALYSE completes fine. > However, with just EXPLAIN (no ANALYSE) Need a complete test case please, not just the query. All I get here is ERROR: relation "tagged_asset" does not exist 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: [HACKERS] Backend crash during explain
Grant Finnemore napsal(a):
CrashReporter trace:
Date/Time: 2007-05-31 10:21:39.285 +0200
OS Version: 10.4.9 (Build 8P2137)
Report Version: 4
Command: postmaster
Path:./bin/postmaster
Parent: postmaster [23091]
Version: ??? (???)
PID:23096
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x0018
Thread 0 Crashed:
0 postmaster 0x00116ec6 ExecSetSlotDescriptor + 77 (execTuples.c:344)
1 postmaster 0x001182f9 ExecAssignScanTypeFromOuterPlan + 33
(execUtils.c:771)
2 postmaster 0x001240c8 ExecInitSort + 168 (nodeSort.c:211)
It looks that tupDesc contains invalid pointer. I found some strange
assignment in ExecAssignScanTypeFromOuterPlan function. See comment
bellow. OuterPlanState expects PlaneState structure instead ScanState.
00762 ExecAssignScanTypeFromOuterPlan(ScanState *scanstate)
00763 {
00764 PlanState *outerPlan;
00765 TupleDesc tupDesc;
00766
00767 outerPlan = outerPlanState(scanstate);
^
scanstate->ps ??
00768 tupDesc = ExecGetResultType(outerPlan);
00769
00770 ExecAssignScanType(scanstate, tupDesc);
00771 }
Zdenek
---(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: [HACKERS] Backend Crash
Harvell F <[EMAIL PROTECTED]> writes: > I've got a database corruption/backend crash problem with my 8.1.3 > database on Mac OS X Server 10.4. I'm beginning the process of > trying to recover it. If anyone is interested in trying to fully > understand the what, where, and why of the crash, please contact me. > I've provided the basic information on the crash below. These traces are for psql, not the backend. It looks like you're having an issue with Apple's libedit failing at psql exit, which is something I seem to remember we fixed, so you might want to consider an update from 8.1.3. However, that's got nothing to do with the server-side problem. Since pg_dump's backend is saying that some *other* process crashed, the first thing to do is identify what it is that's crashing. Have you looked in the postmaster log? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Backend Crash
"Harvell F" <[EMAIL PROTECTED]> writes: > Just as a follow up, it turns out that our fiberchannel RAID was power > cycled > while the systems were up and running. There are several write errors in the > postgresql log. > > Now I'm off to try to recover the data... That's still a problem, it indicates either a bug in Postgres or -- sadly more likely -- a problem with your hardware or system software setup. In a working system Postgres guarantees that a situation like that will result in transactions failing to commit (either with errors or freezing), not corrupted data. Data once committed should never be lost. In order for this to happen something in your software and hardware setup must be caching writes then hiding the errors from Postgres. For instance systems where fsync lies and reports success before it has written the data to disk can result in silently corrupted data on any power outage or system crash. Could you send the write errors? Or at least the first page or so of them? And check the system logs at that time for any lower-level errors as well. What kind of drives are in the fibrechannel RAID? Are they SCSI, PATA, or SATA? Can you check their configuration at all or does the RAID hide all that from you? Does the RAID have a battery backed cache? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Backend Crash
Just as a follow up, it turns out that our fiberchannel RAID was power cycled while the systems were up and running. There are several write errors in the postgresql log. Now I'm off to try to recover the data... -- F Harvell 407 467-1919 On 18 Apr 2007, at 10:08, Harvell F wrote: I've got a database corruption/backend crash problem with my 8.1.3 database on Mac OS X Server 10.4. I'm beginning the process of trying to recover it. If anyone is interested in trying to fully understand the what, where, and why of the crash, please contact me. I've provided the basic information on the crash below.
Re: [HACKERS] Backend crash in 8.2.3 with plpgsql function
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane wrote: > SM <[EMAIL PROTECTED]> writes: >> I got a backend crash in Postgresql 8.2.3 with the plpgsql function. >> The following statement in psql causes a signal 11: >> psql=# create function testpl() returns void as 'begin return; >> end;'language 'plpgsql'; > > Worksforme ... For me too. $ psql Welcome to psql 8.2.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit kalman=# create function testpl() returns void as 'begin return; end;'language 'plpgsql'; CREATE FUNCTION kalman=# select version(); version - PostgreSQL 8.2.3 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51) (1 row) Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+V2/7UpzwH2SGd4RAk29AJ44FZFMnsFHJV+uOcQZpuD0cGN/YACgjxjY 4lVP/g+/PLs2+RfOFtpBJtE= =/Vae -END PGP SIGNATURE- ---(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: [HACKERS] Backend crash with tsearch [NAILED][HELP!]
Ok, I nailed the bug, but i'm not sure what the correct fix is. Attached tsearch_morph.diff that remedies this problem by avoiding it. Also there's a debug aid patch if someone would like to know how i finally found it out :) There problem in the lemmatize() function is that GETDICT(...) returned a value not handled (BYLOCALE). The value (-1) and later used as an index into the dicts[] array. After that everything went berserk stack went crazy somehow so trapping the fault sent me to the wrong place, and every time i read the value it was positive ;) So now i just return the initial word passed to the lemmatize function, because i don't know what to do with it. So you tsearch guys will have to work it out :) Magnus tsearch_morph.c.diff Description: Binary data tsearch_morph.c.debugaid Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash with tsearch
Oleg Bartunov <[EMAIL PROTECTED]> wrote:
>
> So, the problem may be in rh 7.3 ?
>
Might be, i'm debugging it now, and i can see that the dicts[] array in
morph.c is beeing overwritten with junk.
I can trigger it with this query:
select txt2txtidx('Can - Live 1971-77');
Is there any good way of adding watches on any type of memory?
(I'm not that good with gdb -yet :))
Magnus
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Backend crash with tsearch
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > >> I'll reinstall tsearch and try again soon. > >> Is it necesary to install OpenFTS contrib aswell, or do i get away > >> with only installing tsearch? > >> Now i do both... > > > > Can you give us the compressed text? I can try it on my installation > > and see if there's the same problem? > > > > Chris > > No i can't, it's not my data to give :( > But it doesn't matter since if you run "gmake installcheck" in > contrib/tsearch it will explode. > > A funny thing is that i installed pg7.3 on an linux intel celeron system > (rh8.0) w/128 mb memory, and THERE it works! > > Athlon dependent? > (Well maybe not, the rest of 7.3 works and passes all regressiontests) So, the problem may be in rh 7.3 ? > > Magnus > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Backend crash with tsearch
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: > > Works on FreeBSD/Alpha for me. Maybe you've got some weirdness with > bad RAM chips or something? > > Chris Could be, but it only shows when i do this, and the server has been up for several months. If everything else failes, i'll run memtest86 on it. Magnus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Backend crash with tsearch
> No i can't, it's not my data to give :( OK > But it doesn't matter since if you run "gmake installcheck" in > contrib/tsearch it will explode. > > A funny thing is that i installed pg7.3 on an linux intel celeron system > (rh8.0) w/128 mb memory, and THERE it works! Works on FreeBSD/Alpha for me. Maybe you've got some weirdness with bad RAM chips or something? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash with tsearch
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote: >> I'll reinstall tsearch and try again soon. >> Is it necesary to install OpenFTS contrib aswell, or do i get away >> with only installing tsearch? >> Now i do both... > > Can you give us the compressed text? I can try it on my installation > and see if there's the same problem? > > Chris No i can't, it's not my data to give :( But it doesn't matter since if you run "gmake installcheck" in contrib/tsearch it will explode. A funny thing is that i installed pg7.3 on an linux intel celeron system (rh8.0) w/128 mb memory, and THERE it works! Athlon dependent? (Well maybe not, the rest of 7.3 works and passes all regressiontests) Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Backend crash with tsearch
> I'll reinstall tsearch and try again soon. > Is it necesary to install OpenFTS contrib aswell, or do i get away with > only installing tsearch? > Now i do both... Can you give us the compressed text? I can try it on my installation and see if there's the same problem? Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash with tsearch
Teodor Sigaev <[EMAIL PROTECTED]> wrote: > > Sorry, I have no any idea. Just only full reinstall (with initdb > and rm -rf /usr/local/pgsql) postgresql... > Can you give me login on you computer for a several hours? > The thing is that when i ran the thing breakpointing on parsetext() at the line of the call i could type "cont" many times. Could there be some kind of memory corruption, someone overwriting memory? Sorry, i can't hand out a login to the box :( I did a total re-install just now, and it still crashes. Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash with tsearch
As you wish... This is a bt taken from a core file this time (the other ones were from attached processes). The whole thing has been recompiled with no additional compiler flags (i.e. removed -march=athlon -O3), but still with --enable-debug and --enable-cassert. Sorry, I have no any idea. Just only full reinstall (with initdb and rm -rf /usr/local/pgsql) postgresql... Can you give me login on you computer for a several hours? -- Teodor Sigaev [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Backend crash with tsearch
Some more (useless) info. objdump -x /lib/*.so /usr/lib/*.so /lib/i686/*.so /usr/kerberos/lib/*.so /usr/local/pgsql/bin/* /usr/local/pgsql/lib/*.so | grep lemmatize reviels only one lemmatize symbol. The offending address 0x02d1 is not mapped anywhere in the address space according to /proc//maps. Nice that the coredump is 522MB ;) Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Backend crash with tsearch
Oleg Bartunov <[EMAIL PROTECTED]> wrote: > Magnus, we need backtrace from 'make installcheck' > As you wish... This is a bt taken from a core file this time (the other ones were from attached processes). The whole thing has been recompiled with no additional compiler flags (i.e. removed -march=athlon -O3), but still with --enable-debug and --enable-cassert. (gdb) bt #0 0x02d1 in ?? () #1 0x401f9071 in parsetext (prs=0xbfffeb70, buf=0x82ca550 "345 [EMAIL PROTECTED] ' http://www.com/ http://aew.werc.ewr/?ad=qwe&dw 1aew.werc.ewr/?ad=qwe&dw 2aew.werc.ewr http://3aew.werc.ewr/?ad=qwe&dw http://4aew.werc.ewr http://5aew.werc.ewr:8100/? ad=qwe&dw 6aew.w"..., buflen=564) at txtidx.c:366 #2 0x401f93c6 in txt2txtidx (fcinfo=0xbfffebe0) at txtidx.c:487 #3 0x080e2af0 in ExecMakeFunctionResult (fcache=0x82cad44, arguments=0x82ca958, econtext=0x82cabc0, isNull=0xbfffed3f "", isDone=0xbfffed40) at execQual.c:839 #4 0x080e2fc1 in ExecEvalFunc (funcClause=0x82ca974, econtext=0x82cabc0, isNull=0xbfffed3f "", isDone=0xbfffed40) at execQual.c:1168 #5 0x080e3755 in ExecEvalExpr (expression=0x82ca974, econtext=0x82cabc0, isNull=0xbfffed3f "", isDone=0xbfffed40) at execQual.c:1715 #6 0x080e3a34 in ExecTargetList (targetlist=0x82ca9a0, nodomains=1, targettype=0x82cac0c, values=0x82cacfc, econtext=0x82cabc0, isDone=0xbfffef28) at execQual.c:2058 #7 0x080e3cc9 in ExecProject (projInfo=0x82cacd0, isDone=0xbfffef28) at execQual.c:2282 #8 0x080e9dcb in ExecResult (node=0x82ca9bc) at nodeResult.c:160 #9 0x080e17e9 in ExecProcNode (node=0x82ca9bc, parent=0x0) at execProcnode.c:280 #10 0x080e05c3 in ExecutePlan (estate=0x82caa74, plan=0x82ca9bc, operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection, destfunc=0x82cad18) at execMain.c:954 #11 0x080dfbfd in ExecutorRun (queryDesc=0x82caa48, estate=0x82caa74, direction=ForwardScanDirection, count=0) at execMain.c:195 #12 0x08132e33 in ProcessQuery (parsetree=0x82bb344, plan=0x82ca9bc, dest=Remote, completionTag=0xb0b0 "") at pquery.c:242 #13 0x08131414 in pg_exec_query_string (query_string=0x82ba124, dest=Remote, parse_context=0x8284684) at postgres.c:838 #14 0x08132535 in PostgresMain (argc=4, argv=0xb2e0, username=0x826fe61 "root") at postgres.c:2016 #15 0x08117b34 in DoBackend (port=0x826fd30) at postmaster.c:2293 #16 0x08117486 in BackendStartup (port=0x826fd30) at postmaster.c:1915 #17 0x08116689 in ServerLoop () at postmaster.c:1000 #18 0x0811623a in PostmasterMain (argc=1, argv=0x82568a0) at postmaster.c:779 #19 0x080f3293 in main (argc=1, argv=0xbc74) at main.c:210 #20 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Backend crash with tsearch
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote: > Teodor Sigaev <[EMAIL PROTECTED]> wrote: > > Pls, send backtrace... :) > > > > I already have, twice. Magnus, we need backtrace from 'make installcheck' > > Magnus > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 3: 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: [HACKERS] Backend crash with tsearch
Teodor Sigaev wrote:
Does it crashed?
# select txt2txtidx('Can - Live 1971-77');
Line txtidx.c:366 :
lemm = lemmatize(token, &lenlemm, type);
lemmatize() is defined in morph.c. Did you use another modules for
postgresql?
It seems to me that we see a name conflict. Function lemmatize is
defined in somewhere also.
Magnus Naeslund(f) wrote:
More info, the gdb> sharedlibrary loaded some more symbols:
(gdb) bt
#0 0x02d1 in ?? ()
#1 0x401faf48 in parsetext (prs=0xbfffea60, buf=0x4277eb3c "Can - Live
1971-77", buflen=18) at txtidx.c:366
#2 0x401fb5e6 in txt2txtidx (fcinfo=0xbfffeaf0) at txtidx.c:487
#3 0x080ec45c in ExecMakeFunctionResult (fcache=0x83172bc,
arguments=0x831187c, econtext=0x8317114, isNull=0xbfffec8f "",
isDone=0xbfffecd8) at execQual.c:839
Pointers 0x40* - functions in tsearch.so, 0x08 - postgres file.
So first string '#0 0x02d1 in ?? ()' has pointer to 'black hole'.
Very strange
--
Teodor Sigaev
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: 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: [HACKERS] Backend crash with tsearch
Teodor Sigaev <[EMAIL PROTECTED]> wrote: > Pls, send backtrace... :) > I already have, twice. Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash with tsearch
Pls, send backtrace... :) Magnus Naeslund(f) wrote: Oleg Bartunov <[EMAIL PROTECTED]> wrote: Magnus, what is an output of 'make installcheck' ? As i said, it segfaults: [root@fet1b tsearch]# gmake installcheck gmake -C ../../src/test/regress pg_regress gmake[1]: Entering directory `/usr/src/postgresql-7.3/src/test/regress' gmake[1]: `pg_regress' is up to date. gmake[1]: Leaving directory `/usr/src/postgresql-7.3/src/test/regress' ../../src/test/regress/pg_regress tsearch (using postmaster on Unix socket, default port) == dropping database "regression" == DROP DATABASE == creating database "regression" == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== test tsearch ... FAILED == 1 of 1 tests failed. == The differences that caused some tests to fail can be viewed in the file `./regression.diffs'. A copy of the test summary that you see above is saved in the file `./regression.out'. gmake: *** [installcheck] Error 1 The regression.diff is attached. Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Teodor Sigaev [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Backend crash with tsearch
Teodor Sigaev <[EMAIL PROTECTED]> wrote:
> Does it crashed?
> # select txt2txtidx('Can - Live 1971-77');
>
>
> Line txtidx.c:366 :
> lemm = lemmatize(token, &lenlemm, type);
>
> lemmatize() is defined in morph.c. Did you use another modules for
> postgresql?
>
> It seems to me that we see a name conflict. Function lemmatize is
> defined in somewhere also.
>
>
This is what i found out aswell, but isn't lemmatize resolved at
compiletime?
The only other module is Search-OpenFTS.
I'll check if i see any conflicts in $prefix/lib
Magnus
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Backend crash with tsearch
Oleg Bartunov <[EMAIL PROTECTED]> wrote: > Magnus, > > what is an output of 'make installcheck' ? As i said, it segfaults: [root@fet1b tsearch]# gmake installcheck gmake -C ../../src/test/regress pg_regress gmake[1]: Entering directory `/usr/src/postgresql-7.3/src/test/regress' gmake[1]: `pg_regress' is up to date. gmake[1]: Leaving directory `/usr/src/postgresql-7.3/src/test/regress' ../../src/test/regress/pg_regress tsearch (using postmaster on Unix socket, default port) == dropping database "regression" == DROP DATABASE == creating database "regression" == CREATE DATABASE ALTER DATABASE == dropping regression test user accounts == == installing PL/pgSQL== == running regression test queries== test tsearch ... FAILED == 1 of 1 tests failed. == The differences that caused some tests to fail can be viewed in the file `./regression.diffs'. A copy of the test summary that you see above is saved in the file `./regression.out'. gmake: *** [installcheck] Error 1 The regression.diff is attached. Magnus regression.diffs Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Backend crash with tsearch
Does it crashed?
# select txt2txtidx('Can - Live 1971-77');
Line txtidx.c:366 :
lemm = lemmatize(token, &lenlemm, type);
lemmatize() is defined in morph.c. Did you use another modules for postgresql?
It seems to me that we see a name conflict. Function lemmatize is defined in
somewhere also.
Magnus Naeslund(f) wrote:
More info, the gdb> sharedlibrary loaded some more symbols:
(gdb) bt
#0 0x02d1 in ?? ()
#1 0x401faf48 in parsetext (prs=0xbfffea60, buf=0x4277eb3c "Can - Live
1971-77", buflen=18) at txtidx.c:366
#2 0x401fb5e6 in txt2txtidx (fcinfo=0xbfffeaf0) at txtidx.c:487
#3 0x080ec45c in ExecMakeFunctionResult (fcache=0x83172bc,
arguments=0x831187c, econtext=0x8317114, isNull=0xbfffec8f "",
isDone=0xbfffecd8) at execQual.c:839
#4 0x080ed023 in ExecEvalExpr (expression=0x8311898,
econtext=0x8317114, isNull=0xbfffec8f "", isDone=0xbfffecd8)
at execQual.c:1168
#5 0x080ed3c4 in ExecTargetList (targetlist=0x8311b20, nodomains=21,
targettype=0x8312b1c, values=0x83180a0,
econtext=0x8317114, isDone=0xbfffee78) at execQual.c:2058
#6 0x080ed7bf in ExecProject (projInfo=0x8317f90, isDone=0xbfffee78) at
execQual.c:2282
#7 0x080ed8a9 in ExecScan (node=0x8315e60, accessMtd=0x80f4fa0
) at execScan.c:133
#8 0x080f4e73 in ExecSeqScan (node=0x8315e60) at nodeSeqscan.c:133
#9 0x080eafbc in ExecProcNode (node=0x8315e60, parent=0x0) at
execProcnode.c:291
#10 0x080e99f7 in ExecutePlan (estate=0x83161ac, plan=0x8315e60,
operation=CMD_UPDATE, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x8317fbc) at
execMain.c:954
#11 0x080ea999 in ExecutorRun (queryDesc=0x831718c, estate=0x83161ac,
direction=ForwardScanDirection, count=0) at execMain.c:195
#12 0x08143b9b in ProcessQuery (parsetree=0x830c8c4, plan=0x8315e60,
dest=Remote, completionTag=0xb060 "") at pquery.c:242
#13 0x08141dc1 in pg_exec_query_string (query_string=0x830c79c,
dest=Remote, parse_context=0x82d6e88) at postgres.c:838
#14 0x08142e1d in PostgresMain (argc=4, argv=0xb2e0,
username=0x82c23a9 "mag") at postgres.c:2016
#15 0x08125544 in DoBackend (port=0x82c2278) at postmaster.c:2293
#16 0x08124e5c in BackendStartup (port=0x82c2278) at postmaster.c:1915
#17 0x0812430d in ServerLoop () at postmaster.c:1000
#18 0x08123e94 in PostmasterMain (argc=1, argv=0x8276d00) at
postmaster.c:779
#19 0x080fefe2 in main (argc=1, argv=0xbc74) at main.c:210
#20 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
Magnus
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
Teodor Sigaev
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Backend crash with tsearch
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote: > Oleg Bartunov <[EMAIL PROTECTED]> wrote: > > > > Please, tell us postgresql version. Did you reinstall tsearch after > > upgrading ? Test-suite (data, sql) demonstrated the problem would be > > nice. > > > > pgsql 7.3, about 700mb text database with product descriptions. > I'm working on isolation the behavior, the tsearch make installcheck > seems to be crashing aswell. > Is a "psql regression < tsearch.sql" needed, or is that done > automatically in the installcheck? Magnus, what is an output of 'make installcheck' ? > > > For contrib/tsearch you need only tsearch :) > > > > :) > > I hope this is because of something silly. > > Magnus > > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash with tsearch
More info, the gdb> sharedlibrary loaded some more symbols: (gdb) bt #0 0x02d1 in ?? () #1 0x401faf48 in parsetext (prs=0xbfffea60, buf=0x4277eb3c "Can - Live 1971-77", buflen=18) at txtidx.c:366 #2 0x401fb5e6 in txt2txtidx (fcinfo=0xbfffeaf0) at txtidx.c:487 #3 0x080ec45c in ExecMakeFunctionResult (fcache=0x83172bc, arguments=0x831187c, econtext=0x8317114, isNull=0xbfffec8f "", isDone=0xbfffecd8) at execQual.c:839 #4 0x080ed023 in ExecEvalExpr (expression=0x8311898, econtext=0x8317114, isNull=0xbfffec8f "", isDone=0xbfffecd8) at execQual.c:1168 #5 0x080ed3c4 in ExecTargetList (targetlist=0x8311b20, nodomains=21, targettype=0x8312b1c, values=0x83180a0, econtext=0x8317114, isDone=0xbfffee78) at execQual.c:2058 #6 0x080ed7bf in ExecProject (projInfo=0x8317f90, isDone=0xbfffee78) at execQual.c:2282 #7 0x080ed8a9 in ExecScan (node=0x8315e60, accessMtd=0x80f4fa0 ) at execScan.c:133 #8 0x080f4e73 in ExecSeqScan (node=0x8315e60) at nodeSeqscan.c:133 #9 0x080eafbc in ExecProcNode (node=0x8315e60, parent=0x0) at execProcnode.c:291 #10 0x080e99f7 in ExecutePlan (estate=0x83161ac, plan=0x8315e60, operation=CMD_UPDATE, numberTuples=0, direction=ForwardScanDirection, destfunc=0x8317fbc) at execMain.c:954 #11 0x080ea999 in ExecutorRun (queryDesc=0x831718c, estate=0x83161ac, direction=ForwardScanDirection, count=0) at execMain.c:195 #12 0x08143b9b in ProcessQuery (parsetree=0x830c8c4, plan=0x8315e60, dest=Remote, completionTag=0xb060 "") at pquery.c:242 #13 0x08141dc1 in pg_exec_query_string (query_string=0x830c79c, dest=Remote, parse_context=0x82d6e88) at postgres.c:838 #14 0x08142e1d in PostgresMain (argc=4, argv=0xb2e0, username=0x82c23a9 "mag") at postgres.c:2016 #15 0x08125544 in DoBackend (port=0x82c2278) at postmaster.c:2293 #16 0x08124e5c in BackendStartup (port=0x82c2278) at postmaster.c:1915 #17 0x0812430d in ServerLoop () at postmaster.c:1000 #18 0x08123e94 in PostmasterMain (argc=1, argv=0x8276d00) at postmaster.c:779 #19 0x080fefe2 in main (argc=1, argv=0xbc74) at main.c:210 #20 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Backend crash with tsearch
Oleg Bartunov <[EMAIL PROTECTED]> wrote: > > Please, tell us postgresql version. Did you reinstall tsearch after > upgrading ? Test-suite (data, sql) demonstrated the problem would be > nice. > pgsql 7.3, about 700mb text database with product descriptions. I'm working on isolation the behavior, the tsearch make installcheck seems to be crashing aswell. Is a "psql regression < tsearch.sql" needed, or is that done automatically in the installcheck? > For contrib/tsearch you need only tsearch :) > :) I hope this is because of something silly. Magnus ---(end of broadcast)--- TIP 3: 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: [HACKERS] Backend crash with tsearch
On Tue, 3 Dec 2002, Magnus Naeslund(f) wrote: > I'm evaluating tsearch contrib module, and i get a backend crash when > i'm about to use a tsearch function. > > When i issue > update things set nidx=txt2txtidx(productname), > didx=txt2txtidx(longdescription); > > The backend dies in a segfault. > The system is redhat 7.3 dual athlon w/ 1GB memory. > Postgresql is compiled with -march=athlon -O3. > initdb -E LATIN1 Please, tell us postgresql version. Did you reinstall tsearch after upgrading ? Test-suite (data, sql) demonstrated the problem would be nice. > > I have a huge shared buffer count (65536). > > I'll reinstall tsearch and try again soon. > Is it necesary to install OpenFTS contrib aswell, or do i get away with > only installing tsearch? For contrib/tsearch you need only tsearch :) > Now i do both... > > Backtrace: > > #0 0x02d1 in ?? () > #1 0x401faf48 in ?? () > #2 0x401fb5e6 in ?? () > #3 0x080d8f5c in ExecMakeFunctionResult (fcache=0x82d3710, > arguments=0x82ce170, econtext=0x82d3580, isNull=0xbfffec8f "", > isDone=0xbfffecd8) at execQual.c:839 > #4 0x080d99a3 in ExecEvalExpr (expression=0x82ce188, > econtext=0x82d3580, isNull=0xbfffec8f "", isDone=0xbfffecd8) > at execQual.c:1168 > #5 0x080d9d44 in ExecTargetList (targetlist=0x82ce3d8, nodomains=21, > targettype=0x82cf230, values=0x82d4488, > econtext=0x82d3580, isDone=0xbfffee78) at execQual.c:2058 > #6 0x080da13f in ExecProject (projInfo=0x82d3b08, isDone=0xbfffee78) at > execQual.c:2282 > #7 0x080da229 in ExecScan (node=0x82cfeb8, accessMtd=0x80e1270 > ) at execScan.c:133 > #8 0x080e1093 in ExecSeqScan (node=0x82cfeb8) at nodeSeqscan.c:133 > #9 0x080d7d9c in ExecProcNode (node=0x82cfeb8, parent=0x0) at > execProcnode.c:291 > #10 0x080d6a47 in ExecutePlan (estate=0x82d, plan=0x82cfeb8, > operation=CMD_UPDATE, numberTuples=0, > direction=ForwardScanDirection, destfunc=0x82d3b30) at > execMain.c:954 > #11 0x080d7682 in ExecutorRun (queryDesc=0x82d35f0, estate=0x82d, > direction=ForwardScanDirection, count=0) at execMain.c:195 > #12 0x0812a8cb in ProcessQuery (parsetree=0x82cb1c8, plan=0x82cfeb8, > dest=Remote, completionTag=0xb060 "") at pquery.c:242 > #13 0x08128b81 in pg_exec_query_string (query_string=0x82cb0a8, > dest=Remote, parse_context=0x8291cd0) at postgres.c:838 > #14 0x08129b50 in PostgresMain (argc=4, argv=0xb2e0, > username=0x827ccd1 "mag") at postgres.c:2016 > #15 0x0810f0c4 in DoBackend (port=0x827cba0) at postmaster.c:2293 > #16 0x0810e9dc in BackendStartup (port=0x827cba0) at postmaster.c:1915 > #17 0x0810de8d in ServerLoop () at postmaster.c:1000 > #18 0x0810da24 in PostmasterMain (argc=1, argv=0x8245640) at > postmaster.c:779 > #19 0x080ea5c2 in main (argc=1, argv=0xbc74) at main.c:210 > #20 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6 > > Magnus > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Programmer/Networker [|] Magnus Naeslund > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > ---(end of broadcast)--- > TIP 3: 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 > Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Backend crash with tsearch
Tom Lane <[EMAIL PROTECTED]> wrote: > > Be sure to eliminate the possibility that you're loading the wrong > version of the .so (ie, loading a 7.2 tsearch.so into 7.3). People > get bit by that quite frequently right after an upgrade ... > Well, this is a clean install, so that isn't a problem. Magnus ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Backend crash with tsearch
"Magnus Naeslund\(f\)" <[EMAIL PROTECTED]> writes: > It's either that it can't load the lib (shouldn't it complain?) or it's > a bad pointer. Be sure to eliminate the possibility that you're loading the wrong version of the .so (ie, loading a 7.2 tsearch.so into 7.3). People get bit by that quite frequently right after an upgrade ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Backend crash with tsearch
Tom Lane <[EMAIL PROTECTED]> wrote: > "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes: >> The backend dies in a segfault. > >> Backtrace: > >> #0 0x02d1 in ?? () >> #1 0x401faf48 in ?? () >> #2 0x401fb5e6 in ?? () >> #3 0x080d8f5c in ExecMakeFunctionResult (fcache=0x82d3710, >> arguments=0x82ce170, econtext=0x82d3580, isNull=0xbfffec8f "", >> isDone=0xbfffecd8) at execQual.c:839 > > Did you compile tsearch with debug support? If so, the lack of any > symbolic info here must mean that gdb didn't know where to find the > tsearch .so module. You could get a more useful trace by telling > gdb > sharedlibrary /path/to/tsearch.so > > regards, tom lane > I'm working on it (--enable-debug --enable-cassert). It's either that it can't load the lib (shouldn't it complain?) or it's a bad pointer. We'll find out, i hope... Magnus ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash with tsearch
"Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes: > The backend dies in a segfault. > Backtrace: > #0 0x02d1 in ?? () > #1 0x401faf48 in ?? () > #2 0x401fb5e6 in ?? () > #3 0x080d8f5c in ExecMakeFunctionResult (fcache=0x82d3710, > arguments=0x82ce170, econtext=0x82d3580, isNull=0xbfffec8f "", > isDone=0xbfffecd8) at execQual.c:839 Did you compile tsearch with debug support? If so, the lack of any symbolic info here must mean that gdb didn't know where to find the tsearch .so module. You could get a more useful trace by telling gdb sharedlibrary /path/to/tsearch.so regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Backend crash (long)
I've definitely seen errors from including vacuum and/or analyze
statements in functions, I think I've seen crashes too. If you check the
docs I'm pretty sure they mention the specifics of not being able to use
such statements.
Robert Treat
On Wed, 2002-09-18 at 04:09, Michael Paesold wrote:
> Hi all,
>
> I have written a test function, that will create a sequence and a table,
> than insert one million rows into the table, analyze the table and create an
> index on one of the columns.
> (so this will all happen inside on transaction)
>
> After doing that, the backend will crash.
> (but the data will be inserted)
>
> If I comment out the table analyzing and the create index (I have not tested
> which on leads to the crash), everything works fine. I have sent a copy of
> the error log, the psql session, the function and some parts of my
> postgresql.conf file.
>
> My system is RedHat 7.2, Kernel 2.4.9-34, glibc-2.2.4, gcc 2.96, PostgreSQL
> 7.2.2 built from source.
>
> If you want, I could try other combinations of create/insert/analyze etc. to
> test the exact steps needed to crash the backend.
>
> I know what I am doing is not really standard. This was rather a stability
> test of postgres :). What do you think about this all?
>
> Best Regards,
> Michael Paesold
>
>
> --> logfile:
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> 'bench_big_pkey' for table 'bench_big'
> DEBUG: recycled transaction log file 009F
> [...skipping: recycled transaction log file 00A0 to
> 00AE]
> DEBUG: recycled transaction log file 00B0
> DEBUG: Analyzing bench_big
> DEBUG: server process (pid 13840) was terminated by signal 11
> DEBUG: terminating any other active server processes
> DEBUG: all server processes terminated; reinitializing shared memory and
> semaphores
> DEBUG: database system was interrupted at 2002-09-17 11:45:56 CEST
> DEBUG: checkpoint record is at 0/B41170A4
> DEBUG: redo record is at 0/B400DF34; undo record is at 0/0; shutdown FALSE
> DEBUG: next transaction id: 96959; next oid: 6282462
> DEBUG: database system was not properly shut down; automatic recovery in
> progress
> DEBUG: redo starts at 0/B400DF34
> DEBUG: ReadRecord: record with zero length at 0/B495F754
> DEBUG: redo done at 0/B495F730
> DEBUG: recycled transaction log file 00B2
> DEBUG: recycled transaction log file 00B1
> DEBUG: recycled transaction log file 00B3
> DEBUG: database system is ready
>
> The first time I tried the insert, there was an additional notice from
> another backend, just after the line "DEBUG: terminating any other active
> server processes":
> NOTICE: Message from PostgreSQL backend:
> The Postmaster has informed me that some other backend
> died abnormally and possibly corrupted shared memory.
> I have rolled back the current transaction and am
> going to terminate your database system connection and exit.
> Please reconnect to the database system and repeat your query.
>
> --> in psql:
> billing=# select create_benchmark ();
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
> 'bench_big_pkey' for table 'bench_big'
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !# \c
> Password:
> You are now connected to database billing as user billing.
> billing=# select real_time from bench_big where int_id in (1, 100);
>real_time
> ---
> 2002-09-17 11:32:22.63334+02
> 2002-09-17 11:46:16.601282+02
> (2 rows)
>
> --> all rows have definatly been inserted!
>
>
> --> the trigger function:
>
> CREATE OR REPLACE FUNCTION create_benchmark () RETURNS BOOLEAN AS '
> DECLARE
> char100 VARCHAR :=
> \'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZäöüÄÖÜß1234567890!"§$%
> &/()=?+*#<>|-_,;.:^°{}´`[]\';
> r1 INTEGER;
> r2 INTEGER;
> r3 INTEGER;
> BEGIN
> CREATE SEQUENCE bench_seq;
>
> CREATE TABLE bench_big (
> int_id INTEGER NOT NULL default nextval(\'bench_seq\'),
> bigint_id BIGINT NOT NULL,
> sometext1 VARCHAR (50),
> sometext2 VARCHAR (50),
> sometext3 VARCHAR (50),
> trx_time TIME WITHOUT TIME ZONE NOT NULL default CURRENT_TIME,
> trx_timestamp TIMESTAMP WITHOUT TIME ZONE NOT NULL default
> CURRENT_TIMESTAMP,
> trx_date DATE NOT NULL default CURRENT_DATE,
> real_time TIMESTAMP NOT NULL default timeofday(),
> someboolean1 BOOLEAN NOT NULL,
> someboolean2 BOOLEAN NOT NULL,
> PRIMARY KEY (int_id)
> );
>
> FOR i IN 1..100 LOOP
> r1 = CAST( RANDOM() * 49 AS INTEGER );
> r2 = CAST( RANDOM() * 49 AS INTEGER );
> r3 = CAST( RANDOM() * 49 AS INTEGER );
>
> INSERT INTO bench_big
> (bigint_id, sometext1, sometext2, sometext3, someboolean1,
> some
Re: [HACKERS] Backend crash (long)
Rod Taylor <[EMAIL PROTECTED]> writes: > On Wed, 2002-09-18 at 11:03, Tom Lane wrote: >> "Michael Paesold" <[EMAIL PROTECTED]> writes: > I have written a test function, that will create a sequence and a table, > than insert one million rows into the table, analyze the table and create an > index on one of the columns. >> >> You can't run ANALYZE inside a function. In CVS tip there's a check to >> prevent the VACUUM variant of this problem, but I'm not sure if it >> handles the ANALYZE variant (yet). > ANALYZE in 7.3 works fine in a transaction, so it shouldn't it be able > to work in a function as well? Possibly it's okay in 7.3; I have a note to look at that, but haven't done it yet. I think REINDEX has the same problem btw ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Backend crash (long)
On Wed, 2002-09-18 at 11:03, Tom Lane wrote: > "Michael Paesold" <[EMAIL PROTECTED]> writes: > > I have written a test function, that will create a sequence and a table, > > than insert one million rows into the table, analyze the table and create an > > index on one of the columns. > > You can't run ANALYZE inside a function. In CVS tip there's a check to > prevent the VACUUM variant of this problem, but I'm not sure if it > handles the ANALYZE variant (yet). ANALYZE in 7.3 works fine in a transaction, so it shouldn't it be able to work in a function as well? rbt=# begin; BEGIN rbt=# analyze; ANALYZE rbt=# commit; COMMIT rbt=# create function test() returns bool as 'analyze; select true;' language 'sql'; CREATE FUNCTION rbt=# select test(); test -- t (1 row) -- Rod Taylor ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Backend crash (long)
"Michael Paesold" <[EMAIL PROTECTED]> writes: > I have written a test function, that will create a sequence and a table, > than insert one million rows into the table, analyze the table and create an > index on one of the columns. You can't run ANALYZE inside a function. In CVS tip there's a check to prevent the VACUUM variant of this problem, but I'm not sure if it handles the ANALYZE variant (yet). regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Backend crash (segfault) on query with inheritance hierarchy
"Oliver Elphick" <[EMAIL PROTECTED]> writes: > Table `job' is inherited by `manufactured_job' and `purchased_job'. This > query works on either inherited table but not on the whole hierarchy: I've committed a fix to CVS. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
