From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | hawang(at)pivotal(dot)io, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Subject: | Re: Control your disk usage in PG: Introduction to Disk Quota Extension |
Date: | 2018-12-26 05:56:47 |
Message-ID: | 20181226055647.GK2234@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2018-12-26 06:02:04 | Re: plpgsql plugin - stmt_beg/end is not called for top level block of statements |
Previous Message | Tatsuro Yamada | 2018-12-26 05:50:26 | Re: Tab completion for ALTER INDEX|TABLE ALTER COLUMN SET STATISTICS |