From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: COPY FREEZE has no warning |
Date: | 2013-01-25 22:30:58 |
Message-ID: | 24089.1359153058@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-01-25 22:55:19 | Re: SYSV shared memory vs mmap performance |
Previous Message | Bruce Momjian | 2013-01-25 22:10:18 | Re: Potential autovacuum optimization: new tables |