Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1LCs-00045I-Co for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jul 2021 04:00:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m1LCq-0006To-DC for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jul 2021 04:00:08 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1LCq-0006Tg-3s for pgsql-hackers@lists.postgresql.org; Thu, 08 Jul 2021 04:00:08 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m1LCn-0001Nt-MV for pgsql-hackers@postgresql.org; Thu, 08 Jul 2021 04:00:07 +0000 Received: by mail-lf1-x134.google.com with SMTP id t17so10897517lfq.0 for ; Wed, 07 Jul 2021 21:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=siXMfd5oT5Ve5AhoFn1n6azhdzd9HXVAWUVETrfZ+CM=; b=KGUEcGJtjPoPCsnuB3ZOMHWiSh0PTeyAg23QgtKp0mre2+tb0SzDS/JgZMvMAGIlwd +CgZzTzAJd6l3DccIn7LOvEu+n5v/BOWSPi0XnvZP4IQELHXddnBgTj1ptIu90TfkK0j XCbB+5Cr/s+bUKL1Q77tFDJ0DhDIytTDFqJ8tyx7iOZdbhC2NV08B67HCic1mV6PvLcG kwcGV+kNPgbtYEyZGMUgfHgPP8lb0PiGn8AfAeNob6ybDjC7sKZDGYb22rKJ6UEOhQcP aLQ4BaahEgMjG5rv5szpkfXs9SxJBdaW+wZTNHmKILVXBTOts74p9eCCsXlXe/43JZ/x SPmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=siXMfd5oT5Ve5AhoFn1n6azhdzd9HXVAWUVETrfZ+CM=; b=StDV8fLpgQQT/kC6l/Rit2RCJys63Lo1Gp1wVwEBkzZfuXBxWYPMz2267ZN5qHDpHQ z4/BBajhHYCAduZicp4Jp7TQlefaOQqXHkg+VNcmQCX0kim8TgHoKWPkwI/h1S47QtS9 o3K6agjYzigqSMVRkLraMXVropFKyw+mEdtC9s9i04Arp9X6N5c6dlK0LERvr6LI71vu C8jUdWHvp0Ld1Umoxcv23optZ3l9clFooIv6+5X5Hh4HFYXGlK+u/0jADeU5ReFzJkUV K43QIrT2bfmZ7ovQSR+118sCNoQjQVXtYpFoZvWysNjAVG0r4hMgts3gCkBkdqUoIcv1 vBCA== X-Gm-Message-State: AOAM531S+BgNkpvFzKC900ioxIkKvxclenIGDpuifQ1yCD6/vlQ/cAYh XPbgvPcIIWW6D3KtrEeHKc9cbuMOra0= X-Google-Smtp-Source: ABdhPJwjOQZ5whBHBbiiCYMkQWxzCR9atH3Yi06fHvshINMPcJvcN7FrtAnWWLr3KwG7bHzVmuZeEA== X-Received: by 2002:a05:651c:2115:: with SMTP id a21mr22100574ljq.185.1625716803230; Wed, 07 Jul 2021 21:00:03 -0700 (PDT) Received: from [1.0.0.7] ([178.155.6.217]) by smtp.gmail.com with ESMTPSA id m5sm102747ljo.88.2021.07.07.21.00.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 21:00:02 -0700 (PDT) Subject: Re: More time spending with "delete pending" To: Michael Paquier Cc: pgsql-hackers , Tom Lane , Justin Pryzby References: <20201115011112.GW30691@telsasoft.com> <979f4ee6-9960-e37f-f3ee-f458e87777b0@gmail.com> <995713.1605725597@sss.pgh.pa.us> <1001775.1605731995@sss.pgh.pa.us> <3366bfde-183f-60be-62ab-8ae81b946bac@gmail.com> <1006364.1605738508@sss.pgh.pa.us> <20729794-e2bf-bd7a-f01b-d132f89fd0d7@gmail.com> From: Alexander Lakhin Message-ID: <78fa6a17-8e71-7c99-62bd-8a11a47fe894@gmail.com> Date: Thu, 8 Jul 2021 07:00:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Michael, 06.07.2021 11:33, Michael Paquier wrote: > On Sun, Mar 14, 2021 at 06:00:00PM +0300, Alexander Lakhin wrote: >> I believe that the patch attached to [1] should fix this issue. The >> patch still applies to master and makes the demotest (attached to [2]) >> pass. Also I've prepared a trivial patch that makes pgwin32_open() use >> the original stat() function (as in the proposed change for _pgstat64()). > Hmm. Knowing that _pgfstat64() has some special handling related to > files pending for deletion, do we really need that on HEAD? Yes, this fix is needed for HEAD (b9734c13) as the simple test attached to [1] shows: (You can put that script in src\test\modules\test_misc\t and perform `vcregress taptest src\test\modules\test_misc`.) t/001_delete_pending.pl ......... # Looks like your test exited with 2 before it could output anything. and src\test\modules\test_misc\tmp_check\log\regress_log_001_delete_pending contains: # Postmaster PID for node "node" is 1616 error running SQL: 'psql::1: ERROR:  could not stat file "pg_wal/dummy": Permission denied' while running 'psql -XAtq -d port=64889 host=127.0.0.1 dbname='postgres' -f - -v ON_ERROR_STOP=1' with sql 'select count(*) > 0 as ok from pg_ls_waldir();' at C:/src/postgresql/src/test/perl/PostgresNode.pm line 1771. As Tom Lane noted above, the code added with bed90759f is dubious (_NtQueryInformationFile() can not be used to handle the "delete pending" state as CreateFile() returns INVALID_HANDLE_VALUE in this case.) Probably that change should be reverted. Should I do it along with the proposed fix? [1] https://www.postgresql.org/message-id/c3427edf-d7c0-ff57-90f6-b5de3bb62709%40gmail.com Best regards, Alexander