Re: Modest proposal to extend TableAM API for controlling cluster commands

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: Modest proposal to extend TableAM API for controlling cluster commands
Дата
Msg-id C63D2921-DBD3-44D6-8221-F027F5727649@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Modest proposal to extend TableAM API for controlling cluster commands  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers

> On Jun 16, 2022, at 12:27 AM, Andres Freund <andres@anarazel.de> wrote:
>
>> 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...

Indeed it would be compelled speech, and I'm not trying to compel you, only to convince you.  And my apologies if it
cameacross as insulting.  I have a lot of respect for you, as do others at EDB, per invariably complementary comments
I'veheard others express. 

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

It seems like we're talking on two different levels.  I've said what the use case is, which is to implement a TAM that
doesn'tbenefit from cluster or vacuum full, without the overhead of needlessly copying itself, and without causing
argumentlessVACUUM FULL commands to fail.  I'm *emphatically* not asking the community to accept the TAM back as a
patch. The freedom I'm talking about is the freedom to design and implement such a third-party TAM without seeking
communityapproval of the TAM's merits. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: SLRUs in the main buffer pool, redux