> On Nov 20, 2024, at 6:39 AM, Andrey M. Borodin wrote:
>
>
>
>> On 20 Nov 2024, at 15:58, Andrey M. Borodin wrote:
>>
>> PFA the patch doing so.
>
> Ugh. The patch is simply dysfunctional, sorry. xmax_status is being checked
> uninitiated.
> But, well, it highlights the idea: make verif
> On 20 Nov 2024, at 15:58, Andrey M. Borodin wrote:
>
> PFA the patch doing so.
Ugh. The patch is simply dysfunctional, sorry. xmax_status is being checked
uninitiated.
But, well, it highlights the idea: make verify_heapam() aware of such
corruptions.
What do you think?
Best regards, And
> On 28 Oct 2020, at 21:21, Mark Dilger wrote:
>
> The other possibillity is that this tuple is erroneously marked as
> HEAP_UPDATED. heap_update() sets that, which makes sense.
> rewrite_heap_tuple() copies the old tuple's bits to the new tuple and then
> does some work to resolve update
> On Oct 28, 2020, at 8:56 AM, Konstantin Knizhnik
> wrote:
>
>
>
> On 28.10.2020 18:25, Mark Dilger wrote:
>>
>>> On Oct 28, 2020, at 6:44 AM, Konstantin Knizhnik
>>> wrote:
>>>
>>> Looks like there is no assumption that xmax should be set to
>>> InvalidTransactionId when HEAP_XMAX_IN
On 28.10.2020 18:25, Mark Dilger wrote:
On Oct 28, 2020, at 6:44 AM, Konstantin Knizhnik
wrote:
Looks like there is no assumption that xmax should be set to
InvalidTransactionId when HEAP_XMAX_INVALID bit is set.
And I didn't find any check preventing cutoff_xid to be greater than XID o
> On Oct 28, 2020, at 6:44 AM, Konstantin Knizhnik
> wrote:
>
> Looks like there is no assumption that xmax should be set to
> InvalidTransactionId when HEAP_XMAX_INVALID bit is set.
> And I didn't find any check preventing cutoff_xid to be greater than XID of
> some transaction which was
