On Wed, Mar 1, 2023 at 8:18 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Wed, Mar 1, 2023 at 12:51 AM Hayato Kuroda (Fujitsu) > <kuroda.hay...@fujitsu.com> wrote: > > Thinking of side effects of this feature (no matter where we delay > applying the changes), on the publisher, vacuum cannot collect garbage > and WAL cannot be recycled. Is that okay in the first place? The point > is that the subscription setting affects the publisher. That is, > min_send_delay is specified on the subscriber but the symptoms that > could ultimately lead to a server crash appear on the publisher, which > sounds dangerous to me. > > Imagine a service or system like where there is a publication server > and it's somewhat exposed so that a user (or a subsystem) arbitrarily > can create a subscriber to replicate a subset of the data. A malicious > user can have the publisher crash by creating a subscription with, > say, min_send_delay = 20d. max_slot_wal_keep_size helps this situation > but it's -1 by default. >
By publisher crash, do you mean due to the disk full situation, it can lead the publisher to stop/panic? Won't a malicious user can block the replication in other ways as well and let the publisher stall (or crash the publisher) even without setting min_send_delay? Basically, one needs to either disable the subscription or create a constraint-violating row in the table to make that happen. If the system is exposed for arbitrarily allowing the creation of a subscription then a malicious user can create a subscription similar to one existing subscription and block the replication due to constraint violations. I don't think it would be so easy to bypass the current system that a malicious user will be allowed to create/alter subscriptions arbitrarily. Similarly, if there is a network issue (unreachable or slow), one will see similar symptoms. I think retention of data and WAL on publisher do rely on acknowledgment from subscribers and delay in that due to any reason can lead to the symptoms you describe above. We have documented at least one such case already where during Drop Subscription, if the network is not reachable then also, a similar problem can happen and users need to be careful about it [1]. [1] - https://www.postgresql.org/docs/devel/logical-replication-subscription.html -- With Regards, Amit Kapila.
