Re: stat() vs ERROR_DELETE_PENDING, round N + 1

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>
Subject: Re: stat() vs ERROR_DELETE_PENDING, round N + 1
Date: 2021-09-07 06:00:01
Message-ID: 6d84b297-aeec-6196-f4cf-99fc7b94a638@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

06.09.2021 16:04, Thomas Munro wrote:
> On Mon, Sep 6, 2021 at 6:36 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> The last time I poked at the bear (54fb8c7d), there was a test posted
>> by Alexander Lakhin that was really useful in making sure that
>> concurrency is correctly handled when a file is unlinked:
>> https://www.postgresql.org/message-id/c3427edf-d7c0-ff57-90f6-b5de3bb62709@gmail.com
The new approach looks very promising. Knowing that the file is really
in the DELETE_PENDING state simplifies a lot.
I've tested the patch v2_0001_Check... with my demo tests [1] and [2],
and it definitely works.

[1]
https://www.postgresql.org/message-id/e5179494-715e-f8a3-266b-0cf52adac8f4%40gmail.com
[2]
https://www.postgresql.org/message-id/c3427edf-d7c0-ff57-90f6-b5de3bb62709@gmail.com

Best regards,
Alexander

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2021-09-07 06:00:28 Re: Data loss when '"json_populate_recorset" with long column name
Previous Message Michael Paquier 2021-09-07 05:59:58 Re: strange case of "if ((a & b))"