On Tue, Aug 06, 2019 at 03:08:48PM +0200, Daniel Gustafsson wrote:
> Thanks, this is a much better approach and it passes tests for me. +1 on this
> version (regardless of outcome of the other patch as this is separate).
I had an extra lookup at this stuff this morning, and applied the
patch. Pl
> On 6 Aug 2019, at 05:36, Michael Paquier wrote:
>
> On Tue, Aug 06, 2019 at 12:52:09AM +0200, Daniel Gustafsson wrote:
>> Yeah, this is clearly fat-fingered, the intent is to only run the Assert in
>> case XLH_INSERT_CONTAINS_NEW_TUPLE is set in xlrec->flags, as it only applies
>> under that co
On Tue, Aug 06, 2019 at 12:52:09AM +0200, Daniel Gustafsson wrote:
> Yeah, this is clearly fat-fingered, the intent is to only run the Assert in
> case XLH_INSERT_CONTAINS_NEW_TUPLE is set in xlrec->flags, as it only applies
> under that condition. The attached is tested in both in the multi-inser
> On 31 Jul 2019, at 19:20, Heikki Linnakangas wrote:
> This patch makes the assertion more strict than it was before. I don't see
> how it could possibly make a regression failure go away. On the contrary. So,
> huh?
Yeah, this is clearly fat-fingered, the intent is to only run the Assert in
On 08/07/2019 22:42, Daniel Gustafsson wrote:
My patch for using heap_multi_insert in the catalog [1] failed the logical
decoding part of test/recovery [2].
The assertion it failed on seems to not take multi inserts into the catalog
into consideration, while the main logic does. This assertion
My patch for using heap_multi_insert in the catalog [1] failed the logical
decoding part of test/recovery [2].
The assertion it failed on seems to not take multi inserts into the catalog
into consideration, while the main logic does. This assertion hasn't tripped
since there are no multi inserts
