Andrew Dunstan <and...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
