Re: Postgres, fsync, and OSs (specifically linux)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Craig Ringer <craig@2ndquadrant.com>, Asim Praveen <apraveen@pivotal.io>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>
Date: 2018-11-08T20:06:40Z
Lists: pgsql-hackers
On Thu, Nov 8, 2018 at 3:04 PM Thomas Munro <thomas.munro@enterprisedb.com> wrote: > My reasoning for choosing bms_join() is that it cannot fail, assuming > the heap is not corrupted. It simply ORs the two bit-strings into > whichever is the longer input string, and frees the shorter input > string. (In an earlier version I used bms_union(), this function's > non-destructive sibling, but then realised that it could fail to > allocate() causing us to lose track of a 1 bit). Oh, OK. I was assuming it was allocating. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
PANIC on fsync() failure.
- 9ccdd7f66e33 12.0 landed
- f1ff5f51d249 9.4.21 landed
- 312435232217 9.5.16 landed
- b9cce9ddfa17 9.6.12 landed
- afbe03f65470 10.7 landed
- 6534d544cd77 11.2 landed
-
Fix and improve pg_atomic_flag fallback implementation.
- 8c3debbbf618 11.0 cited