Re: [HACKERS] Logical replication and multimaster

Oops,

Looking at my old message from 2015 on this subject, it was Magnus who
pish-poshed it, and Page who liked it. Don't want to throw shaded at the
wrong person ;)
--
Jon Erdman (aka StuckMojo)
PostgreSQL Zealot

On 10/5/23 12:14 AM, Jon Erdman wrote:
>
> Well,
>
> Given my earlier message about Apple wanting to pay me for writing
> patches now, maybe I can revisit this idea.
>
> For background: I brought up the idea of an FDW that could read custom
> dump files and expose them as tables so that you could grab just a
> single record (or of course more) from a custom dump file without having
> to load the whole thing up, if you were stuck reaching into a backup to
> get at accidentally deleted tables, rows, etc.. The stopper, which was
> communicated to me by Tom at the following pgcon was that the code for
> parsing custom dumps is duplicated in pg_dump only, and would need to be
> duplicated into the server for the FDW, or broken out into a library.
>
> And for posterity, Dave Page said that was a stupid idea, while Magnus
> said that it sounded useful. And IIRC Bruce and Robert H said it was
> doable, just a good deal of work on the refactor needed.
>
> This convo went down at the Amsterdam conf where I spoke about using
> writeable LVM snapshots to expose each developer a copy of prod to
> noodle on, without having to actually make a full copy for each dev.
>
> Added trivia: I gave the talk with a can of Heineken in my hand at the
> podium, and my lightning talk had the work F(&king Cool in the title ;)
>
> That was also when I bought my plush Slony which was supposedly the very
> last one. (turns out they made more)
> --
> Jon Erdman (aka StuckMojo)
>     PostgreSQL Zealot
>
> On 12/15/15 9:48 PM, Jim Nasby wrote:
>> On 12/13/15 7:37 AM, David Fetter wrote:
>>> As I understand it, pushing these into a library has been proposed but
>>> not rejected.  That it hasn't happened yet is mostly about the lack of
>>> tuits (the round ones) to rewrite the functionality as libraries and
>>> refactor pg_dump/pg_restore to use only calls to same.  As usual, it's
>>> less about writing the code and more about the enormous amount of
>>> testing any such a refactor would entail.
>>
>> My understanding as well. IIRC Jon Erdman brought this question up a
>> couple years ago and the response was "It'd probably be accepted, it's
>> just that no one has done the work."
>>
>>> I believe that refactoring much of pg_dump's functionality for the
>>> current version of the server into SQL-accessible functions and making
>>> pg_dump use only those functions is achievable with available
>>> resources.
>>>
>>> Such a refactor need not be all-or-nothing.  For example, the
>>> dependency resolution stuff is a first step that appears to be worth
>>> doing by itself even if the effort then pauses, possibly for some
>>> time.
>>
>> If someone wanted to spend time on this, I suspect it'd be worth
>> looking at how bad some of the backward compatibility issues would be
>> if done in the server. Maybe they wouldn't be that bad. I suspect the
>> audience for this code would be much larger if it was in the server as
>> opposed to a C library.