Re: Re: [COMMITTERS] pgsql: Send new protocol keepalive messages to standby servers.

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Well, TBH I didn't think that concept was a useful solution for this at
> all. I can't imagine that we would define "features" at a sufficiently
> fine granularity, or with enough advance foresight, to solve the sort of
> problem that's being faced here. How would you deal with the need for,
> say, some of contrib/xml2's functions to get migrated to core in 9.4 or
> so? When you didn't know that would happen, much less exactly which
> functions, when 9.3 came out? AFAICS the only way that "features" could

You can provide and require new feature names on the same dependency
graph, and the patch allows us to do so without foresight. The trade off
here is that we would need to edit the previous version of PostgreSQL to
add some new feature names.

In your example we would add a feature name to the contrib/xmls
extensions in a 9.3 minor release and add the same feature to 9.4 core
distribution. That requires minor upgrade before major upgrade for us to
have a chance to deal with lack of foresight.

> fix this would be if we always created a feature for every exposed
> function, which is unmanageable.

Agreed, exposing each function as a feature is not the way to go.

> AFAICS, the SQL-standard features list is just about entirely irrelevant
> to this discussion. How often is it going to happen that we implement a
> standard feature in a contrib module before migrating it into core?

I wanted the standard to help me with the "core features" idea, I agree
it's not a smart move here.

> I think almost every case in which we'll face this problem will involve
> a PG-specific feature not mentioned in the SQL feature taxonomy. The
> case at hand (some proposed new functions for managing replication)
> certainly isn't going to be found there.

Agreed.

> And, quite aside from whether we could invent feature names that match
> what we want to move from contrib to core, exactly how would having a
> feature name help? The problem we're actually facing is getting
> pg_upgrade to not dump particular functions when it's doing a
> binary-upgrade dump of an extension. Maybe I've forgotten, but I do not
> recall any exposed connection between feature names and particular SQL
> objects in your proposal.

We're talking about several distinct problems here, one is low level
upgrade mechanism to keep OIDs and the other is about upgrading to a
newer version of the same extension, which the content changed. And we
want to do both, of course.

The idea would be to implement the upgrade as you're proposing, or at
least my understanding of it, which is to just issue a create extension
command as part of the schema creation. That will run the new extension
script which will know not to install deprecated functions.

The problem with that is to conserve OIDs that might be stored in user
relations, such as types. If we want pg_upgrade to cope with upgrading
an extension to a new content, we have to change its implementation.

An idea would be to add hooks in the backend code at OID attribution
time so that pg_upgrade can attach code that will provide the OID. As
input it should have creating_extension, extension name, schema name and
object name, and also object "argument list" for more complex things
such as functions and aggregates.

I don't think the "extension features" dependency management patch
should be fixing the running the newer extension script while keeping
existing OID list by itself.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support