Re: -DCLOBBER_CACHE_ALWAYS shows COPY FREEZE regression problem

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On a new buildfarm member friarbird
> <http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=friarbird&dt=2012-12-06%2020%3A55%3A31>,
> configured with _DCLOBBER_CACHE_ALWAYS:

> BEGIN;
> TRUNCATE vistest;
> COPY vistest FROM stdin CSV FREEZE;
> + NOTICE: FREEZE option specified but pre-conditions not met

The notice is coming out because the relcache is dropping the value of
rd_newRelfilenodeSubid as a result of cache flushes. The COPY FREEZE
code is aware of this risk, commenting

* As mentioned in comments in utils/rel.h, the in-same-transaction test
* is not completely reliable, since in rare cases rd_createSubid or
* rd_newRelfilenodeSubid can be cleared before the end of the transaction.
* However this is OK since at worst we will fail to make the optimization.

but I'd say this seriously throws into question whether it should be
emitting a notice. That seems to tie into the discussion a little bit
ago about whether the FREEZE option is a command or a hint. Throwing a
notice seems like a pretty schizophrenic choice: it's not an error but
you're in the user's face about it anyway. In any case, if the option
is unreliable (and with this implementation it certainly is), we can
*not* treat its failure as an error, so it's not a command.

TBH I think that COPY FREEZE should not have been committed yet;
it doesn't seem to be fully baked.

regards, tom lane