A Modest Upgrade Proposal

On 05/16/2016 05:52 PM, David Fetter wrote:

Folks,

This path would, of course, run either locally or across a network,
and be testable in both cases. There would be a downgrade path,
namely switching origin nodes.

What say?

What happens when the database is 5TB in size and you only have 500GB
available but that 500GB won't exhaust before the 18 month lease expiry?

JD

Cheers,
David.

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

David Fetter wrote:

As a relatively (to our users) minor course correction, I would like
to propose the following:

- Develop a logical upgrade path as a part of the (Yay! Sexy!) logical
replication that's already in large part built.

This path would, of course, run either locally or across a network,
and be testable in both cases.

This is one use case that pglogical intends to fulfill. If you're able
to contribute to that project, I'm sure many would appreciate it. Right
now the hottest question seems to be: is this something that should be
an extension, or should it be part of core with its own set of DDL etc?
The current patch is geared towards the former, so if the community at
large prefers to have it as the latter and would oppose the former, now
is the time to speak up so that the course can be corrected.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 05/16/2016 06:22 PM, Alvaro Herrera wrote:

David Fetter wrote:

As a relatively (to our users) minor course correction, I would like
to propose the following:

- Develop a logical upgrade path as a part of the (Yay! Sexy!) logical
replication that's already in large part built.

This path would, of course, run either locally or across a network,
and be testable in both cases.

This is one use case that pglogical intends to fulfill. If you're able
to contribute to that project, I'm sure many would appreciate it. Right
now the hottest question seems to be: is this something that should be
an extension, or should it be part of core with its own set of DDL etc?
The current patch is geared towards the former, so if the community at
large prefers to have it as the latter and would oppose the former, now
is the time to speak up so that the course can be corrected.

Alvaro,

Thank you for bringing this to light. Is there a contributor FAQ for
PgLogical so that people can help?

Sincerely,

jD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joshua D. Drake wrote:

Alvaro,

Thank you for bringing this to light. Is there a contributor FAQ for
PgLogical so that people can help?

Hmm, I don't think there's any contributor FAQ. It's supposed to be a
regular patch submission, after all -- it needs user interface review, a
review of the communication protocol, tests, code-level review, etc.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 05/16/2016 06:32 PM, Alvaro Herrera wrote:

Joshua D. Drake wrote:

Alvaro,

Thank you for bringing this to light. Is there a contributor FAQ for
PgLogical so that people can help?

Hmm, I don't think there's any contributor FAQ. It's supposed to be a
regular patch submission, after all -- it needs user interface review, a
review of the communication protocol, tests, code-level review, etc.

O.k. so we should discuss all PgLogical things here and not on Github? I
am just trying to figure out what the proper mode here is. I don't think
anybody wants us to double up efforts.

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, May 16, 2016 at 06:20:34PM -0700, Joshua D. Drake wrote:

On 05/16/2016 05:52 PM, David Fetter wrote:

Folks,

This path would, of course, run either locally or across a
network, and be testable in both cases. There would be a
downgrade path, namely switching origin nodes.

What say?

What happens when the database is 5TB in size and you only have
500GB available but that 500GB won't exhaust before the 18 month
lease expiry?

We cannot prepare for every eventuality.

The downside risk of a binary upgrade in the type of case you describe
is in no conceivable instance better than "rent or borrow another
server with more storage attached and replicate to it."

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joshua D. Drake wrote:

On 05/16/2016 06:32 PM, Alvaro Herrera wrote:

Joshua D. Drake wrote:

Alvaro,

Thank you for bringing this to light. Is there a contributor FAQ for
PgLogical so that people can help?

Hmm, I don't think there's any contributor FAQ. It's supposed to be a
regular patch submission, after all -- it needs user interface review, a
review of the communication protocol, tests, code-level review, etc.

O.k. so we should discuss all PgLogical things here and not on Github? I am
just trying to figure out what the proper mode here is. I don't think
anybody wants us to double up efforts.

As far as I am concerned, by all means ignore Github and discuss issues
in pgsql-hackers. Github is being used only because it provides a
convenient Git mirror, which is said to be easier to use than attaching
huge patches back and forth. I think it may be more convenient also to
keep track of issues people have reported so that they can be marked as
fixed in commit messages, etc.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, May 16, 2016 at 9:22 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

David Fetter wrote:

As a relatively (to our users) minor course correction, I would like
to propose the following:

- Develop a logical upgrade path as a part of the (Yay! Sexy!) logical
replication that's already in large part built.

This path would, of course, run either locally or across a network,
and be testable in both cases.

This is one use case that pglogical intends to fulfill. If you're able
to contribute to that project, I'm sure many would appreciate it. Right
now the hottest question seems to be: is this something that should be
an extension, or should it be part of core with its own set of DDL etc?
The current patch is geared towards the former, so if the community at
large prefers to have it as the latter and would oppose the former, now
is the time to speak up so that the course can be corrected.

There was an unconference session on this topic at PGCon and quite a
number of people there stated that they found DDL to be an ease-of-use
feature and wanted to have it.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, May 16, 2016 at 8:52 PM, David Fetter <david@fetter.org> wrote:

In light of the above, it is perfectly reasonable to require, at least
temporarily, setting up duplicate storage, or another node.

I am aware that some cases exist where this is not possible, but I
don't think we should twist ourselves into pretzels to accommodate a
tiny minority of our users, which my experience in the field leads me
to believe is the case.

So, on the one hand, I agree that logical replication is a great way
to facilitate major version upgrades. On the other hand, I think it's
completely wrong to suppose that only a tiny minority of people can't
use it. In some cases, hardware availability is definitely an issue.
But even when people have the hardware, being able to cleanly do a
cutover from one master to another is not necessarily something people
are set up to do. Getting that to work well requires more brainpower
than many users are willing to give to their database. A lot of
people want to just shut the database down, upgrade it, and start it
back up.

pg_upgrade does that, kinda. I'd like to have something better, but
in the absence of that, I think it's quite wrong to think about
deprecating it, even if we had logical replication fully integrated
into core today. Which we by no means do.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 7 July 2016 at 21:01, Robert Haas <robertmhaas@gmail.com> wrote:

On Mon, May 16, 2016 at 9:22 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

David Fetter wrote:

As a relatively (to our users) minor course correction, I would like
to propose the following:

- Develop a logical upgrade path as a part of the (Yay! Sexy!) logical
replication that's already in large part built.

This path would, of course, run either locally or across a network,
and be testable in both cases.

This is one use case that pglogical intends to fulfill. If you're able
to contribute to that project, I'm sure many would appreciate it. Right
now the hottest question seems to be: is this something that should be
an extension, or should it be part of core with its own set of DDL etc?
The current patch is geared towards the former, so if the community at
large prefers to have it as the latter and would oppose the former, now
is the time to speak up so that the course can be corrected.

There was an unconference session on this topic at PGCon and quite a
number of people there stated that they found DDL to be an ease-of-use
feature and wanted to have it.

Yes, I ran the unconference session. It was a shame you weren't able to
stay for the whole discussion.

We all agreed that an in-core solution was desirable, if only for wider
adoption.

About half the people wanted DDL and about half the people didn't. When we
discussed why we wanted DDL there wasn't any answers apart from the thought
that we want to be able to backup the replication configurations, which
seemed to be possible with or without DDL. Any such backup would need to be
easily removed from the objects themselves, to avoid external dependencies
on making recovery work.

Chris Browne finally summed it up by saying we could wait on having DDL
until some time later, once we've decided on things like how we configure
it, how we secure it and what/how to store it in the catalog. "We could
probably live without DDL in the first version."

Personally, I'm in the group of people that don't see the need for DDL.
There are already many successful features that don't utilize DDL, such as
backup, advisory locks and some features that use DDL that don't really
need to such as LISTEN/NOTIFY, full text search etc.. Also note that both
Oracle and SQLServer have moved away from DDL in favour of function APIs,
most NoSQL databases and almost all languages prefer functional interfaces
over parsed text languages, so I don't see a huge industry revival for DDL
as means of specifying things.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 7 July 2016 at 21:10, Robert Haas <robertmhaas@gmail.com> wrote:

pg_upgrade does that, kinda. I'd like to have something better, but
in the absence of that, I think it's quite wrong to think about
deprecating it, even if we had logical replication fully integrated
into core today. Which we by no means do.

I don't see any problem with extending pg_upgrade to use logical
replication features under the covers.

It seems very smooth to be able to just say

pg_upgrade --online

and then specify whatever other parameters that requires.

It would be much easier to separate out that as a use-case so we can be
sure we get that in 10.0, even if nothing else lands.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 07/07/2016 01:10 PM, Robert Haas wrote:

On Mon, May 16, 2016 at 8:52 PM, David Fetter <david@fetter.org> wrote:

In light of the above, it is perfectly reasonable to require, at least
temporarily, setting up duplicate storage, or another node.

pg_upgrade does that, kinda. I'd like to have something better, but
in the absence of that, I think it's quite wrong to think about
deprecating it, even if we had logical replication fully integrated
into core today. Which we by no means do.

I would much rather see more brain power put into pg_upgrade or in place
upgrades than logical replication (as a upgrade solution).

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 8 July 2016 at 00:48, Joshua D. Drake <jd@commandprompt.com> wrote:

On 07/07/2016 01:10 PM, Robert Haas wrote:

On Mon, May 16, 2016 at 8:52 PM, David Fetter <david@fetter.org> wrote:

In light of the above, it is perfectly reasonable to require, at least
temporarily, setting up duplicate storage, or another node.

pg_upgrade does that, kinda. I'd like to have something better, but

in the absence of that, I think it's quite wrong to think about
deprecating it, even if we had logical replication fully integrated
into core today. Which we by no means do.

I would much rather see more brain power put into pg_upgrade or in place
upgrades than logical replication (as a upgrade solution).

Why is that?

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 07/07/2016 05:14 PM, Simon Riggs wrote:

I would much rather see more brain power put into pg_upgrade or in
place upgrades than logical replication (as a upgrade solution).

Why is that?

First, let me state that I don't have a problem with logical replication
as an upgrade solution. I have used one form or another many times. I
have also used pg_upgrade and will use pg_upgrade every single time I
can over replication (even pg_logical which is reasonably simple) if I
can. *KISS* is the mantra.

I certainly think logical replication has an absolute place (especially
if upgrading from something like 9.2 -> 9.5). I just don't think it is
as useful (generally) as a solid pg_upgrade or in-place upgrade solution.

We have had logical replication as a solution for over a decade. First
there was slony then londiste and then others. They all suffered from
various issues and limitations.

* Horrible overhead
* Long running transaction
* Need for lots of extra space

It is true that something like pg_logical doesn't suffer from those
three things but it does suffer from others:

* No DDL - Agreed, not "required" but certainly a very nice feature.

* Lack of simplicity

Users, like simple. It is one of the key reasons there is a migration to
the cloud, simplicity. Everything from scaling, to pricing, to
provisioning etc...

If I take a step back and say to myself, "What would *really* rock in
terms of PostgreSQL upgrades?" The answer is pretty simple:

apt-get update; apt-get upgrade;
service postgresql upgrade;

Which would pass a flag to "insert technology here" that started
PostgreSQL in a mode that told it, "Hey, you are going to need to check
a few things and probably modify a few things before you enter "ready
for transactions"".

I am fully aware that what I am saying is not easy. There are a whole
ton of issues (what if we are replicating to a slave?).

Anyway, that's why. I am by far more a consultant than an engineer now
and I can only relay what I run into when I speak either at conferences
or clients.

Sincerely,

JD

--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 8 July 2016 at 01:47, Joshua D. Drake <jd@commandprompt.com> wrote:

It is true that something like pg_logical doesn't suffer from those three
things but it does suffer from others:

* No DDL - Agreed, not "required" but certainly a very nice
feature.

* Lack of simplicity

Users, like simple. It is one of the key reasons there is a migration to
the cloud, simplicity. Everything from scaling, to pricing, to provisioning
etc...

Well, you can't run DDL during pg_upgrade either. I've never seen a
solution that supported that, and if it did, it would certainly violate the
"simple" rule you advocate.

Simplicity is key, I agree. But that's just a user interface feature, not a
comment on what's underneath the covers. pg_upgrade is not simple and is
never likely to be so, under the covers.

Anyway, I'm cool if you don't want to use it, for while or never. Options
are good.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 8 July 2016 at 01:47, Joshua D. Drake <jd@commandprompt.com> wrote:

* Long running transaction

And of course you can't run any transactions at all during pg_upgrade, not
just long running ones.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Thu, Jul 7, 2016 at 7:15 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Yes, I ran the unconference session. It was a shame you weren't able to stay
for the whole discussion.

I thought I sat through, at least, most of it, but you barely gave
anyone else a chance to talk, which kind of misses the point of an
unconference. The portion which I attended was not about how to move
the development of the feature forward, but just involved describing
it. I thought it was a shame that the time wasn't used better.

We all agreed that an in-core solution was desirable, if only for wider
adoption.

Yep.

About half the people wanted DDL and about half the people didn't. When we
discussed why we wanted DDL there wasn't any answers apart from the thought
that we want to be able to backup the replication configurations, which
seemed to be possible with or without DDL. Any such backup would need to be
easily removed from the objects themselves, to avoid external dependencies
on making recovery work.

I really don't think that's accurate. There might have been 50% of
people who thought that not having DDL was acceptable, but I think
there were very few people who found it preferable.

Chris Browne finally summed it up by saying we could wait on having DDL
until some time later, once we've decided on things like how we configure
it, how we secure it and what/how to store it in the catalog. "We could
probably live without DDL in the first version."

Right. In other words, DDL would be desirable, but he'd be willing to
live without it if that somehow made things easier. But it really
doesn't. Adding new DDL commands is not particularly difficult.

Personally, I'm in the group of people that don't see the need for DDL.
There are already many successful features that don't utilize DDL, such as
backup, advisory locks and some features that use DDL that don't really need
to such as LISTEN/NOTIFY, full text search etc.. Also note that both Oracle
and SQLServer have moved away from DDL in favour of function APIs, most
NoSQL databases and almost all languages prefer functional interfaces over
parsed text languages, so I don't see a huge industry revival for DDL as
means of specifying things.

DDL is our standard way of getting things into the system catalogs.
We have no system catalog metadata that is intended to be populated by
any means other than DDL. If you want to add a column to a table, you
say ALTER TABLE .. ADD COLUMN. If you want to add a column to an
extension, you say ALTER EXTENSION .. ADD TABLE. If you want to add
an option to a foreign table, you say ALTER FOREIGN TABLE .. OPTIONS
(ADD ..). Therefore, I think it is entirely reasonable and obviously
consistent with existing practice that if you want to add a table to a
replication set, you should write ALTER REPLICATION SET .. ADD TABLE.
I don't understand why logical replication should be the one feature
that departs from the way that all of our other features work. Sure,
we have other features that do not involve DDL, but (1) one of your
examples is full text search, which of course does have DDL, and was
moved from an interface that did not involve DDL to one that did
because the latter is better and (2) your other examples don't involve
defining catalog contents, which makes them apples-to-oranges
comparisons.

The burden of proof isn't on me to demonstrate why this feature "needs
DDL"; it's on you to explain why replication-related operations that
establish persistent database state don't need to behave just like all
other commands. Really, where this jumped the shark for me is when
you argued that this stuff didn't even need pg_dump support. Come on.
This feature doesn't get a pass from handling all of the things that
every existing similar feature needs to deal with.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 8 July 2016 at 02:41, Robert Haas <robertmhaas@gmail.com> wrote:

On Thu, Jul 7, 2016 at 7:15 PM, Simon Riggs <simon@2ndquadrant.com> wrote:

Yes, I ran the unconference session. It was a shame you weren't able to

stay

for the whole discussion.

I thought I sat through, at least, most of it, but you barely gave
anyone else a chance to talk, which kind of misses the point of an
unconference. The portion which I attended was not about how to move
the development of the feature forward, but just involved describing
it. I thought it was a shame that the time wasn't used better.

I think the problem was that I gave everybody an even shot at commenting,
rather than focusing on a few key developers.

There were twenty people actively involved in that discussion.

We all agreed that an in-core solution was desirable, if only for wider
adoption.

Yep.

About half the people wanted DDL and about half the people didn't. When

we

discussed why we wanted DDL there wasn't any answers apart from the

thought

that we want to be able to backup the replication configurations, which
seemed to be possible with or without DDL. Any such backup would need to

be

easily removed from the objects themselves, to avoid external

dependencies

on making recovery work.

I really don't think that's accurate. There might have been 50% of
people who thought that not having DDL was acceptable, but I think
there were very few people who found it preferable.

Without being in the room, its kinda hard for you to know, right?

Chris Browne finally summed it up by saying we could wait on having DDL
until some time later, once we've decided on things like how we configure
it, how we secure it and what/how to store it in the catalog. "We could
probably live without DDL in the first version."

Right. In other words, DDL would be desirable, but he'd be willing to
live without it if that somehow made things easier. But it really
doesn't. Adding new DDL commands is not particularly difficult.

Personally, I'm in the group of people that don't see the need for DDL.

The burden of proof isn't on me to demonstrate why this feature "needs
DDL"; it's on you to explain why replication-related operations that
establish persistent database state don't need to behave just like all
other commands. Really, where this jumped the shark for me is when
you argued that this stuff didn't even need pg_dump support. Come on.
This feature doesn't get a pass from handling all of the things that
every existing similar feature needs to deal with.

I don't agree, not least because I wasn't the only one saying it.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 8 July 2016 at 02:41, Robert Haas <robertmhaas@gmail.com> wrote:

Personally, I'm in the group of people that don't see the need for DDL.
There are already many successful features that don't utilize DDL, such

as

backup, advisory locks and some features that use DDL that don't really

need

to such as LISTEN/NOTIFY, full text search etc.. Also note that both

Oracle

and SQLServer have moved away from DDL in favour of function APIs, most
NoSQL databases and almost all languages prefer functional interfaces

over

parsed text languages, so I don't see a huge industry revival for DDL as
means of specifying things.

DDL is our standard way of getting things into the system catalogs.
We have no system catalog metadata that is intended to be populated by
any means other than DDL. If you want to add a column to a table, you
say ALTER TABLE .. ADD COLUMN. If you want to add a column to an
extension, you say ALTER EXTENSION .. ADD TABLE. If you want to add
an option to a foreign table, you say ALTER FOREIGN TABLE .. OPTIONS
(ADD ..). Therefore, I think it is entirely reasonable and obviously
consistent with existing practice that if you want to add a table to a
replication set, you should write ALTER REPLICATION SET .. ADD TABLE.
I don't understand why logical replication should be the one feature
that departs from the way that all of our other features work. Sure,
we have other features that do not involve DDL, but (1) one of your
examples is full text search, which of course does have DDL, and was
moved from an interface that did not involve DDL to one that did
because the latter is better and (2) your other examples don't involve
defining catalog contents, which makes them apples-to-oranges
comparisons.

pg_am has existed for decades without supporting DDL and we have gone to
great lengths over many years to allow catalog tables to be
inserted/updated/deleted by normal SQL rather than DDL, so not all catalog
access is via DDL. One of my examples was full text search and it does have
DDL, but that was an anti-example; all the feedback I have is that it was
much easier to use before it had DDL and that forcing it to use DDL pretty
much killed it for most users.

Anyway, backups and replication slots don't use DDL because they need to
work on standbys. So if you are arguing in favour of forcing logical
replication to never work on standbys, I'm interested in why that
restriction is useful and sensible, especially since we already agreed that
a failover mechanism for use of logical replication on standbys was
desirable. It seems likely that we're discussing this at too high a level
and that we each see things the other does not.

The burden of proof isn't on me to demonstrate why this feature "needs
DDL"; it's on you to explain why replication-related operations that
establish persistent database state don't need to behave just like all
other commands. Really, where this jumped the shark for me is when
you argued that this stuff didn't even need pg_dump support. Come on.
This feature doesn't get a pass from handling all of the things that
every existing similar feature needs to deal with.

As I already said, I accept that there needs to be some way to backup
replication config; the meeting continued after you left.

I note also that replication slots aren't backed up by pg_dump; I see
analogy here and think that at least some parts of logical replication will
be similar and not require DDL at all, just as slots do not.

pg_dump support doesn't require DDL, in any case, nor is it certain yet
that pg_dump is the right utility for backup.

The main point I see is that the user interface mechanisms have very little
to do with DDL or not. Having a command called ALTER REPLICATION SLOT or a
function called pg_alter_replication_slot() makes little real difference to
a user.

We have much to discuss in terms of security, the way it should work and
what options to support and a sidetrack into syntax isn't warranted at this
early stage. Please lets discuss those important things first, then return
to whether DDL makes sense or not; it may do, or may not, or more likely
which parts of it need DDL and which do not.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services