Date: Wed, 26 Dec 2018 14:56:47 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: hawang@pivotal.io,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>
Subject: Re: Control your disk usage in PG: Introduction to Disk Quota
 Extension
Message-ID: <20181226055647.GK2234@paquier.xyz>
References: 
 <CAB0yre=RP_ho6Bq4cV23ELKxRcfhV2Yqrb1zHp0RfUPEWCnBRw@mail.gmail.com>
 <eface0f387a6f7530862ef40e3e3e55ac915ea83.camel@2ndquadrant.com>
 <CAB0yrenHV2iw4hQEnHGkTTpXZN8jMUJNtsCV4=BmWckjnn16Mg@mail.gmail.com>
 <CAL_NLp+jLqn9P+hzy1vYSqoUuCsJ4AtTF4QYH5=950rB9S3dSw@mail.gmail.com>
 <CA+Tgmoa9m74nhU8LpPfsiW-WS2MvWkipCEn4VW40kFrMMkbhKw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="75WsOQSofUOhcSOp"
Content-Disposition: inline
In-Reply-To: 
 <CA+Tgmoa9m74nhU8LpPfsiW-WS2MvWkipCEn4VW40kFrMMkbhKw@mail.gmail.com>
Precedence: bulk


--75WsOQSofUOhcSOp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--75WsOQSofUOhcSOp
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlwjGB8ACgkQnvQgOdby
QH3+6Q/+Lh4wCJDZXp7jBEjvkAmlY5Ny2YACfTC6FFsCnOtnuYlD3anRLFni9oR9
Qpey3tg4c1rQjdwYGgp0l2nN7ZXspXaP62JjPUFpASVtEIwtergY+XQrXRN//Mq+
emnicpwghDKp8tZhzYDFumVjEfcj+KSJTveT0TNB0W/N/odZLH17vZeptwwWTWqa
RZ/HMBco+dH+lNGskTXV6qXLAv9suSwjN6k0JipB4KBCyKd1otam3fjiXi5Kbsnm
Z2hOGRyQI8nrh/O4XzLxYBdxIUiKOa+luzphp/YNAZgCT1KAu9sIATihc1dN8bn8
z0Z981iX4Pd5lflPgD6Tnn0OT+9Br7ERylCXakLGjyoSrmIbAaOREHekcuE15Jew
rqFzwewT6Mrn92WUjjXHgZ6ODeckTUHNWhMuWVylwUA8VESso1E99LMr8wxmxqV0
cpTKLJwOXzRYgbz49PdJlImIMDYR4hdclsCBDzF2+1VStPclgphaHbaNO4QEOqc9
4jer3HSUYFRVnXpmn1MfRjh/H/g/NAfrEhcm0F+v+poPKH/PuCRwpJzaDDUKvFM/
O7kzpfgG+/NY2Sj8U0YV7QAepXH1ylGEYfKKT8CdlR9whgLEtCKPaCoBoT9dqkAF
hguFIV/95WLgA6aX9eTTvsa4XaiB7gLRLoSwZGgtl/7i/HA6WBw=
=uqO+
-----END PGP SIGNATURE-----

--75WsOQSofUOhcSOp--