Problem in log parser logic

[0xgouda]

Describe the bug
The current log parser implementation starts reading from offset zero on opening new log file, with configs like log_truncate_on_rotation = off and log_file_name = postgresql-%H, the files will be reused and not truncated, hence pgwatch will read all of them from the beginning each time they become the latest modified file.

Expected behavior
pgwatch should start from the offset it was it the last time it saw the file.

[SumitKumar-17]

@0xgouda are you working on it ,I’d like to work on this feature.

[0xgouda]

@0xgouda are you working on it ,I’d like to work on this feature.

Hi Sumit, this still depends on #1072 getting merged. After that, you are welcome to work on it.

[pashagolub]

We need to remember that pgwatch shouldn't be responsible for the user's choices. If user wants that kind of log rotation, they don't have the log parsing functionality. That simple.
Of course, if it's trivial to fix, let's do it! But we should always remember that pgwatch is a monitoring solution, not a log parsing solution.

If we want to enhance the logging possibilities it's better rely on existing software, e.g. pgbouncer, and use it as a source.

[0xgouda]

Hi @SumitKumar-17, #1072 is merged. are you still interested in this one?

If yes, please make sure that we have some sort of threshold for the map (or whatever you use) that saves the offsets.
A 1-year running pgwatch instance monitoring a database with the default postgresql-%Y-%m-%d_%H%M%S.log log file name and saving all these filename entries can create a significant memory overhead