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

help / color / mirror / Atom feed
From: Shawn Debnath <sdn@amazon.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Refactoring the checkpointer's fsync request queue
Date: Mon, 4 Mar 2019 08:55:06 -0800
Message-ID: <20190304165505.GA67539@f01898859afd.ant.amazon.com> (raw)
In-Reply-To: <CA+TgmobdCuF2xNvrL_6H3CzvZsc7nVJbLvd-SL6DSjj++x7trw@mail.gmail.com>
References: <20190222235742.4oed46wocpjfpoa5@alap3.anarazel.de>
	<20190227212653.GA7171@f01898859afd.ant.amazon.com>
	<CA+hUKG+2EuoDhVBdieOKnneFX14SeuRp7z0WG2PSOMJt8ks3qw@mail.gmail.com>
	<CA+hUKGKF7QvUi2ST4R5vd_PVdcztBTXB23ZJwoj_ASoujrbsmQ@mail.gmail.com>
	<20190301174256.3um2t73wycsywrur@alap3.anarazel.de>
	<CA+TgmobqzMkSnWBHcTYqxwQhL3MahX-cpWzs2sVJ4219ciAYGA@mail.gmail.com>
	<20190301193558.GA4664@f01898859afd.ant.amazon.com>
	<CA+Tgmob3hqmNr-EJsudHvFohXKn5wm=Un+nWKXuJiL0fibqhyQ@mail.gmail.com>
	<20190301203533.GB4664@f01898859afd.ant.amazon.com>
	<CA+TgmobdCuF2xNvrL_6H3CzvZsc7nVJbLvd-SL6DSjj++x7trw@mail.gmail.com>

On Fri, Mar 01, 2019 at 04:27:47PM -0500, Robert Haas wrote:
> On Fri, Mar 1, 2019 at 3:35 PM Shawn Debnath <sdn@amazon.com> wrote:
> > On Fri, Mar 01, 2019 at 03:03:19PM -0500, Robert Haas wrote:
> > > On Fri, Mar 1, 2019 at 2:36 PM Shawn Debnath <sdn@amazon.com> wrote:
> > > > I disagree, at least with combining and retaining enums. Encoding all
> > > > the possible request types with the current, planned and future SMGRs
> > > > would cause a sheer explosion in the number of enum  values.
> > >
> > > How big of an explosion would it be?
> >
> > 4 enum values x # of smgrs; currently md, soon undo and slru so 12 in
> > total. Any future smgr addition will expand this further.
> 
> I thought the idea was that each smgr might have a different set of
> requests.  If they're all going to have the same set of requests then
> I agree with you.

Yeah, in this particular case and at this layer, the operations are 
consistent across all storage managers, in that, they want to queue a 
new sync request for a specific file, forget an already queued request, 
forget a hierarchy of requests, or unlink a specific file.

The fun is at the smgr layer which was discussed in a sub-thread in the 
"Drop type smgr" thread started by Thomas. I started on a patch and will 
be sending it out after the refactor patch is revised.


-- 
Shawn Debnath
Amazon Web Services (AWS)




view thread (87+ messages)  latest in thread

Message-ID: <20190304165505.GA67539@f01898859afd.ant.amazon.com>
Permalink:  ../20190304165505.GA67539@f01898859afd.ant.amazon.com/
Also on:    postgresql.org/message-id/20190304165505.GA67539@f01898859afd.ant.amazon.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: sdn@amazon.com, robertmhaas@gmail.com, andres@anarazel.de, thomas.munro@gmail.com, thomas.munro@enterprisedb.com, 9erthalion6@gmail.com
  Subject: Re: Refactoring the checkpointer's fsync request queue
  In-Reply-To: <20190304165505.GA67539@f01898859afd.ant.amazon.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