On Wed, Apr 14, 2021 at 6:45 AM Himanshu Upadhyaya
wrote:
> The purpose of this FIX is to mainly focus on getting consistent behavior
> with PREPARE TRANSACTION. With the case that I had mentioned
> previously, my expectation was either both PREPARE TRANSACTION should fail
> or both should succeed
Hi Robert,
Thanks for sharing your thoughts.
The purpose of this FIX is to mainly focus on getting consistent behavior
with PREPARE TRANSACTION. With the case that I had mentioned
previously, my expectation was either both PREPARE TRANSACTION should fail
or both should succeed but here second same
On Wed, Apr 7, 2021 at 12:19 PM Himanshu Upadhyaya
wrote:
> Please find attached the V2 patch.
Hi,
This patch is essentially taking the position that calling
load_typcache_tupdesc before using that tupdesc for anything is
required for correctness. I'm not sure whether that's a good
architectural
Hi Vignesh,
Thanks for sharing the review comments. Please find my response below.
> 1) We can drop the table after this test.
>
Done.
> 2) +-- Test for accessing Temporary table
> +-- in prepare transaction.
> can be changed to
> -- Test for accessing cached temporary table in a prepared transac
On Tue, Apr 6, 2021 at 8:18 PM Himanshu Upadhyaya
wrote:
>
> Hi,
>
> While working on one of the issue, I have noticed below unexpected behavior
> with "PREPARE TRANSACTION".
>
> We are getting this unexpected behavior with PREPARE TRANSACTION when it is
> mixed with Temporary Objects. Please co
Hi,
While working on one of the issue, I have noticed below unexpected behavior
with "PREPARE TRANSACTION".
We are getting this unexpected behavior with PREPARE TRANSACTION when it is
mixed with Temporary Objects. Please consider the below setup and SQL block.
set max_prepared_transactions to 1
