4 ms·
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 w
by pweissbrod 4y ago
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?
- GordonS 4y agoIt 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 4y agobeware of subscribers being down. wal file will fill-up and then you’ll loose messages.
- GordonS 4y agoWon't it just... write more WAL files?
- jerrysievert 4y agoyes, until you run out of disk - it's happy to write as much as you can handle. but, disk isn't usually infinite.
- GordonS 4y agoWell 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 4y agoI mean running out of disk is a danger for any persistence, that's not specific to using WAL
- oa335 4y agoIf 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.