Addition of pgaudit.log_rotation_size option

[Nd1002]

Good afternoon! When using 'pgauditlogtofile', there was a need to rotate the file based on its size. Adding log file rotation based on the size set in pgaudit.log_rotation_size. The unit of measurement is the same as in PostgreSQL's standard logging. pgaudit.log_rotation_size is only set by the user; otherwise, its functionality will be disabled. This feature was tested in various scenarios, including with pgbench. When enabled, microseconds are added to the log file name (assuming the standard 'pgaudit-%Y-%m-%d_%H%M%S.log' template), changing it to 'pgaudit-%Y-%m-%d_%H%M%S-%ms.log', this is needed when pgaudit.log_rotation_size is set to a small value.

I would appreciate your corrections and suggestions!

[fmbiete]

Thank you for the contribution! I like the idea of having the option of doing a rotation by size. Some thoughts: The filename could be something like: <pgaudit.log_filename>[.N] where N is > 0 So, if I select rotate by day and rotate after 10GB, I would have

pgaudit-20240815.log <- this always the active
pgaudit-20240815.log.1 <- first rotation after 10GB
pgaudit-20240815.log.2 <- second rotation after 20GB
pgaudit-20240815.log.3 <- third rotation after 30GB

that would require some file rename

[stackane]

@Nd1002 any plans from your side to adjust and get this merged?

If not, I could might find some time to jump in, although I am pretty new to this repo.

[fmbiete]

@Nd1002 any plans from your side to adjust and get this merged?

If not, I could might find some time to jump in, although I am pretty new to this repo.

Any size rotation logic should be lockless (or maybe using some atomic type and sacrificing rotating around that size and not at the exact size). If to track the current size we need to synchronize all the backends it will have a noticeable performance impact