Re: -DCLOBBER_CACHE_ALWAYS shows COPY FREEZE regression problem

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