Re: Modest proposal to extend TableAM API for controlling cluster commands - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Modest proposal to extend TableAM API for controlling cluster commands
Date
Msg-id 20220616072759.m5hezdtnbncz7x22@alap3.anarazel.de
Whole thread Raw
In response to Re: Modest proposal to extend TableAM API for controlling cluster commands  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: Modest proposal to extend TableAM API for controlling cluster commands
List pgsql-hackers
Hi,

On 2022-06-15 22:23:36 -0700, Mark Dilger wrote:
> I'm not entirely against you on that, but it makes me cringe that we impose
> design decisions like that on any and all future TAMs.  It seems better to
> me to let the TAM author decide to emit an error, warning, notice, or
> whatever, as they see fit.

The tradeoff is that that pushes down complexity and makes the overall system
harder to understand. I'm not saying that there's no possible use for such
callbacks / configurability, I'm just not convinced it's worth the cost.


> >> But I can't really complete my work with the interface as it stands
> >> now.
> > 
> > Since you've not described that work to a meaningful degree...
> 
> I don't think I should have to do so.  It's like saying, "I think I should
> have freedom of speech", and you say, "well, I'm not sure about that; tell
> me what you want to say, and I'll decide if I'm going to let you say it".'
> That's not freedom.  I think TAM authors should have broad discretion over
> anything that the core system doesn't have a compelling interest in
> controlling.

That's insultingly ridiculous. You can say, do whatever you want, but that
doesn't mean I have to be convinced by it (i.e. +1 adding an API) - that'd be
compelled speech, to go with your image...

It's utterly normal to be asked what the use case for a new API is when
proposing one.


> You've not yet said why a TAM should be prohibited from opting
> out of cluster/vacfull.

API / behavioural complexity. If we make ever nook and cranny configurable,
we'll have an ever harder to use / administer system (from a user's POV) and
have difficulty understanding the state of the system when writing patches
(from a core PG developer's POV). It might be the right thing in this case -
hence me asking for what the motivation is.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: "David G. Johnston"
Date:
Subject: Re: Modest proposal to extend TableAM API for controlling cluster commands