On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
wrote:
> On 15.01.2013 21:03, Tom Lane wrote:
>> Robert Haas writes:
>>>
>>> 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.
Robert Haas writes:
> 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.
Hm, keep a flag in that storage you mean? Yeah, that coul
On Tue, Jan 15, 2013 at 10:57 AM, Tom Lane wrote:
> Gurjeet Singh writes:
>> On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane 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 i
Gurjeet Singh writes:
> On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane 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 t
On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane wrote:
> Gurjeet Singh writes:
> > Please find attached two patches, implementing two different approaches
> to
> > fix the issue of COMMIT truncating empty TEMP tables that have the ON
> > COMMIT DELETE ROWS attribute.
>
> > v2.patch: This approach int
Gurjeet Singh writes:
> Please find attached two patches, implementing two different approaches to
> fix the issue of COMMIT truncating empty TEMP tables that have the ON
> COMMIT DELETE ROWS attribute.
> v2.patch: This approach introduces a boolean 'rd_rows_inserted' in
> RelationData struct, an
