Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruHdY-004Bqk-TN for pgsql-bugs@arkaria.postgresql.org; Tue, 09 Apr 2024 20:00:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ruHdY-00ASEQ-24 for pgsql-bugs@arkaria.postgresql.org; Tue, 09 Apr 2024 20:00:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruHdX-00ASEI-OP for pgsql-bugs@lists.postgresql.org; Tue, 09 Apr 2024 20:00:07 +0000 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ruHdU-00242O-E4 for pgsql-bugs@lists.postgresql.org; Tue, 09 Apr 2024 20:00:06 +0000 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-516c403cc46so11292798e87.3 for ; Tue, 09 Apr 2024 13:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712692803; x=1713297603; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=SxgynrmFhHMnrOgrJJQL4ncbdjuKjix5ZBG1kF2WWTo=; b=cWWagzbdyifIZOnO38/JYtXFmkDY4Pj9VPYdiMZ7JQWNxQB9KAhPCfRNpMmIyLbXKc b5BTr/3fW7rJQWP+bCnynMhMEAEgWR/3VeOh6m+9udbCdgZ4B7Vw2QMa8Zr5ZtNIs7Lk h+/yMQopR7KiZqBABBon+2YKdj7w1xJmu4r+UKf16uNzjwyjD88asfeJalgbHnSXA7St 54dqQ9LHHcyf2p9RSn7DqDM/yfxzwhVMddpO9x4RrikK0aI78hNvKh5MxI3zT+JtH2BS ebPaei7AkZWpoKT3AZSKhxvFr1KUhAOCWk2qESqcuD0zig75oGqXAe9S68n6b0B8Yo+y Uvjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712692803; x=1713297603; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SxgynrmFhHMnrOgrJJQL4ncbdjuKjix5ZBG1kF2WWTo=; b=CnW2DUtV9GEewwb9Vou83xUsJjAPAjcSJ019cV5JEGR25dCrrzITlG2ZR03Lss6JGg O/fJtefJdRgKvtwjcYdndUqpdI1eO+Bj4piHj9zDakvcDoQVGKPwxb9Ef0KQVbgi8Fv6 ENQW+0zKIe6ltPYnnCGZJoRGjHLYgTiCwQju/e294BYeS2WOZ9wk6z+M9TJNyr19DQuZ uAetPrQ73BH5Ezc7Povkf/PwpY73QIFmU9JsAuv3i++/L96VEJoMmXdm5OcYe5ulzcsF dwGfnaHPYwU90LjV8BA0t8am1jM9ZFRQd00p//NmqExquPtqGMkZy3yXKTRjTnQ0Ihib PgUw== X-Gm-Message-State: AOJu0YzMfn9nPzgZAh7NQCjGJX8sESsBKAXirig8S2rxODcA3311bBJZ lcDoDhlrlVRm6InBiJ87lee7uFnSYBPDDIBXG4+XgVStGZ53QeIs X-Google-Smtp-Source: AGHT+IG4pVAvfmP7Q2nIppuyNUPFMMS+AWWSFaDlzw2KHtPsQ92odAxcgTTH9DY2TqVtwiLpve0Yrg== X-Received: by 2002:ac2:554c:0:b0:516:c44a:657d with SMTP id l12-20020ac2554c000000b00516c44a657dmr326190lfk.64.1712692802379; Tue, 09 Apr 2024 13:00:02 -0700 (PDT) Received: from [1.0.0.7] ([91.185.79.145]) by smtp.gmail.com with ESMTPSA id 23-20020ac24837000000b00516be080873sm1631385lft.8.2024.04.09.13.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Apr 2024 13:00:01 -0700 (PDT) Message-ID: Date: Tue, 9 Apr 2024 23:00:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune() Content-Language: en-US To: Robert Haas Cc: PostgreSQL mailing lists References: <17257-1e46de26bec11433@postgresql.org> <5cbe0b03-d6f3-501d-3849-534568b0e776@gmail.com> From: Alexander Lakhin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 09.04.2024 21:59, Robert Haas wrote: > >> But on dad1539ae I got no failures for 3 runs (the same is on >> REL_16_STABLE with a slightly modified lazy_scan_prune patch). > I'm having trouble understanding what this means exactly -- are you > talking about REL_16_STABLE, or about dad1539ae, or both, or what? At > any rate, it's really important here that we understand whether we > still have a bug here, and if so, in which releases and with what test > case. I wasn't aware of dad1539ae but that certainly seems like it > might've made a big difference, if not fixing the problem entirely > then at least making it a lot less likely. And I think it's possible > that some of the related freezing+pruning commits on master might have > removed the problem altogether, but that needs to be tested. I was talking about both — dad1539ae eliminated the bug (judging from the repro) on REL_14_STABLE, and I suppose that 18b87b201 did the same for REL_15_STABLE/REL_16_STABLE... (On 18b87b201~1 I've got (twice): TRAP: FailedAssertion("HeapTupleHeaderIsHeapOnly(htup)", File: "pruneheap.c", Line: 964, PID: 1854895) I can double-check exactly 18b87b201 with the repro, if it makes sense.) Best regards, Alexander