pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Jakub Wartak <Jakub.Wartak@tomtom.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: WIP: WAL prefetch (another approach)
Date: Fri, 9 Apr 2021 15:36:58 -0500
Message-ID: <20210409203658.GU6592@telsasoft.com> (raw)
In-Reply-To: <CA+hUKG+deAXJUigdX4yDqwzWyqr6qLA8StiWJVFOHTy83eqqtA@mail.gmail.com>
References: <20210214231815.GO27507@tamriel.snowman.net>
	<17b3f450-048c-f3a6-7086-259523f33cbc@enterprisedb.com>
	<20210317214331.GF20766@tamriel.snowman.net>
	<28c3352e-5388-6410-aae7-05907079e6c9@enterprisedb.com>
	<CA+hUKGLHTjbBPFX6E1ZCGVyQD30-vWtH=N6EcHEzW13q+jh7FQ@mail.gmail.com>
	<8dd2dcc2-0b6b-a4ab-c1b3-032c0a5ab1c3@enterprisedb.com>
	<CA+hUKGKmkKfH1h9XG5ctYCgqeOHGdN5bHMoQMZLR=+kLY0PQzA@mail.gmail.com>
	<CA+hUKGLsF8sEE+n3qoaV6+XjmYEwYoFVDbLPbYTGz7oGkL=iZA@mail.gmail.com>
	<20210409033703.GP6592@telsasoft.com>
	<CA+hUKG+deAXJUigdX4yDqwzWyqr6qLA8StiWJVFOHTy83eqqtA@mail.gmail.com>

On Sat, Apr 10, 2021 at 08:27:42AM +1200, Thomas Munro wrote:
> On Fri, Apr 9, 2021 at 3:37 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> > Here's some little language fixes.
> 
> Thanks!  Done.  I rewrote the gibberish comment that made you say
> "XXX: what?".  Pushed.
> 
> > BTW, before beginning "recovery", PG syncs all the data dirs.
> > This can be slow, and it seems like the slowness is frequently due to file
> > metadata.  For example, that's an obvious consequence of an OS crash, after
> > which the page cache is empty.  I've made a habit of running find /zfs -ls |wc
> > to pre-warm it, which can take a little bit, but then the recovery process
> > starts moments later.  I don't have any timing measurements, but I expect that
> > starting to stat() all data files as soon as possible would be a win.
> 
> Did you see commit 61752afb, "Provide
> recovery_init_sync_method=syncfs"?  Actually I believe it's safe to
> skip that phase completely and do a tiny bit more work during
> recovery, which I'd like to work on for v15[1].

Yes, I have it in my list for v14 deployment.  Thanks for that.

Did you see this?
https://www.postgresql.org/message-id/GV0P278MB0483490FEAC879DCA5ED583DD2739%40GV0P278MB0483.CHEP278...

I meant to mail you so you could include it in the same commit, but forgot
until now.

-- 
Justin





view thread (174+ messages)  latest in thread

Message-ID: <20210409203658.GU6592@telsasoft.com>
Permalink:  ../20210409203658.GU6592@telsasoft.com/
Also on:    postgresql.org/message-id/20210409203658.GU6592@telsasoft.com

 · 

reply
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: pryzby@telsasoft.com, thomas.munro@gmail.com, tomas.vondra@enterprisedb.com, sfrost@snowman.net, andres@anarazel.de, Jakub.Wartak@tomtom.com, alvherre@2ndquadrant.com, tomas.vondra@2ndquadrant.com, 9erthalion6@gmail.com, david@pgmasters.net
  Subject: Re: WIP: WAL prefetch (another approach)
  In-Reply-To: <20210409203658.GU6592@telsasoft.com>

* 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