On Sat, Feb 2, 2013 at 12:09:05PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Well, so you are saying that there really isn't any use-visible logic
> > for those messages to be different,
>
> No, and in fact the whole block of code is badly written because it
> conflates two unrelated tests. I guess somebody was trying to save
> a couple of nanoseconds by not calling GetCurrentSubTransactionId
> if a previous test had failed, but really why should we care about
> that number of cycles in COPY preliminaries? The code ought to be
> more like this:
>
> /* comment about skipping FSM or WAL here */
> if (cstate->rel->rd_createSubid != InvalidSubTransactionId ||
> cstate->rel->rd_newRelfilenodeSubid != InvalidSubTransactionId)
> {
> hi_options |= HEAP_INSERT_SKIP_FSM;
> if (!XLogIsNeeded())
> hi_options |= HEAP_INSERT_SKIP_WAL;
> }
> /* comment about when we can perform FREEZE here */
> if (cstate->freeze)
> {
> if (!ThereAreNoPriorRegisteredSnapshots() || !ThereAreNoReadyPortals())
> ereport(ERROR,
> (ERRCODE_INVALID_TRANSACTION_STATE,
> errmsg("cannot perform FREEZE because of prior transaction activity")));
>
> if (cstate->rel->rd_createSubid != GetCurrentSubTransactionId() &&
> cstate->rel->rd_newRelfilenodeSubid != GetCurrentSubTransactionId())
> ereport(ERROR,
> (ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE,
> errmsg("cannot perform FREEZE because the table was not created or truncated in the current
subtransaction")));
> hi_options |= HEAP_INSERT_FROZEN;
> }
Yes, I found the blocking odd too --- the test for
InvalidSubTransactionId is used by hi_options, and for freeze checking.
I assumed "!= InvalidSubTransactionId" and "!=
GetCurrentSubTransactionId()" had different meanings for freeze
checking.
I compounded the problem because originally there was no FREEZE failure
so no action was taken if "!= InvalidSubTransactionId".
Applied patch attached.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
