Re: Checkpoint not retrying failed fsync?
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-08T05:36:00Z
Lists: pgsql-hackers
On Fri, Apr 6, 2018 at 6:26 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Fri, Apr 6, 2018 at 11:36 AM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> On Fri, Apr 6, 2018 at 11:34 AM, Andrew Gierth >> <andrew@tao11.riddles.org.uk> wrote: >>> Right. >>> >>> But I don't think just copying the value is sufficient; if a new bit was >>> set while we were processing the old ones, how would we know which to >>> clear? We couldn't just clear all the bits afterwards because then we >>> might lose a request. >> >> Agreed. The attached draft patch handles that correctly, I think. > > After some testing, here is a better one for review. Changes: > > 1. The copy wasn't really needed. > 2. errno needed to be restored (in case bms_union stomped on it), > thanks to Andrew for an off-list complaint about that. > 3. Memory context was wrong. > 4. bms_first_member() eats its input. Need to use bms_next_member() instead. > Won't in the success case, you need to delete each member (by something like bms_del_member) rather than just using bms_free? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Don't forget about failed fsync() requests.
- 1556cb2fc5c7 12.0 landed
- 2b2010d12a62 9.4.21 landed
- a4a4aede5fab 9.5.16 landed
- a4d6d6a25c12 9.6.12 landed
- 28117764db7e 10.7 landed
- 542e6f3861ce 11.2 landed