To reproduce with a local PDB: {code:java}in psql: alter role pdb_test set lock_timeout=300; run: lein test :only puppetlabs.puppetdb.cli.services-test/regular-gc-drops-oldest-partitions-incrementally {code} This will cause the test to fail with: {code:java}21349 [pool-3-thread-3] ERROR puppetlabs.puppetdb.cli.services - Error while sweeping reports and resource events java.lang.NumberFormatException: For input string: "300ms" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.base/java.lang.Long.parseLong(Long.java:692) at java.base/java.lang.Long.parseLong(Long.java:817) at puppetlabs.puppetdb.scf.storage$prune_daily_partitions.invokeStatic(storage.clj:1571) ... {code} If there is a lock_timeout set for postgres or for the puppetdb/pe-puppetdb role it will cause partition GC to fail and cause partitions to build up until PDB is restarted or the lock_timeout is reset. If there isn't a lock_timeout set the query returns 0 which isn't a problem for Long/parseLong.
As a workaround resetting the lock_timeout should allow partition GC to succeed. For example: {code:java} alter role "pe-puppetdb" reset lock_timeout; {code} Will reset the lock_timeout on the pe-puppetdb role and should resolve the error seen above. Partition drops are still protected by a (5min default) lock_timeout which is defaulted and set via an env var [here|https://github.com/puppetlabs/puppetdb/blob/6.x/src/puppetlabs/puppetdb/scf/storage.clj#L1584-L1586].