Comment from cursor.next/prev:

Column store appends are inherently non-transactional.
Even a non-visible update by a concurrent or aborted transaction
changes the effective end of the data. The effect is subtle because
of the blurring between deleted and empty values, but ideally we
would skip all uncommitted changes at the end of the data.

The problem is that we don't know at this point whether there may be
multiple uncommitted changes at the end of the data, and it would be
expensive to check every time we hit an aborted update. If an
insert is aborted, we simply return zero (empty), regardless of
whether we are at the end of the data.

Michael:

> The same issue does apply to prev, in the sense that we may return some zero records at the beginning of a reverse scan that would not be seen if an aborted append had never happened. It's probably slightly easier to fix prev by skipping invisible records at the beginning of a reverse scan, though we don't do that now for deleted records. I've added a comment at the same place in the prev code.

> The only documentation I am aware of for the existing behavior of fixed-length column stores in the docs for cursor->remove: "Removing a record in a fixed-length column-store is identical to setting the record's value to 0". That doesn't say anything about where scans begin or end. If we say that aborting an append is equivalent to removing the appended record, there is no real problem with the existing behavior.

> To be clear, the underlying issue here is not caused by transactions, it is that we are already somewhat vague about where scans will begin and end in fixed-length column stores. If we changed next and prev so that applications never see zeroed records at the beginning or end of a full scan, that would avoid visible side effects from aborted transactions.

Keith:

> I don't see how we'd change next/prev so applications never see zero'd records at the beginning or end of a full scan without instantiating them somehow associated with the transaction, for example, applications can insert zero records explicitly.

> I'm inclined to solve this with documentation unless you think a typical application might actually care about this.