Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

On Tue, Jan 15, 2013 at 10:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
>> On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I think this is unacceptable on its face. It essentially supposes that
>>> relcache entries are reliable storage. They are not.
>
>> Would it be acceptable if we inverted the meaning of the struct member, and
>> named it to rd_rows_not_inserted. When registering an ON COMMIT action, we
>> can set this member to true, and set it to false when inserting a row into
>> it. The pre-commit hook will truncate any relation that doesn't have this
>> member set to true.
>
>> With that in place, even if the relcache entry is discarded midway through
>> the transaction, the cleanup code will truncate the relation, preserving
>> the correct behaviour.
>
> Well, that would fail in the safe direction, but it just seems
> excessively ugly and hard-to-understand. Given the field demand for
> this optimization (which so far as I've noticed is nil), I'm not
> convinced we need to do this.

Yep, this is also why I prefer the approach of setting a global
variable. The demand for this is not *precisely* zero or it wouldn't
be on the TODO list, but the global seems like it would head off the
worst of the damage without requiring any fiddling with the relcache.

On the third hand, the fact that a table is OCDR is recorded in
backend-local storage somewhere, and that storage (unlike the
relcache) had better be reliable. So maybe there's some way to
finesse it that way.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company