"A.V.Shutko" <AVShutko@mail.khstu.ru> writes:
> Your server have a bug that sometimes cause coredumps.....
> Tom Lane> What version of postgres?
> # ./postgres -V
> postgres (PostgreSQL) 7.1
Okay, I think I understand the scenario here. Are you using table
inheritance? I can produce a crash in the same place using UPDATE
of an inheritance group:
regression=# create table par(f1 int);
CREATE
regression=# create table child(f2 int) inherits (par);
CREATE
regression=# insert into par values(1);
INSERT 1453231 1
regression=# begin;
BEGIN
regression=# update par set f1 = f1 + 1;
UPDATE 1
<< now start a second backend, and in it also do >>
regression=# update par set f1 = f1 + 1;
<< second backend blocks waiting for first one to commit;
go back to first backend and do >>
regression=# end;
COMMIT
<< now second backend crashes in exec_append_initialize_next >>
The direct cause of the problem is that EvalPlanQual isn't completely
initializing the estate that it sets up for re-evaluating the plan.
In particular it's not filling in es_result_relations and
es_num_result_relations, which need to be set up if the top plan node
is an Append. (That's probably my fault.) But there are a bunch of
other fields that it's failing to copy, too.
Vadim, I'm thinking that EvalPlanQual would be better if it memcpy'd
the parent estate, and then changed the fields that should be different,
rather than zeroing the child state and then copying the fields that
need to be copied. Seems like the default behavior should be to copy
fields rather than leave them zero. What do you think? Which fields
should really be zero in the child?
regards, tom lane
