On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 15.01.2013 21:03, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On the third hand, the fact that a table is OCDR is recorded in
backend-local storage somewhere, and that storage (unlike the
Gurjeet Singh singh.gurj...@gmail.com writes:
On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane t...@sss.pgh.pa.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
On Tue, Jan 15, 2013 at 10:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com writes:
On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think this is unacceptable on its face. It essentially supposes that
relcache entries are reliable storage.
Robert Haas robertmh...@gmail.com 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
Gurjeet Singh singh.gurj...@gmail.com 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
On Mon, Jan 14, 2013 at 10:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh singh.gurj...@gmail.com 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.
