Massimo Dal Zotto <dz@cs.unitn.it> writes:
> dz=> select count(1) from my_table;
> pqReadData() -- backend closed the channel unexpectedly.
Poking into this failure revealed a potentially serious problem in
execQual.c, so I decided it would be wise to fix it now rather than
wait till after 6.5. In the situation where ExecTargetList() is asked
to generate a null tuple --- which arises in the case above, and
evidently in other cases judging from the comments there and the
multiple bogus ways that people have tried to fix it before ---
it was handing back a palloc'd but uninitialized chunk of memory.
This would result in unpredictable behavior if anyone actually tried
to do anything with the tuple. In the case above, nodeAgg.c tried to
copy the tuple, leading to coredumps some of the time. I fixed
ExecTargetList to generate a valid tuple containing zero attributes,
which should work reliably.
I had managed to break the planner's handling of this case too, so I
figured I would fix that as long as I was annoying Marc anyway ;-).
The behavior is now back to that of 6.4.2: you get "1" when the query is
not grouped and row counts when it is. I still think that that's wrong,
but I will not risk trying to change it just before release.
regards, tom lane
