Обсуждение: Core dump on PG 7.1.3
Hello,
I have pretty serious problem ...
~~~~~~~~~~~
Summary: On our production database, we are consistently getting core dumps
when trying to execute a particular sequence of queries.
~~~~~~~~~~~
Platform:
Redhat 7.1 (the kernel appears to be 2.4.2-2)
Postgres 7.1.3 (SELECT version() reports "PostgreSQL 7.1.3 on
i686-pc-linux-gnu, compiled by GCC 2.96")
~~~~~~~~~~~
Here is the actual query that causes the core dump ... It is basically
trying to update ~20k rows
UPDATE campaign_email
SET campaign_email_status = 2,
campaign_email_last_modified = message_queue.last_modification
FROM message_queue, message_queue_purge_lock
WHERE message_queue.message_id = message_queue_purge_lock.message_id
AND message_queue.campaign_email_id = campaign_email.campaign_email_id;
~~~~~~~~~~~
Relevant schema (if you want the entire schema, i can send that along too
... we have FK constraints setup)
Table "message_queue"
Attribute | Type | Modifier
-------------------------+--------------------------+----------------------
message_id | integer | not null
status | character(1) | not null default 'N'
lock_holder_session_id | character varying(16) |
campaign_id | integer | not null
campaign_email_id | integer | not null
Index: message_queue_pkey
Table "message_queue_purge_lock"
Attribute | Type | Modifier
------------+---------+----------
message_id | integer | not null
Index: message_queue_purge_lock_pkey
Table "campaign_email"
Attribute | Type | Modifier
------------------------------+--------------------------+----------
campaign_email_id | numeric(11,0) | not null
campaign_id | numeric(11,0) | not null
campaign_email_status | numeric(2,0) | not null
campaign_email_last_modified | timestamp with time zone | not null
campaign_email_detail | character varying(500) |
impression_date | timestamp with time zone |
Indices: campaign_email_bounce_date_idx,
campaign_email_optout_date_idx,
campaign_email_pkey,
email_campaign_idx,
email_campaign_patron_unq,
email_patron_idx
~~~~~~~~~~~
The Postgres log file reports the following:
Server process (pid 24542) exited with status 139 at Mon Apr 1 11:40:20
2002
Terminating any 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.
The Data Base System is in recovery mode
Server processes were terminated at Mon Apr 1 11:40:20 2002
Reinitializing shared memory and semaphores
DEBUG: database system was interrupted at 2002-04-01 11:40:12 EST
DEBUG: CheckPoint record at (7, 3892464228)
DEBUG: Redo record at (7, 3892371300); Undo record at (0, 0); Shutdown
FALSE
DEBUG: NextTransactionId: 14376178; NextOid: 7673608
DEBUG: database system was not properly shut down; automatic recovery in
progress...
DEBUG: redo starts at (7, 3892371300)
The Data Base System is starting up
DEBUG: ReadRecord: record with zero len at (7, 3939513968)
DEBUG: redo done at (7, 3939513900)
The Data Base System is starting up
The Data Base System is starting up
The Data Base System is starting up
DEBUG: MoveOfflineLogs: remove 00000007000000E7
The Data Base System is starting up
DEBUG: database system is in production state
~~~~~~~~~~~
I didn't compile Postgres with debug symbols turned on so the backtrace from
the core dump is pretty useless looking
ore was generated by `postgres: postgres bnmail [local] UPDATE '.
Program terminated with signal 11, Segmentation fault.
#0 0x080b995f in ?? ()
(gdb) bt
#0 0x080b995f in ?? ()
#1 0x080ba4e5 in ?? ()
#2 0x080b9f37 in ?? ()
#3 0x080b9fb0 in ?? ()
#4 0x080ba1a1 in ?? ()
#5 0x080ba561 in ?? ()
#6 0x080b9f37 in ?? ()
#7 0x080b9fb0 in ?? ()
#8 0x080ba14d in ?? ()
#9 0x080ba555 in ?? ()
#10 0x080ba666 in ?? ()
#11 0x080bdfbd in ?? ()
#12 0x080bab13 in ?? ()
#13 0x080be194 in ?? ()
#14 0x080b928d in ?? ()
#15 0x080bfa08 in ?? ()
#16 0x080b92c9 in ?? ()
#17 0x080b8f16 in ?? ()
#18 0x080b8eee in ?? ()
#19 0x080b8847 in ?? ()
#20 0x080b84e1 in ?? ()
#21 0x080b79a8 in ?? ()
#22 0x080fc8d7 in ?? ()
#23 0x080fb3e6 in ?? ()
#24 0x080fc3ce in ?? ()
#25 0x080e7430 in ?? ()
#26 0x080e7023 in ?? ()
#27 0x080e628d in ?? ()
#28 0x080e5cd8 in ?? ()
#29 0x080c743f in ?? ()
#30 0x400ed306 in ?? ()
~~~~~~~~~~~
Here's the ultimate irony ... I cannot reproduce this bug on our
non-production database ... that means that I am unable to do the standard
experimentation that would further help diagnose this problem ... Reducing
the size of the data set, reducing the complexity of the tables, removing
the FK constraints ... all of those things are not an option on production
data ... However, since this problem needs to be fixed, I see myself being
able to do one of two things ...
- Recompiling PG 7.1.3 using the debug symbols ..
- Upgrading to PG 7.2
Is there anything I'm missing here that I could try that is non-invasive?
Thanks in advance
-Dave
"David Esposito" <dvesposito@newnetco.com> writes:
> However, since this problem needs to be fixed, I see myself being
> able to do one of two things ...
> - Recompiling PG 7.1.3 using the debug symbols ..
> - Upgrading to PG 7.2
> Is there anything I'm missing here that I could try that is non-invasive?
Recompiling with debug symbols should be reasonably non-invasive,
assuming that you can otherwise duplicate the configuration options.
(If you're using locally built executables this shouldn't be hard;
not sure what's involved if you are using RPMs that came from somewhere
else.)
Updating to 7.2 would imply a dump and restore, which'd very likely make
the problem go away --- but then we'd not learn anything about what
caused the crash. If the underlying bug still exists in 7.2 then it
might someday bite you again. Are you more interested in getting up and
running ASAP, or in helping to debug the problem?
regards, tom lane
Hopefully I'll have permission to take the application down for an hour tomorrow to do a more complete diagnosis ... The first thing I'll do is recompile with debug symbols and I'll post the more helpful back trace ... Yes, I would like to help debug the problem ... and I'd be even more eager if it wasn't production hardware that i have to tip-toe around on .. ;) Thanks for the speedy response .. -dave > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Monday, April 01, 2002 4:17 PM > To: David Esposito > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Core dump on PG 7.1.3 > > > "David Esposito" <dvesposito@newnetco.com> writes: > > However, since this problem needs to be fixed, I see myself being > > able to do one of two things ... > > - Recompiling PG 7.1.3 using the debug symbols .. > > - Upgrading to PG 7.2 > > Is there anything I'm missing here that I could try that is > non-invasive? > > Recompiling with debug symbols should be reasonably non-invasive, > assuming that you can otherwise duplicate the configuration options. > (If you're using locally built executables this shouldn't be hard; > not sure what's involved if you are using RPMs that came from somewhere > else.) > > Updating to 7.2 would imply a dump and restore, which'd very likely make > the problem go away --- but then we'd not learn anything about what > caused the crash. If the underlying bug still exists in 7.2 then it > might someday bite you again. Are you more interested in getting up and > running ASAP, or in helping to debug the problem? > > regards, tom lane
Ok, I'll be the first to admit that my GDB debugging skills are not all that strong ... ;) Here's what I did to compile postgres 7.1.3 ./configure --enable-debug gmake CPPFLAGS=-DALLOW_ABSOLUTE_DBPATHS all gmake install (i could see that it was compiling debug info into the executables since the "-g" flag was being used with the gcc commands) So then I fired up postgres and managed to get it to crash again ... I changed to the directory containing the core dump and ran gdb gdb -c core once GDB started, i typed "bt" and, again, i just got the hex addresses and no pretty function names or line numbers ... am I doing something wrong? Core was generated by `postgres: postgres bnmail [local] UPDATE '. Program terminated with signal 11, Segmentation fault. #0 0x080b992b in ?? () (gdb) bt #0 0x080b992b in ?? () #1 0x080ba4b1 in ?? () #2 0x080b9f03 in ?? () #3 0x080b9f7c in ?? () #4 0x080ba16d in ?? () #5 0x080ba52d in ?? () #6 0x080b9f03 in ?? () #7 0x080b9f7c in ?? () #8 0x080ba119 in ?? () #9 0x080ba521 in ?? () #10 0x080ba632 in ?? () #11 0x080bdf89 in ?? () #12 0x080baadf in ?? () #13 0x080be160 in ?? () #14 0x080b9259 in ?? () #15 0x080bf9d4 in ?? () #16 0x080b9295 in ?? () #17 0x080b8ee2 in ?? () #18 0x080b8eba in ?? () #19 0x080b8813 in ?? () #20 0x080b84ad in ?? () #21 0x080b7974 in ?? () #22 0x080fc8b7 in ?? () #23 0x080fb3c6 in ?? () #24 0x080fc3ae in ?? () #25 0x080e7408 in ?? () #26 0x080e6ffb in ?? () #27 0x080e6265 in ?? () #28 0x080e5cb0 in ?? () #29 0x080c7417 in ?? () #30 0x400ed306 in ?? () > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Monday, April 01, 2002 4:17 PM > To: David Esposito > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] Core dump on PG 7.1.3 > > > "David Esposito" <dvesposito@newnetco.com> writes: > > However, since this problem needs to be fixed, I see myself being > > able to do one of two things ... > > - Recompiling PG 7.1.3 using the debug symbols .. > > - Upgrading to PG 7.2 > > Is there anything I'm missing here that I could try that is > non-invasive? > > Recompiling with debug symbols should be reasonably non-invasive, > assuming that you can otherwise duplicate the configuration options. > (If you're using locally built executables this shouldn't be hard; > not sure what's involved if you are using RPMs that came from somewhere > else.) > > Updating to 7.2 would imply a dump and restore, which'd very likely make > the problem go away --- but then we'd not learn anything about what > caused the crash. If the underlying bug still exists in 7.2 then it > might someday bite you again. Are you more interested in getting up and > running ASAP, or in helping to debug the problem? > > regards, tom lane
It's amazing what a man page can teach you ... ;)
[postgres@timdb2 2034013]$ gdb /usr/local/pgsql/bin/postgres -c core
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
warning: core file may not match specified executable file.
Core was generated by `postgres: postgres bnmail [local] UPDATE '.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libreadline.so.4.1...done.
Loaded symbols for /usr/lib/libreadline.so.4.1
Reading symbols from /lib/libtermcap.so.2...done.
Loaded symbols for /lib/libtermcap.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0 ExecEvalVar (variable=0x8237338, econtext=0x8238238, isNull=0x826769c
"") at execQual.c:324
324 tuple_type = slot->ttc_tupleDescriptor;
(gdb) bt
#0 ExecEvalVar (variable=0x8237338, econtext=0x8238238, isNull=0x826769c
"") at execQual.c:324
#1 0x080ba4b1 in ExecEvalExpr (expression=0x8237338, econtext=0x8238238,
isNull=0x826769c "", isDone=0xbfffea78)
at execQual.c:1187
#2 0x080b9f03 in ExecEvalFuncArgs (fcache=0x8267638, argList=0x8237360,
econtext=0x8238238) at execQual.c:614
#3 0x080b9f7c in ExecMakeFunctionResult (fcache=0x8267638,
arguments=0x8237360, econtext=0x8238238, isNull=0x8267614 "",
isDone=0xbfffeb38) at execQual.c:667
#4 0x080ba16d in ExecEvalFunc (funcClause=0x82372f8, econtext=0x8238238,
isNull=0x8267614 "", isDone=0xbfffeb38)
at execQual.c:902
#5 0x080ba52d in ExecEvalExpr (expression=0x82372f8, econtext=0x8238238,
isNull=0x8267614 "", isDone=0xbfffeb38)
at execQual.c:1226
#6 0x080b9f03 in ExecEvalFuncArgs (fcache=0x82675b0, argList=0x8237378,
econtext=0x8238238) at execQual.c:614
#7 0x080b9f7c in ExecMakeFunctionResult (fcache=0x82675b0,
arguments=0x8237378, econtext=0x8238238, isNull=0xbfffebfb "",
isDone=0x0) at execQual.c:667
#8 0x080ba119 in ExecEvalOper (opClause=0x82372a8, econtext=0x8238238,
isNull=0xbfffebfb "", isDone=0x0) at execQual.c:860
#9 0x080ba521 in ExecEvalExpr (expression=0x82372a8, econtext=0x8238238,
isNull=0xbfffebfb "", isDone=0x0) at execQual.c:1222
#10 0x080ba632 in ExecQual (qual=0x82373d0, econtext=0x8238238,
resultForNull=0 '\000') at execQual.c:1374
#11 0x080bdf89 in IndexNext (node=0x8236a70) at nodeIndexscan.c:133
#12 0x080baadf in ExecScan (node=0x8236a70, accessMtd=0x80bde8c <IndexNext>)
at execScan.c:95
#13 0x080be160 in ExecIndexScan (node=0x8236a70) at nodeIndexscan.c:283
#14 0x080b9259 in ExecProcNode (node=0x8236a70, parent=0x8233990) at
execProcnode.c:282
#15 0x080bf9d4 in ExecNestLoop (node=0x8233990) at nodeNestloop.c:165
#16 0x080b9295 in ExecProcNode (node=0x8233990, parent=0x8233990) at
execProcnode.c:297
#17 0x080b8ee2 in EvalPlanQualNext (estate=0x8230de0) at execMain.c:1884
#18 0x080b8eba in EvalPlanQual (estate=0x8230de0, rti=1, tid=0xbfffee00) at
execMain.c:1870
#19 0x080b8813 in ExecReplace (slot=0x82313f4, tupleid=0xbfffee90,
estate=0x8230de0) at execMain.c:1465
#20 0x080b84ad in ExecutePlan (estate=0x8230de0, plan=0x82307a8,
operation=CMD_UPDATE, numberTuples=0,
direction=ForwardScanDirection, destfunc=0x82331a0) at execMain.c:1125
#21 0x080b7974 in ExecutorRun (queryDesc=0x8230dc8, estate=0x8230de0,
feature=3, count=0) at execMain.c:233
#22 0x080fc8b7 in ProcessQuery (parsetree=0x8203270, plan=0x82307a8,
dest=Remote) at pquery.c:295
#23 0x080fb3c6 in pg_exec_query_string (
query_string=0x8202a78 "UPDATE campaign_email \nSET
campaign_email_status = 2,\ncampaign_email_last_modified =
message_queue.last_modification \nFROM message_queue,
message_queue_purge_lock \nWHERE message_queue.message_id = mes"...,
dest=Remote,
parse_context=0x81dc6e8) at postgres.c:810
#24 0x080fc3ae in PostgresMain (argc=4, argv=0xbffff150, real_argc=4,
real_argv=0xbffffadc, username=0x81d3261 "postgres")
at postgres.c:1908
#25 0x080e7408 in DoBackend (port=0x81d2ff8) at postmaster.c:2114
#26 0x080e6ffb in BackendStartup (port=0x81d2ff8) at postmaster.c:1897
#27 0x080e6265 in ServerLoop () at postmaster.c:995
#28 0x080e5cb0 in PostmasterMain (argc=4, argv=0xbffffadc) at
postmaster.c:685
#29 0x080c7417 in main (argc=4, argv=0xbffffadc) at main.c:171
#30 0x400ed306 in __libc_start_main (main=0x80c72e4 <main>, argc=4,
ubp_av=0xbffffadc, init=0x8065364 <_init>,
fini=0x813e970 <_fini>, rtld_fini=0x4000d2cc <_dl_fini>,
stack_end=0xbffffacc) at ../sysdeps/generic/libc-start.c:129
(gdb)
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of David Esposito
> Sent: Tuesday, April 02, 2002 9:11 AM
> To: Tom Lane
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Core dump on PG 7.1.3
>
>
> Ok, I'll be the first to admit that my GDB debugging skills are
> not all that
> strong ... ;)
>
> Here's what I did to compile postgres 7.1.3
>
> ./configure --enable-debug
> gmake CPPFLAGS=-DALLOW_ABSOLUTE_DBPATHS all
> gmake install
>
> (i could see that it was compiling debug info into the
> executables since the
> "-g" flag was being used with the gcc commands)
>
> So then I fired up postgres and managed to get it to crash again ...
>
> I changed to the directory containing the core dump and ran gdb
>
> gdb -c core
>
> once GDB started, i typed "bt" and, again, i just got the hex
> addresses and
> no pretty function names or line numbers ...
>
> am I doing something wrong?
>
> Core was generated by `postgres: postgres bnmail [local] UPDATE
> '.
> Program terminated with signal 11, Segmentation fault.
> #0 0x080b992b in ?? ()
> (gdb) bt
> #0 0x080b992b in ?? ()
> #1 0x080ba4b1 in ?? ()
> #2 0x080b9f03 in ?? ()
> #3 0x080b9f7c in ?? ()
> #4 0x080ba16d in ?? ()
> #5 0x080ba52d in ?? ()
> #6 0x080b9f03 in ?? ()
> #7 0x080b9f7c in ?? ()
> #8 0x080ba119 in ?? ()
> #9 0x080ba521 in ?? ()
> #10 0x080ba632 in ?? ()
> #11 0x080bdf89 in ?? ()
> #12 0x080baadf in ?? ()
> #13 0x080be160 in ?? ()
> #14 0x080b9259 in ?? ()
> #15 0x080bf9d4 in ?? ()
> #16 0x080b9295 in ?? ()
> #17 0x080b8ee2 in ?? ()
> #18 0x080b8eba in ?? ()
> #19 0x080b8813 in ?? ()
> #20 0x080b84ad in ?? ()
> #21 0x080b7974 in ?? ()
> #22 0x080fc8b7 in ?? ()
> #23 0x080fb3c6 in ?? ()
> #24 0x080fc3ae in ?? ()
> #25 0x080e7408 in ?? ()
> #26 0x080e6ffb in ?? ()
> #27 0x080e6265 in ?? ()
> #28 0x080e5cb0 in ?? ()
> #29 0x080c7417 in ?? ()
> #30 0x400ed306 in ?? ()
>
> > -----Original Message-----
> > From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > Sent: Monday, April 01, 2002 4:17 PM
> > To: David Esposito
> > Cc: pgsql-general@postgresql.org
> > Subject: Re: [GENERAL] Core dump on PG 7.1.3
> >
> >
> > "David Esposito" <dvesposito@newnetco.com> writes:
> > > However, since this problem needs to be fixed, I see myself being
> > > able to do one of two things ...
> > > - Recompiling PG 7.1.3 using the debug symbols ..
> > > - Upgrading to PG 7.2
> > > Is there anything I'm missing here that I could try that is
> > non-invasive?
> >
> > Recompiling with debug symbols should be reasonably non-invasive,
> > assuming that you can otherwise duplicate the configuration options.
> > (If you're using locally built executables this shouldn't be hard;
> > not sure what's involved if you are using RPMs that came from somewhere
> > else.)
> >
> > Updating to 7.2 would imply a dump and restore, which'd very likely make
> > the problem go away --- but then we'd not learn anything about what
> > caused the crash. If the underlying bug still exists in 7.2 then it
> > might someday bite you again. Are you more interested in getting up and
> > running ASAP, or in helping to debug the problem?
> >
> > regards, tom lane
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
"David Esposito" <dvesposito@newnetco.com> writes:
> #0 ExecEvalVar (variable=0x8237338, econtext=0x8238238, isNull=0x826769c
> "") at execQual.c:324
> 324 tuple_type = slot->ttc_tupleDescriptor;
> (gdb) bt
> #0 ExecEvalVar (variable=0x8237338, econtext=0x8238238, isNull=0x826769c
> "") at execQual.c:324
Okay ... could we see the results of getting into gdb at this point
and doing
p slot
p *slot -- if above shows slot not 0, which I doubt
p *variable
p *econtext
I'd also like to see the results of EXPLAIN VERBOSE for the problem
query.
regards, tom lane
Ok, here are the results of the queries to GDB ... i could send the core
file along too but i don't know if it would do you any good (does the core
dump only work on the machine on which it was generated?)
#0 ExecEvalVar (variable=0x8237338, econtext=0x8238238, isNull=0x826769c
"") at execQual.c:324
324 tuple_type = slot->ttc_tupleDescriptor;
(gdb) p slot
$1 = (TupleTableSlot *) 0x0
(gdb) p *slot
Cannot access memory at address 0x0
(gdb) p *variable
$2 = {type = T_Var, varno = 65001, varattno = 3, vartype = 23, vartypmod
= -1, varlevelsup = 0, varnoold = 2, varoattno = 11}
(gdb) p *econtext
$3 = {type = T_ExprContext, ecxt_scantuple = 0x82374c0, ecxt_innertuple =
0x0, ecxt_outertuple = 0x0,
ecxt_per_query_memory = 0x81dc7f8, ecxt_per_tuple_memory = 0x822f030,
ecxt_param_exec_vals = 0x0, ecxt_param_list_info = 0x0,
ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
(gdb)
As far as the EXPLAIN VERBOSE goes, i can't run it against the database that
crashed until tomorrow morning ... but I did run it against a PG 7.1.3
installation with the exact same schema and data set ... I figure this is
sufficient since I can't imagine that the query plan changes based on
anything machine-specific ... However, since the database doesn't actually
crash when executing it on this machine, i don't know if any of that
information would be included in the EXPLAIN data ...
Am I right in concluding that when a query is run with "EXPLAIN", it doesn't
actually modify the database? (it went way too fast ... plus i never saw my
normal "UPDATE 0 20084" returned like i would if it actually performed the
update .. )
bnmail=# EXPLAIN VERBOSE UPDATE campaign_email
bnmail-# SET campaign_email_status = 2,
bnmail-# campaign_email_last_modified = message_queue.last_modification
bnmail-# FROM message_queue, message_queue_purge_lock
bnmail-# WHERE message_queue.message_id =
message_queue_purge_lock.message_id
bnmail-# AND message_queue.campaign_email_id =
campaign_email.campaign_email_id;
NOTICE: QUERY DUMP:
{ MERGEJOIN :startup_cost 0.00 :total_cost 2985543.45 :rows 13107000 :width
118 :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 1700
:restypmod 720900 :resname campaign_email_id :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 65001 :varattno 1
:vartype 1700 :vartypmod 720900 :varlevelsup 0 :varnoold 1 :varoattno 1}}
{ TARGETENTRY :resdom { RESDOM :resno 2 :restype 1700 :restypmod 720900
:resname campaign_id :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk
false } :expr { VAR :varno 65001 :varattno 2 :vartype 1700 :vartypmod 720900
:varlevelsup 0 :varnoold 1 :varoattno 2}} { TARGETENTRY :resdom { RESDOM
:resno 3 :restype 1700 :restypmod 720900 :resname patron_id :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 65001
:varattno 3 :vartype 1700 :vartypmod 720900 :varlevelsup 0 :varnoold 1
:varoattno 3}} { TARGETENTRY :resdom { RESDOM :resno 4 :restype 1700
:restypmod 131076 :resname campaign_email_status :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { CONST :consttype 1700
:constlen -1 :constbyval false :constisnull false :constvalue 11 [ 11 0 0 0
0 0 0 0 0 0 32 ] }} { TARGETENTRY :resdom { RESDOM :resno 5 :restype 1184
:restypmod -1 :resname campaign_email_last_modified :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 65001 :varattno 11
:vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 7}} {
TARGETENTRY :resdom { RESDOM :resno 6 :restype 1043 :restypmod 504 :resname
campaign_email_detail :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk
false } :expr { VAR :varno 65001 :varattno 4 :vartype 1043 :vartypmod 504
:varlevelsup 0 :varnoold 1 :varoattno 6}} { TARGETENTRY :resdom { RESDOM
:resno 7 :restype 1184 :restypmod -1 :resname impression_date :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 65001
:varattno 5 :vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 1
:varoattno 7}} { TARGETENTRY :resdom { RESDOM :resno 8 :restype 1184
:restypmod -1 :resname last_click_through_date :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 65001 :varattno 6
:vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 8}} {
TARGETENTRY :resdom { RESDOM :resno 9 :restype 1700 :restypmod 720900
:resname num_click_throughs :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 65001 :varattno 7 :vartype 1700
:vartypmod 720900 :varlevelsup 0 :varnoold 1 :varoattno 9}} { TARGETENTRY
:resdom { RESDOM :resno 10 :restype 1184 :restypmod -1 :resname bounce_date
:reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno
65001 :varattno 8 :vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 1
:varoattno 10}} { TARGETENTRY :resdom { RESDOM :resno 11 :restype 1184
:restypmod -1 :resname opt_out_date :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 65001 :varattno 9 :vartype 1184
:vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 11}} { TARGETENTRY
:resdom { RESDOM :resno 12 :restype 27 :restypmod -1 :resname ctid :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk true } :expr { VAR :varno 65001
:varattno 10 :vartype 27 :vartypmod -1 :varlevelsup 0 :varnoold 1
:varoattno -1}}) :qpqual <> :lefttree { NESTLOOP :startup_cost 0.00
:total_cost 2969088.19 :rows 1310700 :width 114 :qptargetlist ({ TARGETENTRY
:resdom { RESDOM :resno 1 :restype 1700 :restypmod 720900 :resname <>
:reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno
65000 :varattno 1 :vartype 1700 :vartypmod 720900 :varlevelsup 0 :varnoold
1 :varoattno 1}} { TARGETENTRY :resdom { RESDOM :resno 2 :restype 1700
:restypmod 720900 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 65000 :varattno 2 :vartype 1700
:vartypmod 720900 :varlevelsup 0 :varnoold 1 :varoattno 2}} { TARGETENTRY
:resdom { RESDOM :resno 3 :restype 1700 :restypmod 720900 :resname <>
:reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno
65000 :varattno 3 :vartype 1700 :vartypmod 720900 :varlevelsup 0 :varnoold
1 :varoattno 3}} { TARGETENTRY :resdom { RESDOM :resno 4 :restype 1043
:restypmod 504 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk
false } :expr { VAR :varno 65000 :varattno 4 :vartype 1043 :vartypmod 504
:varlevelsup 0 :varnoold 1 :varoattno 6}} { TARGETENTRY :resdom { RESDOM
:resno 5 :restype 1184 :restypmod -1 :resname <> :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 65000 :varattno 5
:vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 7}} {
TARGETENTRY :resdom { RESDOM :resno 6 :restype 1184 :restypmod -1 :resname
<> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR
:varno 65000 :varattno 6 :vartype 1184 :vartypmod -1 :varlevelsup 0
:varnoold 1 :varoattno 8}} { TARGETENTRY :resdom { RESDOM :resno 7 :restype
1700 :restypmod 720900 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 65000 :varattno 7 :vartype 1700
:vartypmod 720900 :varlevelsup 0 :varnoold 1 :varoattno 9}} { TARGETENTRY
:resdom { RESDOM :resno 8 :restype 1184 :restypmod -1 :resname <> :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 65000
:varattno 8 :vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 1
:varoattno 10}} { TARGETENTRY :resdom { RESDOM :resno 9 :restype 1184
:restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk
false } :expr { VAR :varno 65000 :varattno 9 :vartype 1184 :vartypmod -1
:varlevelsup 0 :varnoold 1 :varoattno 11}} { TARGETENTRY :resdom { RESDOM
:resno 10 :restype 27 :restypmod -1 :resname <> :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 65000 :varattno 10
:vartype 27 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno -1}} {
TARGETENTRY :resdom { RESDOM :resno 11 :restype 1184 :restypmod -1 :resname
<> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR
:varno 65001 :varattno 1 :vartype 1184 :vartypmod -1 :varlevelsup 0
:varnoold 2 :varoattno 7}} { TARGETENTRY :resdom { RESDOM :resno 12 :restype
23 :restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 65001 :varattno 2 :vartype 23
:vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 1}} { TARGETENTRY
:resdom { RESDOM :resno 13 :restype 23 :restypmod -1 :resname <> :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 65001
:varattno 3 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno
11}}) :qpqual <> :lefttree { INDEXSCAN :startup_cost 0.00 :total_cost 59.00
:rows 1000 :width 16 :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1
:restype 1184 :restypmod -1 :resname <> :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 2 :varattno 7
:vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 7}} {
TARGETENTRY :resdom { RESDOM :resno 2 :restype 23 :restypmod -1 :resname <>
:reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno
2 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2
:varoattno 1}} { TARGETENTRY :resdom { RESDOM :resno 3 :restype 23
:restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk
false } :expr { VAR :varno 2 :varattno 11 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 2 :varoattno 11}}) :qpqual <> :lefttree <>
:righttree <> :extprm () :locprm () :initplan <> :nprm 0 :scanrelid 2
:indxid ( 960076) :indxqual (<>) :indxqualorig (<>) :indxorderdir 1 }
:righttree { INDEXSCAN :startup_cost 0.00 :total_cost 2949.37 :rows 1311
:width 98 :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype
1700 :restypmod 720900 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 1 :varattno 1 :vartype 1700 :vartypmod
720900 :varlevelsup 0 :varnoold 1 :varoattno 1}} { TARGETENTRY :resdom {
RESDOM :resno 2 :restype 1700 :restypmod 720900 :resname <> :reskey 0
:reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1
:varattno 2 :vartype 1700 :vartypmod 720900 :varlevelsup 0 :varnoold 1
:varoattno 2}} { TARGETENTRY :resdom { RESDOM :resno 3 :restype 1700
:restypmod 720900 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0
:resjunk false } :expr { VAR :varno 1 :varattno 3 :vartype 1700 :vartypmod
720900 :varlevelsup 0 :varnoold 1 :varoattno 3}} { TARGETENTRY :resdom {
RESDOM :resno 4 :restype 1043 :restypmod 504 :resname <> :reskey 0 :reskeyop
0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 6
:vartype 1043 :vartypmod 504 :varlevelsup 0 :varnoold 1 :varoattno 6}} {
TARGETENTRY :resdom { RESDOM :resno 5 :restype 1184 :restypmod -1 :resname
<> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR
:varno 1 :varattno 7 :vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold 1
:varoattno 7}} { TARGETENTRY :resdom { RESDOM :resno 6 :restype 1184
:restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk
false } :expr { VAR :varno 1 :varattno 8 :vartype 1184 :vartypmod -1
:varlevelsup 0 :varnoold 1 :varoattno 8}} { TARGETENTRY :resdom { RESDOM
:resno 7 :restype 1700 :restypmod 720900 :resname <> :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 9
:vartype 1700 :vartypmod 720900 :varlevelsup 0 :varnoold 1 :varoattno 9}}
{ TARGETENTRY :resdom { RESDOM :resno 8 :restype 1184 :restypmod -1 :resname
<> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR
:varno 1 :varattno 10 :vartype 1184 :vartypmod -1 :varlevelsup 0 :varnoold
1 :varoattno 10}} { TARGETENTRY :resdom { RESDOM :resno 9 :restype 1184
:restypmod -1 :resname <> :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk
false } :expr { VAR :varno 1 :varattno 11 :vartype 1184 :vartypmod -1
:varlevelsup 0 :varnoold 1 :varoattno 11}} { TARGETENTRY :resdom { RESDOM
:resno 10 :restype 27 :restypmod -1 :resname <> :reskey 0 :reskeyop 0
:ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno -1
:vartype 27 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno -1}})
:qpqual <> :lefttree <> :righttree <> :extprm () :locprm () :initplan <>
:nprm 0 :scanrelid 1 :indxid ( 959439) :indxqual (({ EXPR :typeOid 16
:opType op :oper { OPER :opno 1752 :opid 1718 :opresulttype 16 } :args ({
VAR :varno 1 :varattno 1 :vartype 1700 :vartypmod 720900 :varlevelsup 0
:varnoold 1 :varoattno 1} { EXPR :typeOid 1700 :opType func :oper { FUNC
:funcid 1740 :functype 1700 } :args ({ VAR :varno 65001 :varattno 3 :vartype
23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 11})})}))
:indxqualorig (({ EXPR :typeOid 16 :opType op :oper { OPER :opno 1752 :opid
1718 :opresulttype 16 } :args ({ EXPR :typeOid 1700 :opType func :oper {
FUNC :funcid 1740 :functype 1700 } :args ({ VAR :varno 65001 :varattno 3
:vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2 :varoattno 11})} { VAR
:varno 1 :varattno 1 :vartype 1700 :vartypmod 720900 :varlevelsup 0
:varnoold 1 :varoattno 1})})) :indxorderdir 0 } :extprm () :locprm ()
:initplan <> :nprm 0 :jointype 0 :joinqual <>} :righttree { INDEXSCAN
:startup_cost 0.00 :total_cost 59.00 :rows 1000 :width 4 :qptargetlist ({
TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname <>
:reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno
3 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 3
:varoattno 1}}) :qpqual <> :lefttree <> :righttree <> :extprm () :locprm ()
:initplan <> :nprm 0 :scanrelid 3 :indxid ( 960104) :indxqual (<>)
:indxqualorig (<>) :indxorderdir 1 } :extprm () :locprm () :initplan <>
:nprm 0 :jointype 0 :joinqual <> :mergeclauses ({ EXPR :typeOid 16 :opType
op :oper { OPER :opno 96 :opid 65 :opresulttype 16 } :args ({ VAR :varno
65001 :varattno 12 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 2
:varoattno 1} { VAR :varno 65000 :varattno 1 :vartype 23 :vartypmod -1
:varlevelsup 0 :varnoold 3 :varoattno 1})})}
NOTICE: QUERY PLAN:
Merge Join (cost=0.00..2985543.45 rows=13107000 width=118)
-> Nested Loop (cost=0.00..2969088.19 rows=1310700 width=114)
-> Index Scan using message_queue_pkey on message_queue
(cost=0.00..59.00 rows=1000 width=16)
-> Index Scan using campaign_email_pkey on campaign_email
(cost=0.00..2949.37 rows=1311 width=98)
-> Index Scan using message_queue_purge_lock_pkey on
message_queue_purge_lock (cost=0.00..59.00 rows=1000 width=4)
EXPLAIN
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Tuesday, April 02, 2002 10:20 AM
> To: David Esposito
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Core dump on PG 7.1.3
>
>
> "David Esposito" <dvesposito@newnetco.com> writes:
> > #0 ExecEvalVar (variable=0x8237338, econtext=0x8238238,
> isNull=0x826769c
> > "") at execQual.c:324
> > 324 tuple_type = slot->ttc_tupleDescriptor;
> > (gdb) bt
> > #0 ExecEvalVar (variable=0x8237338, econtext=0x8238238,
> isNull=0x826769c
> > "") at execQual.c:324
>
> Okay ... could we see the results of getting into gdb at this point
> and doing
>
> p slot
> p *slot -- if above shows slot not 0, which I doubt
> p *variable
> p *econtext
>
> I'd also like to see the results of EXPLAIN VERBOSE for the problem
> query.
>
> regards, tom lane
"David Esposito" <dvesposito@newnetco.com> writes:
> (gdb) p *variable
> $2 = {type = T_Var, varno = 65001, varattno = 3, vartype = 23, vartypmod
> = -1, varlevelsup = 0, varnoold = 2, varoattno = 11}
> (gdb) p *econtext
> $3 = {type = T_ExprContext, ecxt_scantuple = 0x82374c0, ecxt_innertuple =
> 0x0, ecxt_outertuple = 0x0,
> ecxt_per_query_memory = 0x81dc7f8, ecxt_per_tuple_memory = 0x822f030,
> ecxt_param_exec_vals = 0x0, ecxt_param_list_info = 0x0,
> ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
Hmm ... trying to access an "OUTER" variable in a context that has no
outer tuple ... and it's called from EvalPlanQual ... yes, this is a
known bug. I believe it's the same case addressed by this recent fix:
2002-02-11 15:10 tgl
* src/backend/executor/: nodeIndexscan.c, nodeTidscan.c: Repair
problems with EvalPlanQual where target table is scanned as inner
indexscan (ie, one with runtime keys). ExecIndexReScan must
compute or recompute runtime keys even if we are rescanning in the
EPQ case. TidScan seems to have comparable problems. Per bug
noted by Barry Lind 11-Feb-02.
The EvalPlanQual path is only taken in concurrent-update scenarios;
probably the reason you could not reproduce the problem on your devel
box is that you executed the query in isolation, not in competition
with other updates on the same rows.
This fix is in 7.2.1 --- it is *not* in 7.2. If you can afford to
update your production box to 7.2.1 now, that's the approach I'd
recommend.
regards, tom lane
Thanks ... I'll do that in the wee hours of tomorrow morning and let you
know how it turns out ...
Thanks for the quick responses ...
-Dave
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Tom Lane
> Sent: Tuesday, April 02, 2002 12:05 PM
> To: David Esposito
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Core dump on PG 7.1.3
>
>
> "David Esposito" <dvesposito@newnetco.com> writes:
> > (gdb) p *variable
> > $2 = {type = T_Var, varno = 65001, varattno = 3, vartype = 23, vartypmod
> > = -1, varlevelsup = 0, varnoold = 2, varoattno = 11}
> > (gdb) p *econtext
> > $3 = {type = T_ExprContext, ecxt_scantuple = 0x82374c0,
> ecxt_innertuple =
> > 0x0, ecxt_outertuple = 0x0,
> > ecxt_per_query_memory = 0x81dc7f8, ecxt_per_tuple_memory = 0x822f030,
> > ecxt_param_exec_vals = 0x0, ecxt_param_list_info = 0x0,
> > ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
>
> Hmm ... trying to access an "OUTER" variable in a context that has no
> outer tuple ... and it's called from EvalPlanQual ... yes, this is a
> known bug. I believe it's the same case addressed by this recent fix:
>
> 2002-02-11 15:10 tgl
>
> * src/backend/executor/: nodeIndexscan.c, nodeTidscan.c: Repair
> problems with EvalPlanQual where target table is scanned as inner
> indexscan (ie, one with runtime keys). ExecIndexReScan must
> compute or recompute runtime keys even if we are rescanning in the
> EPQ case. TidScan seems to have comparable problems. Per bug
> noted by Barry Lind 11-Feb-02.
>
> The EvalPlanQual path is only taken in concurrent-update scenarios;
> probably the reason you could not reproduce the problem on your devel
> box is that you executed the query in isolation, not in competition
> with other updates on the same rows.
>
> This fix is in 7.2.1 --- it is *not* in 7.2. If you can afford to
> update your production box to 7.2.1 now, that's the approach I'd
> recommend.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
The upgrade went smoothly and I am unable to replicate the core dump on the
new version of Postgres ...
Thanks for all of your help ... Postgres is a really dynamite db ..
-dave
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of David Esposito
> Sent: Tuesday, April 02, 2002 1:03 PM
> To: Tom Lane
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Core dump on PG 7.1.3
>
>
> Thanks ... I'll do that in the wee hours of tomorrow morning and let you
> know how it turns out ...
>
> Thanks for the quick responses ...
>
> -Dave
>
> > -----Original Message-----
> > From: pgsql-general-owner@postgresql.org
> > [mailto:pgsql-general-owner@postgresql.org]On Behalf Of Tom Lane
> > Sent: Tuesday, April 02, 2002 12:05 PM
> > To: David Esposito
> > Cc: pgsql-general@postgresql.org
> > Subject: Re: [GENERAL] Core dump on PG 7.1.3
> >
> >
> > "David Esposito" <dvesposito@newnetco.com> writes:
> > > (gdb) p *variable
> > > $2 = {type = T_Var, varno = 65001, varattno = 3, vartype =
> 23, vartypmod
> > > = -1, varlevelsup = 0, varnoold = 2, varoattno = 11}
> > > (gdb) p *econtext
> > > $3 = {type = T_ExprContext, ecxt_scantuple = 0x82374c0,
> > ecxt_innertuple =
> > > 0x0, ecxt_outertuple = 0x0,
> > > ecxt_per_query_memory = 0x81dc7f8, ecxt_per_tuple_memory =
> 0x822f030,
> > > ecxt_param_exec_vals = 0x0, ecxt_param_list_info = 0x0,
> > > ecxt_aggvalues = 0x0, ecxt_aggnulls = 0x0}
> >
> > Hmm ... trying to access an "OUTER" variable in a context that has no
> > outer tuple ... and it's called from EvalPlanQual ... yes, this is a
> > known bug. I believe it's the same case addressed by this recent fix:
> >
> > 2002-02-11 15:10 tgl
> >
> > * src/backend/executor/: nodeIndexscan.c, nodeTidscan.c: Repair
> > problems with EvalPlanQual where target table is scanned as inner
> > indexscan (ie, one with runtime keys). ExecIndexReScan must
> > compute or recompute runtime keys even if we are rescanning in the
> > EPQ case. TidScan seems to have comparable problems. Per bug
> > noted by Barry Lind 11-Feb-02.
> >
> > The EvalPlanQual path is only taken in concurrent-update scenarios;
> > probably the reason you could not reproduce the problem on your devel
> > box is that you executed the query in isolation, not in competition
> > with other updates on the same rows.
> >
> > This fix is in 7.2.1 --- it is *not* in 7.2. If you can afford to
> > update your production box to 7.2.1 now, that's the approach I'd
> > recommend.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)