From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Subject: | Re: amcheck (B-Tree integrity checking tool) |
Date: | 2017-03-06 23:57:00 |
Message-ID: | 20170306235700.o7moee5qn3optttl@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-02-13 12:05:21 -0500, Robert Haas wrote:
> On Fri, Feb 10, 2017 at 8:39 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > On Thu, Feb 9, 2017 at 2:32 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> Except that the proposed names aren't remotely like that... ;).
> >
> > Revision attached -- V5. We now REVOKE ALL on both functions, as
> > Robert suggested, instead of the previous approach of having a
> > hard-coded superuser check with enforcement.
> >
> >> And I proposed documenting named parameters, and
> >> check_btree(performing_check_requiring_exclusive_locks => true) is just
> >> about as expressive.
> >
> > I have not done this, nor have I renamed the functions. I still think
> > that this is something that we can fix by adding a boolean argument to
> > each function in the future, or something along those lines. I
> > *really* hate the idea of having one function with non-obvious,
> > variable requirements on locking, with locking implications that are
> > not knowable when we PREPARE an SQL statement calling the function. It
> > also removes a useful way of have superusers discriminate against the
> > stronger locking variant bt_index_parent_check() by not granting
> > execute on it (as an anti-footgun measure).
>
> I think Andres is more or less correct that
> "performing_check_requiring_exclusive_locks => true" is just about as
> expressive as calling a different function, but I think that your
> point that the superuser might want to grant access to one function
> but not the other is a good one. On the other hand, I think Andres
> has a concern that we might have more modes in the future and we don't
> want to end up with 2^n entrypoints. That also seems valid. Hmm.
That's part of my concern. The second part is that I really want to be
able to have a check_relation() (and check_database())function that I
can pass a bunch of arguments determining how expensive checks are going
to be performed.
E.g. I'd like to be able to do something like
SELECT *
FROM check_relation(
'my_table'::regclass,
test_btree => 'true',
test_btree_heap_interlock => 'true',
test_gin => 'true');
SELECT *
FROM check_current_database(
test_heap_update_chains => 'true',
test_heap_clog_interlock => 'true',
test_btree => 'true',
test_gin => 'false');
etc.
You can't really trivially replace these with a larger query and/or
function, because of the locking considerations (consider what happens
if somebody concurrently drops a table/index - your whole query errors
out, wasting hours of work).
I'm ok with not immediately doing so, but I think Peter's design isn't
in line with achieving something like this.
Regards,
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-03-06 23:59:02 | Re: Performance degradation in TPC-H Q18 |
Previous Message | Michael Paquier | 2017-03-06 23:55:15 | Re: contrib modules and relkind check |