public inbox for [email protected]
help / color / mirror / Atom feedFrom: Haozhou Wang <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: Hubert Zhang <[email protected]>
Subject: Re: Control your disk usage in PG: Introduction to Disk Quota Extension
Date: Mon, 7 Jan 2019 18:56:09 +0800
Message-ID: <CAL_NLpKMknkagF0WzgjeJAjAL=ZosoNifbnqo7YgbtcYgSBepA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAB0yre=RP_ho6Bq4cV23ELKxRcfhV2Yqrb1zHp0RfUPEWCnBRw@mail.gmail.com>
<[email protected]>
<CAB0yrenHV2iw4hQEnHGkTTpXZN8jMUJNtsCV4=BmWckjnn16Mg@mail.gmail.com>
<CAL_NLp+jLqn9P+hzy1vYSqoUuCsJ4AtTF4QYH5=950rB9S3dSw@mail.gmail.com>
<CA+Tgmoa9m74nhU8LpPfsiW-WS2MvWkipCEn4VW40kFrMMkbhKw@mail.gmail.com>
<[email protected]>
Thanks very much for your comments.
To the best of my knowledge, smgr is a layer that abstract the storage
operations. Therefore, it is a good place to control or collect information
the storage operations without touching the physical storage layer.
Moreover, smgr is coming with actual disk IO operation (not consider the OS
cache) for postgres. So we do not need to worry about the buffer management
in postgres.
It will make the purpose of hook is pure: a hook for actual disk IO.
Regards,
Haozhou
On Wed, Dec 26, 2018 at 1:56 PM Michael Paquier <[email protected]> wrote:
> On Wed, Nov 21, 2018 at 09:47:44AM -0500, Robert Haas wrote:
> > +1 for adding some hooks to support this kind of thing, but I think
> > the names you've chosen are not very good. The hook name should
> > describe the place from which it is called, not the purpose for which
> > one imagines that it will be used, because somebody else might imagine
> > another use. Both BufferExtendCheckPerms_hook_type and
> > SmgrStat_hook_type are imagining that they know what the hook does -
> > CheckPerms in the first case and Stat in the second case.
>
> I personally don't mind making Postgres more pluggable, but I don't
> think that we actually need the extra ones proposed here at the layer
> of smgr, as smgr is already a layer designed to call an underlying set
> of APIs able to extend, unlink, etc. depending on the storage type.
>
> > For this particular purpose, I don't immediately see why you need a
> > hook in both places. If ReadBuffer is called with P_NEW, aren't we
> > guaranteed to end up in smgrextend()?
>
> Yes, that's a bit awkward.
> --
> Michael
view thread (24+ messages) latest in thread
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Control your disk usage in PG: Introduction to Disk Quota Extension
In-Reply-To: <CAL_NLpKMknkagF0WzgjeJAjAL=ZosoNifbnqo7YgbtcYgSBepA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox