[pweissbrod]

How would this work from a fault tolerance perspective? For example the listening application happens to be offline but the database is inserting records. How would the application catch up?

[oa335]

If the listener is offline, the Postgres will see that a subscriber is behind and mark more of internal data as needing to be retained - this will keep certain maintenance tasks from being run (i.e. VACUUM). If VACUUM is not run for long enough, it will cause a catastrophic failure in your DB.

The application can catch up when restarted, if it retains the last WAL position. When it restarts, can asks Postgres to start replaying from that point.

[GordonS]

It would catch up by reading the WAL files when it restarted - using this method, the WAL files will remain on disk until they've been read.

[codaphiliac]

beware of subscribers being down. wal file will fill-up and then you’ll loose messages.

[GordonS]

Won't it just... write more WAL files?

[jerrysievert]

yes, until you run out of disk - it's happy to write as much as you can handle.

but, disk isn't usually infinite.

[GordonS]

Well of course, but I don't feel like this is a noteworthy limitation here; it applies to any form of queue that persists messages.

I had imagined the GP might have been insinuating something like: a configurable number of WAL files would be written, then they'll be overwritten once all full.

[skrtskrt]

I mean running out of disk is a danger for any persistence, that's not specific to using WAL