Re: COPY FREEZE has no warning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COPY FREEZE has no warning
Date
Msg-id 24089.1359153058@sss.pgh.pa.us
Whole thread Raw
In response to Re: COPY FREEZE has no warning  (Bruce Momjian <bruce@momjian.us>)
Responses Re: COPY FREEZE has no warning
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> OK, updated patch attached that throws an error with a more specific
> message.


>            *
>            * As noted above rd_newRelfilenodeSubid is not set in all cases
>            * where we can apply the optimization, so in those rare cases
> !          * where we cannot honor the request.
>            */

This sentence not complete.  I kind of think the entire para visible
above could be removed, anyway.

> !                 ereport(ERROR, (errmsg("cannot perform FREEZE operation due to invalid table or transaction
state")));

I don't find this terribly specific.  It would at least be useful to
have two messages distinguishing whether the cause was invalid table
state (rd_createSubid and rd_newRelfilenodeSubid not set) or invalid
transaction state (the snapshot and portal tests).  The former might
usefully be phrased as "because the table was not created or truncated
in the current transaction" and the latter as "because other actions are
in progress within the current transaction".

I'd also suggest "cannot perform COPY FREEZE because <whatever>" rather
than using the unnecessarily vague "operation".

Also, this is missing an errcode, which means it will report itself as
an internal error, which it ain't.  It's also randomly unlike the
standard layout for ereport calls.
ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE would do for the table case,
not sure about the other.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Potential autovacuum optimization: new tables
Next
From: Robert Haas
Date:
Subject: Re: SYSV shared memory vs mmap performance