PostgreSQL log tail: an old and a new log file sharing one mtime second are not ordered by recency (newest pick has no tiebreak) #4723

Found while working on #4719.

pg_ls_logdir() reports modification as a stat mtime with one-second resolution. The six tail CTEs in PerformanceMonitor.Collectors/PgServerLogTail.cs (TailCteSql, TailCteBinarySql, and the csvlog and jsonlog twins) pick the newest file with ORDER BY modification DESC LIMIT 1 and no tiebreak.

After a rotation (a size rotation at log_rotation_size, or pg_rotate_logfile()), the old file's last write and the new file's last write can fall in the same second. Then both files carry the same mtime and the pick is not decided by recency.

Measured on a local PostgreSQL 18.6 target with the CI stderr settings: after a size rotation in the middle of a 6500-record burst, postgresql-2026-09-29_060408.log (10,488,576 bytes) and the new postgresql-2026-09-29_060412.log (263,424 bytes) both listed modification = 06:04:12. The CI failures of ALogThatGrewPastTheWindow stage a marker that names the OLD 10.49 MB file as the newest.

Effect: the new file's lines are not collected until something writes to it in a later second. On a busy server that is a delay of one cycle. On a quiet one it has no bound.

Fix to consider: add name DESC after modification DESC in the six constants (the default log_filename embeds a sortable timestamp; PgDeadlocksResumeLiveTests already orders modification DESC, name DESC), or read current_logfiles. It changes six pinned constants, so the byte-for-byte pins in PgServerLogTailBinaryRouteTests, PgLogEventsPipelineTests and TsqlConventionGuardTests move with it. A live test can force the tie by writing a line, calling pg_rotate_logfile() and writing again inside the same second of the server clock.