On Thu, Feb 02, 2023 at 06:59:51AM -0800, Andres Freund wrote:
> On 2022-09-20 11:32:02 -0700, Nathan Bossart wrote:
>> Note that this change also disallows XMAX_COMMITTED together with
>> the special pre-v9.3 locked-only bit pattern that
>> HEAP_XMAX_IS_LOCKED_ONLY checks for. This locked-only
Hi,
On 2022-09-20 11:32:02 -0700, Nathan Bossart wrote:
> Note that this change also disallows XMAX_COMMITTED together with
> the special pre-v9.3 locked-only bit pattern that
> HEAP_XMAX_IS_LOCKED_ONLY checks for. This locked-only bit pattern
> may still be present on servers pg_upgraded from
On Tue, Sep 20, 2022 at 2:32 PM Nathan Bossart
wrote:
> Here is a rebased patch for cfbot.
>
>
>
Applies, passes make check world.
Patch is straightforward, but the previous code is less so. It purported to
set XMAX_COMMITTED _or_ XMAX_INVALID, but never seemed to un-set
XMAX_COMMITTED, was
Here is a rebased patch for cfbot.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 9ae1f5409ddeee17b99a9565247da885cbb86be9 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 22 Mar 2022 15:35:34 -0700
Subject: [PATCH v6 1/1] Disallow setting XMAX_COMMITTED and
On Tue, Mar 22, 2022 at 04:13:47PM -0700, Andres Freund wrote:
> Just skimming this thread quickly, I really have no idea what this is trying
> to achieve and the commit message doesn't help either... I didn't read the
> referenced thread, but I shouldn't have to, to get a basic idea.
Ah, my
Hi,
On 2022-03-22 16:06:40 -0700, Nathan Bossart wrote:
> On Thu, Mar 17, 2022 at 04:45:28PM -0700, Nathan Bossart wrote:
> > I think this one requires some more work, and it needn't be a priority for
> > v15, so I've adjusted the commitfest entry to v16 and moved it to the next
> > commitfest.
>
On Thu, Mar 17, 2022 at 04:45:28PM -0700, Nathan Bossart wrote:
> I think this one requires some more work, and it needn't be a priority for
> v15, so I've adjusted the commitfest entry to v16 and moved it to the next
> commitfest.
Here is a new patch. The main differences from v3 are in
I think this one requires some more work, and it needn't be a priority for
v15, so I've adjusted the commitfest entry to v16 and moved it to the next
commitfest.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On 12/21/21, 11:42 AM, "Mark Dilger" wrote:
> + /* pre-v9.3 lock-only bit pattern */
> + ereport(ERROR,
> + (errcode(ERRCODE_DATA_CORRUPTED),
> +errmsg_internal("found tuple with HEAP_XMAX_COMMITTED
> and"
> +
> On Dec 1, 2021, at 10:59 AM, Bossart, Nathan wrote:
>
> here is a v3
It took a while for me to get to this
@@ -1304,33 +1370,46 @@ HeapTupleSatisfiesVacuumHorizon(HeapTuple htup, Buffer
buffer, TransactionId *de
if (HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask))
{
+ if
On 11/25/21, 9:16 AM, "Mark Dilger" wrote:
>> On Nov 24, 2021, at 12:53 PM, Bossart, Nathan wrote:
>>
>> Another option we might consider is only checking for the
>> HEAP_XMAX_LOCK_ONLY bit instead of everything in
>> HEAP_XMAX_IS_LOCKED_ONLY. IIUC everything else is only expected to
>> happen
> On Nov 24, 2021, at 12:53 PM, Bossart, Nathan wrote:
>
> Another option we might consider is only checking for the
> HEAP_XMAX_LOCK_ONLY bit instead of everything in
> HEAP_XMAX_IS_LOCKED_ONLY. IIUC everything else is only expected to
> happen for upgrades from v9.2 or earlier, so it might
On 11/23/21, 4:59 PM, "Mark Dilger" wrote:
>> On Nov 23, 2021, at 4:51 PM, Bossart, Nathan wrote:
>>
>> This is a good point. Right now, you'd have to manually inspect the
>> infomask field to determine the exact form of the invalid combination.
>> My only worry with this is that we'd want to
> On Nov 23, 2021, at 4:51 PM, Bossart, Nathan wrote:
>
> This is a good point. Right now, you'd have to manually inspect the
> infomask field to determine the exact form of the invalid combination.
> My only worry with this is that we'd want to make sure these checks
> stayed consistent
On 11/23/21, 4:36 PM, "Mark Dilger" wrote:
> I have to wonder if, when corruption is reported for conditions like this:
>
> + if ((ctx->tuphdr->t_infomask & HEAP_XMAX_COMMITTED) &&
> + HEAP_XMAX_IS_LOCKED_ONLY(ctx->tuphdr->t_infomask))
>
> if the first thing we're going to
> On Nov 23, 2021, at 4:26 PM, Bossart, Nathan wrote:
>
> I've finally gotten started on this, and I've attached a work-in-
> progress patch to gather some early feedback. I'm specifically
> wondering if there are other places it'd be good to check for these
> unsupported combinations and
The archives seem unhappy with my attempt to revive this old thread,
so here is a link to it in case anyone is looking for more context:
https://www.postgresql.org/message-id/flat/3476708e-7919-20cb-ca45-6603470565f7%40amazon.com
Nathan
On Thu, Aug 27, 2020 at 5:06 PM Mark Dilger
wrote:
> These two are both checked in verify_heapam.c. The point is that the system
> will also refuse to write out pages that have this corruption. The Asserts
> could be converted to panics or whatever, but that has other more serious
>
> On Aug 27, 2020, at 4:58 PM, Peter Geoghegan wrote:
>
> On Thu, Aug 27, 2020 at 4:57 PM Mark Dilger
> wrote:
>> The amcheck patch has Asserts in hio.c that purport to disallow writing
>> invalid header bits to disk.
>
> Can it also be a runtime check for the verification process? I think
On Thu, Aug 27, 2020 at 4:57 PM Mark Dilger
wrote:
> The amcheck patch has Asserts in hio.c that purport to disallow writing
> invalid header bits to disk.
Can it also be a runtime check for the verification process? I think
that we can easily afford to be fairly exhaustive about stuff like
> On Aug 27, 2020, at 4:47 PM, Peter Geoghegan wrote:
>
> On Wed, Aug 26, 2020 at 12:16 PM Alvaro Herrera
> wrote:
>> We could do this in stable branches, if there were any reports that
>> this inconsistency is happening in real world databases.
>
> I hope that the new heapam amcheck stuff
On Wed, Aug 26, 2020 at 12:16 PM Alvaro Herrera
wrote:
> We could do this in stable branches, if there were any reports that
> this inconsistency is happening in real world databases.
I hope that the new heapam amcheck stuff eventually leads to our
having total (or near total) certainty about
On 8/26/20, 12:16 PM, "Alvaro Herrera" wrote:
> On 2020-Aug-20, Jeremy Schneider wrote:
>> Alternatively, if we don't want to take this approach, then I'd argue
>> that we should update README.tuplock to explicitly state that
>> XMAX_LOCK_ONLY and XMAX_COMMITTED are incompatible (just as it
On 2020-Aug-20, Jeremy Schneider wrote:
> While working with Nathan Bossart on an extension, we came across an
> interesting quirk and possible inconsistency in the PostgreSQL code
> around infomask flags. I'd like to know if there's something I'm
> misunderstanding here or if this really is a
24 matches
Mail list logo
