pgsql: Use fabsf() instead of Abs() or fabs() where appropriate
Use fabsf() instead of Abs() or fabs() where appropriate This function is new in C99. Reviewed-by: Zhang Mingli Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/4beb42b5-216b-bce8-d452-d924d5794c63%40enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e4c61bedcb791fe79fdc4e96a3a7ab59b0dbacaf Modified Files -- contrib/btree_gist/btree_float4.c | 2 +- contrib/intarray/_int_gist.c | 2 +- contrib/seg/seg.c | 5 +++-- src/backend/utils/adt/float.c | 2 +- 4 files changed, 6 insertions(+), 5 deletions(-)
pgsql: pgstat: Prevent stats reset from corrupting slotname by removing
pgstat: Prevent stats reset from corrupting slotname by removing slotname Previously PgStat_StatReplSlotEntry contained the slotname, which was mainly used when writing out the stats during shutdown, to identify the slot in the serialized data (at runtime the index in ReplicationSlotCtl->replication_slots is used, but that can change during a restart). Unfortunately the slotname was overwritten when the slot's stats were reset. That turned out to only cause "real" problems if the slot was active during the reset, triggering an assertion failure at the next pgstat_report_replslot(). In other paths the stats were re-initialized during pgstat_acquire_replslot(). Fix this by removing slotname from PgStat_StatReplSlotEntry. Instead we can get the slot's name from the slot itself. Besides fixing a bug, this also is architecturally cleaner (a name is not really statistics). This is safe because stats, for a slot removed while shut down, will not be restored at startup. In 15 the slotname is not removed, but renamed, to avoid changing the stats format. In master, bump PGSTAT_FILE_FORMAT_ID. This commit does not contain a test for the fix. I think this can only be tested by a tap test starting pg_recvlogical in the background and checking pg_recvlogical's output. That type of test is notoriously hard to be reliable, so committing it shortly before the release is wrapped seems like a bad idea. Reported-by: Jaime Casanova Author: Andres Freund Reviewed-by: Masahiko Sawada Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/YxfagaTXUNa9ggLb@ahch-to Backpatch: 15-, where the bug was introduced in 5891c7a8ed8f Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/06dbd619bfbfe03fefa7223838690d4012f874ad Modified Files -- src/backend/replication/slot.c | 28 ++ src/backend/utils/activity/pgstat.c | 2 +- src/backend/utils/activity/pgstat_replslot.c | 56 +--- src/include/pgstat.h | 3 +- src/include/replication/slot.h | 1 + src/include/utils/pgstat_internal.h | 5 ++- 6 files changed, 60 insertions(+), 35 deletions(-)
pgsql: pgstat: Prevent stats reset from corrupting slotname by removing
pgstat: Prevent stats reset from corrupting slotname by removing slotname Previously PgStat_StatReplSlotEntry contained the slotname, which was mainly used when writing out the stats during shutdown, to identify the slot in the serialized data (at runtime the index in ReplicationSlotCtl->replication_slots is used, but that can change during a restart). Unfortunately the slotname was overwritten when the slot's stats were reset. That turned out to only cause "real" problems if the slot was active during the reset, triggering an assertion failure at the next pgstat_report_replslot(). In other paths the stats were re-initialized during pgstat_acquire_replslot(). Fix this by removing slotname from PgStat_StatReplSlotEntry. Instead we can get the slot's name from the slot itself. Besides fixing a bug, this also is architecturally cleaner (a name is not really statistics). This is safe because stats, for a slot removed while shut down, will not be restored at startup. In 15 the slotname is not removed, but renamed, to avoid changing the stats format. In master, bump PGSTAT_FILE_FORMAT_ID. This commit does not contain a test for the fix. I think this can only be tested by a tap test starting pg_recvlogical in the background and checking pg_recvlogical's output. That type of test is notoriously hard to be reliable, so committing it shortly before the release is wrapped seems like a bad idea. Reported-by: Jaime Casanova Author: Andres Freund Reviewed-by: Masahiko Sawada Reviewed-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/YxfagaTXUNa9ggLb@ahch-to Backpatch: 15-, where the bug was introduced in 5891c7a8ed8f Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c3b5992b91c4b0d2c4f4eab0fb856f34854c129d Modified Files -- src/backend/replication/slot.c | 28 ++ src/backend/utils/activity/pgstat.c | 2 +- src/backend/utils/activity/pgstat_replslot.c | 56 +--- src/include/pgstat.h | 6 ++- src/include/replication/slot.h | 1 + src/include/utils/pgstat_internal.h | 5 ++- 6 files changed, 64 insertions(+), 34 deletions(-)
