Re: global / super barriers (for checksums) - Mailing list pgsql-hackers

On Wed, Dec 11, 2019 at 12:38 PM Andres Freund <andres@anarazel.de> wrote:
> I just don't buy this argument. There's a difference in between an
> unpatched version of postgres suddenly potentially running hooks
> everywhere CFI() etc is called, and some user patching postgres to
> behave differently. In the former case we'll have to ask to reproduce
> problems without extension in a lot more cases.  For me code like this
> that runs in pretty low level situations that we've gotten wrong more
> than once, doesn't benefit by being extensible. We just make things more
> fragile, and provide traps for extension authors.

It seems to me that this amounts to an argument that (a) core
developers are smarter than extension developers, and are thus the
only ones entitled to play with sharp tools, and/or (b) core
developers are more important than extension developers, and thus
inconveniencing extension developers is OK if it makes life better for
core developers. Both propositions seem pretty arrogant to me.

> But that's just not how it ends up working in a lot of cases? People
> still report bugs to the list, and the debugging experience of problems
> where an extension causes crashes-at-a-distance is pretty bad.

I agree that crashes at a distance are bad, and that those caused by
extensions are more annoying than those caused by core code, because
in the latter case there is a silent contributor to the problem about
which we may have little information. However, I disagree with the
idea that the right solution is to try to lock things down so that
extension authors can't do stuff. Extensibility is an important part
of what has made PostgreSQL successful, and I think we need more of
it, not less.

We can to some extent mitigate these kinds of problems by adding
assertions to our code that will catch usage errors, which has the
advantage that those things also get caught when somebody accidentally
introduces such bugs into core. To the extent that we can't mitigate
them, I think we should live with them, because I think extensibility
is far too valuable to cast aside over such concerns.

While I have passionate philosophical feelings about this topic, for
purposes of the present thread the really important question (IMV,
anyway) is whether there's any way of getting a patch for global
barriers committed in advance of the first user of such barriers. Both
your version and mine add an enum, and I think that you can't have an
enum with no elements. If you have a suggestion as to how we can
structure things so that we can start out with 0 users of this
mechanism rather than needing to start out with 1, I'd like to hear
them. If not, then I guess we'll need to decide which of checksum
enable/disable and ALTER SYSTEM READ ONLY is going to go first and
commit this only when that patch is ready to go as well. Or, I
suppose, commit it with a dummy placeholder that then gets replaced by
whichever patch goes first, but I'm not sure whether people would be
OK with that.

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