On 10/28/21 3:08 PM, Bruce Momjian wrote:
> On Thu, Oct 28, 2021 at 02:23:39PM -0500, Ron wrote:
>> On 10/28/21 2:06 PM, Adrian Klaver wrote:
>>> On 10/28/21 11:48, Ron wrote:
>>>> On 10/28/21 1:00 PM, Adrian Klaver wrote:
>>>>> On 10/28/21 10:51, Ron wrote:
>>>>>
>>>> Not doable in Postgresql because WAL files are global to cluster.
>>>> I've read multiple times that will not be changed.
>>> Yet somehow logical replication does it:
>>>
>>> https://www.postgresql.org/docs/14/logical-replication-architecture.html
>>>
>>> "
>>> Logical replication is built with an architecture similar to physical
>>> streaming replication (see Section 27.2.5). It is implemented by
>>> “walsender” and “apply” processes. The walsender process starts logical
>>> decoding (described in Chapter 49) of the WAL and loads the
>> Scans the (global) WAL data for only the that portion from the relevant
>> database?
>>
>> If so, definitely not the same as having per-database WAL files.
>>
>> Just as importantly, replication is not, and never will be, a substitute for
>> backups.
> Uh, for replication slots, we don't send the entire WAL stream to the
> subscriber:
I meant scanning at the source.
> https://www.postgresql.org/docs/14/logical-replication.html
>
> Logical replication of a table typically starts with taking a snapshot
> of the data on the publisher database and copying that to the subscriber.
> Once that is done, the changes on the publisher are sent to the subscriber
> as they occur in real-time. The subscriber applies the data in the same
> order as the publisher so that transactional consistency is guaranteed for
> publications within a single subscription. This method of data replication
> is sometimes referred to as transactional replication.
It's still a bunch of transaction logs, whereas differential and incremental
backups only backup the changed pages, no matter how many times they've been
changed.
That's a serious reduction in disk space, and time to apply them.
--
Angular momentum makes the world go 'round.
