Re: The same 2PC data maybe recovered twice

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "suyu(dot)cmj" <mengjuan(dot)cmj(at)alibaba-inc(dot)com>
Cc: "zhihui(dot)fan1213" <zhihui(dot)fan1213(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: The same 2PC data maybe recovered twice
Date: 2023-07-18 05:13:52
Message-ID: ZLYfkPNovHH+IIhE@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Mon, Jul 17, 2023 at 05:20:00PM +0800, suyu.cmj wrote:
> Thanks for the feedback! I have updated the patch, hope you can check it.

I have looked at v3, and noticed that the stat() call is actually a
bit incorrect in its error handling because it would miss any errors
that happen when checking for the existence of the file. The only
error that we should safely expect is ENOENT, for a missing entry.
All the other had better fail like the other code paths restoring 2PC
entries from the shared state. At the end, I have made the choice of
relying only on access() to check the existence of the file as this is
an internal place, simplified a bit the comment. Finally, I have made
the choice to remove the assert-only check. After sleeping on it, it
would have value in very limited cases while a bunch of recovery cases
would take a hit, including developers with large 2PC setups, so there
are a lot of downsides with limited upsides.
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2023-07-18 05:44:18 Re: BUG #18026: compile error / fe-auth.c:807:64: error: 'CHAR_BIT' undeclared (first use in this function)
Previous Message Tom Lane 2023-07-18 03:51:16 Re: pg_dump needs an option to add the force flag to the drop database

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-07-18 05:28:08 Re: Support logical replication of DDLs
Previous Message Masahiko Sawada 2023-07-18 04:57:19 Re: logicalrep_message_type throws an error