Handle read-only filesystem gracefully about collector HOT 1 OPEN

Thanks for bringing this up - overall I would say we do not aim to make the collector work with a read-only file system at this point. For context, separate from log files being written out temporarily, there is a state file that is used for restarts/reloads - whilst we could refactor how that works for reloads specifically (i.e. keep it in memory somehow), it'd cause some extra complexity.

Regarding not acknowledging Pub/Sub messages in error cases - we could avoid doing so if the log processing fails in the early stages, but there are failure cases later in the process too (mostly related to out of order log messages), and as you note crashes can occur too.

I think re-architecting this to not acknowledge the messages until they are saved (i.e. much later in the process than currently, at least 3 seconds later) will cause a different problem, as the Pub/Sub queue may back up noticeably when there is a high volume of log messages, and I recall that can cause issues with GCP's APIs - in my understanding they want readers to acknowledge messages quickly.

All that said, I'm open to a proposal how to handle things differently (preferably with a working PR), but its not a priority to do major rework here for us at this point. We may revise this in a future when we add more auditing (as in pg_audit) focused features to pganalyze.

from collector.