Re: Control your disk usage in PG: Introduction to Disk Quota Extension - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Control your disk usage in PG: Introduction to Disk Quota Extension
Date
Msg-id CA+Tgmoa9m74nhU8LpPfsiW-WS2MvWkipCEn4VW40kFrMMkbhKw@mail.gmail.com
Whole thread Raw
In response to Re: Control your disk usage in PG: Introduction to Disk Quota Extension  (Haozhou Wang <hawang@pivotal.io>)
Responses Re: Control your disk usage in PG: Introduction to Disk Quota Extension  (Haozhou Wang <hawang@pivotal.io>)
Re: Control your disk usage in PG: Introduction to Disk QuotaExtension  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, Nov 20, 2018 at 2:20 AM Haozhou Wang <hawang@pivotal.io> wrote:
> We prepared a patch that includes the hook points. And such hook points are needed for disk quota extension.
> There are two hooks.
> One is SmgrStat_hook. It's used to perform ad-hoc logic in storage when doing smgr create/extend/truncate in general.
Asfor disk quota extension, this hook is used to detect active tables(new created tables, tables extending new blocks,
ortables being truncated) 
> The other is BufferExtendCheckPerms_hook. It's used to perform ad-hoc logic when buffer extend a new block. Since
ReadBufferExtendedis a hot function, we call this hook only when blockNum == P_NEW. As  for disk quota extension, this
hookis used to do query enforcement during the query is loading data. 
>
> Any comments are appreciated.

+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.

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()?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: [PATCH] Log PostgreSQL version number on startup
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Opclass parameters