> 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
03
date_updated | 2023-08-16 03:31:36.306481+03
-[ RECORD 2 ]+-
ctid | (21597,16)
id | 1121skipped
date_created | 2023-08-16 03:31:36.306466+03
date_updated | 2024-09-06 14:10:47.926007+03
Freezing was failing with "cannot freeze committed xmax". xmax
> 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
released the lock).
*/
if (!HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask) &&
TransactionIdDidCommit(xid))
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
errmsg_internal("cannot
Hi,
On 2020-07-24 11:06:58 -0400, Robert Haas wrote:
> On Thu, Jul 23, 2020 at 2:10 PM Andres Freund wrote:
> > In the case the HOT logic triggers, we'll call
> > heap_prepare_freeze_tuple() even when the tuple is dead.
>
> I think this is very bad. I've always been confused about these
> comment
On Thu, Jul 23, 2020 at 2:10 PM Andres Freund wrote:
> In the case the HOT logic triggers, we'll call
> heap_prepare_freeze_tuple() even when the tuple is dead.
I think this is very bad. I've always been confused about these
comments, but I couldn't quite put my finger on the problem. Now I
think
ansactionIdDidCommit(xid))
ereport(PANIC,
(errcode(ERRCODE_DATA_CORRUPTED),
errmsg_internal("cannot freeze
committed xmax %u",
10 matches
Mail list logo