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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
Cc: PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT
Date: 2013-01-15 15:57:54
Message-ID: 26360.1358265474@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-01-15 16:04:25 Re: Curious buildfarm failures
Previous Message Peter Eisentraut 2013-01-15 15:55:41 Re: pg_ctl idempotent option