On Sun, Mar 20, 2016 at 11:01 PM, Peter Geoghegan <p...@heroku.com> wrote: > Allowing 0 tuple runs in rare cases seems like the simplest solution. > After all, mergeprereadone() is expressly prepared for 0 tuple runs. > It says "ensure that we have at least one tuple, if any are to be > had". There is no reason to assume that it says this only because it > imagines that no tuples might be found *only after* the first preread > for the merge (by which I mean I don't think that only applies when a > final on-the-fly merge reloads tuples from one particular tape > following running out of tuples of the tape/run in memory).
I just realized that there is what amounts to an over-zealous assertion in dumpbatch(): > + * When this edge case hasn't occurred, the first memtuple should not > + * be found to be heapified (nor should any other memtuple). > + */ > + Assert(state->memtupcount == 0 || > + state->memtuples[0].tupindex == HEAP_RUN_NEXT); The problem is that state->memtuples[0].tupindex won't have been *reliably* initialized here. We could make sure that it is for the benefit of this assertion, but I think it would be better to just remove the assertion, which isn't testing very much over and above the similar assertions that appears in the only dumpbatch() caller, dumptuples(). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
