Andrew Dunstan <andrew@dunslane.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
rarecases rd_createSubid or * rd_newRelfilenodeSubid can be cleared before the end of the transaction. * However
thisis 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