From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Craig Ringer <craig@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Postgres, fsync, and OSs (specifically linux)
Date: Sat, 28 Apr 2018 11:10:54 -0400
Message-ID: <20180428151054.GR27724@tamriel.snowman.net> (raw)
In-Reply-To: <20180427234332.wtkjvtkbpdl6mu6g@alap3.anarazel.de>
References: <20180427222842.in2e4mibx45zdth5@alap3.anarazel.de>
<20180427230447.GA32605@momjian.us>
<20180427231043.of7vhjmhx4qzexm7@alap3.anarazel.de>
<20180427233830.GB32605@momjian.us>
<20180427234332.wtkjvtkbpdl6mu6g@alap3.anarazel.de>
Greetings,
* Andres Freund (andres@anarazel.de) wrote:
> On 2018-04-27 19:38:30 -0400, Bruce Momjian wrote:
> > On Fri, Apr 27, 2018 at 04:10:43PM -0700, Andres Freund wrote:
> > > On 2018-04-27 19:04:47 -0400, Bruce Momjian wrote:
> > > > On Fri, Apr 27, 2018 at 03:28:42PM -0700, Andres Freund wrote:
> > > > > - We need more aggressive error checking on close(), for ENOSPC and
> > > > > EIO. In both cases afaics we'll have to trigger a crash recovery
> > > > > cycle. It's entirely possible to end up in a loop on NFS etc, but I
> > > > > don't think there's a way around that.
> > > >
> > > > If the no-space or write failures are persistent, as you mentioned
> > > > above, what is the point of going into crash recovery --- why not just
> > > > shut down?
> > >
> > > Well, I mentioned that as an alternative in my email. But for one we
> > > don't really have cases where we do that right now, for another we can't
> > > really differentiate between a transient and non-transient state. It's
> > > entirely possible that the admin on the system that ran out of space
> > > fixes things, clearing up the problem.
> >
> > True, but if we get a no-space error, odds are it will not be fixed at
> > the time we are failing. Wouldn't the administrator check that the
> > server is still running after they free the space?
>
> I'd assume it's pretty common that those are separate teams. Given that
> we currently don't behave that way for other cases where we *already*
> can enter crash-recovery loops I don't think we need to introduce that
> here. It's far more common to enter this kind of problem with pg_xlog
> filling up the ordinary way. And that can lead to such loops.
When we crash-restart, we also go through and clean things up some, no?
Seems like that gives us the potential to end up fixing things ourselves
and allowing the crash-restart to succeed.
Consider unlogged tables, temporary tables, on-disk sorts, etc. It's
entirely common for a bad query to run the system out of disk space (but
have a write of a regular table be what discovers the out-of-space
problem...) and if we crash-restart properly then we'd hopefully clean
things out, freeing up space, and allowing us to come back up.
Now, of course, ideally admins would set up temp tablespaces and
segregate WAL onto its own filesystem, etc, but...
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, andres@anarazel.de, bruce@momjian.us, craig@2ndquadrant.com
Subject: Re: Postgres, fsync, and OSs (specifically linux)
In-Reply-To: <20180428151054.GR27724@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox