Michael Paquier <michael.paqu...@gmail.com> writes:
> On Fri, Sep 4, 2015 at 10:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Also, I am very strongly tempted to convert the original problem-causing
>> Assert in relcache.c into a regular runtime test-and-elog. If we're wrong
>> about having sealed off this hole completely, I'd much rather see the
>> result be an elog than silent corruption of the relcache.
> +1. For a HEAD-only change I suppose.
No, the point is to have less dangerous behavior *in the field* if the
situation occurs. I have every intention of back-patching this bit as
well.
Although after some experimentation with a build lacking the Portal-level
fixes, an elog(ERROR) in RelationClearRelation isn't much fun either,
because the problem case causes errors during error cleanup, soon leading
to "PANIC: ERRORDATA_STACK_SIZE exceeded".
After review of all the callers of RelationClearRelation, it seems like
most of them already have sufficient guards to prevent triggering of the
Assert. The ones that lack such tests are AtEOXact_cleanup and
AtEOSubXact_cleanup. So what I'm now thinking is that those should do
something along the lines of
if (isCommit)
relation->rd_createSubid = parentSubid;
else if (RelationHasReferenceCountZero(relation))
{
RelationClearRelation(relation, false);
return;
}
else
{
elog(WARNING, "rel so-and-so is still referenced");
relation->rd_createSubid = parentSubid;
}
so as to mitigate the damage if there's a dangling reference.
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
