Postgresql goes down due to "terminating connection due to administrator command"

Steps to reproduce
Deploy postgresql 14/edge on rev 239 with three units.
Model                        Controller                         Cloud/Region              Version  SLA          Timestamp
prod-repo-policy-compliance  juju-controller-35-production-ps6  k8s-prod-general/default  3.5.3    unsupported  08:07:59Z

App                       Version  Status  Scale  Charm                     Channel      Rev  Address        Exposed  Message
postgresql                14.12    active      3  postgresql-k8s            14/edge      239  <IP_ADDRESS>    no       Primary
repo-policy-compliance             active      1  repo-policy-compliance    latest/edge   17  <IP_ADDRESS>     no

Unit                         Workload  Agent  Address          Ports  Message
postgresql/0                 active    idle   <IP_ADDRESS>          Primary
postgresql/1*                active    idle   <IP_ADDRESS>
postgresql/2                 active    idle   <IP_ADDRESS>
repo-policy-compliance/0*    active    idle   <IP_ADDRESS>

Expected behavior
Postgreql is not going down.
Actual behavior

We received the Postgresql down alert on a production deployment with three units.
[[FIRING:2] (instance="prod-repo-policy-compliance_e3901794-73c7-43f0-85ae-5179a6dc1b16_postgresql_postgresql/1", job="juju_prod-repo-policy-compliance_e3901794_postgresql_prometheus_scrape-1_638a329e43b79c2385aeef8f96e0df8ed4864b1b4128b49c0b1215c36f0adff0", juju_charm="postgresql-k8s", juju_unit="postgresql/1", severity="critical")](http://alertmanager-0.alertmanager-endpoints.prod-cos-k8s-ps6-is-charms.svc.cluster.local:9093/#/alerts?receiver=mattermost-notifications)
Alert: Postgresql down (instance prod-repo-policy-compliance_e3901794-73c7-43f0-85ae-5179a6dc1b16_postgresql_postgresql/1) - critical

Description: Postgresql instance is down
  VALUE = 0
  LABELS = map[name:pg_up instance:prod-repo-policy-compliance_e3901794-73c7-43f0-85ae-5179a6dc1b16_postgresql_postgresql/1 job:juju_prod-repo-policy-compliance_e3901794_postgresql_prometheus_scrape-1_638a329e43b79c2385aeef8f96e0df8ed4864b1b4128b49c0b1215c36f0adff0 juju_application:postgresql juju_charm:postgresql-k8s juju_model:prod-repo-policy-compliance juju_model_uuid:e3901794-73c7-43f0-85ae-5179a6dc1b16 juju_unit:postgresql/1]

Details:
   • alertname: PostgresqlDown
   • instance: prod-repo-policy-compliance_e3901794-73c7-43f0-85ae-5179a6dc1b16_postgresql_postgresql/1
   • job: juju_prod-repo-policy-compliance_e3901794_postgresql_prometheus_scrape-1_638a329e43b79c2385aeef8f96e0df8ed4864b1b4128b49c0b1215c36f0adff0
   • juju_application: postgresql
   • juju_charm: postgresql-k8s
   • juju_model: prod-repo-policy-compliance
   • juju_model_uuid: e3901794-73c7-43f0-85ae-5179a6dc1b16
   • juju_unit: postgresql/1
   • severity: critical

Source:  http://prometheus-0.prometheus-endpoints.prod-cos-k8s-ps6-is-charms.svc.cluster.local:9090/prod-cos-k8s-ps6-is-charms-prometheus-0/graph?g0.expr=pg_up%7Bjuju_application%3D%22postgresql%22%2Cjuju_model%3D%22prod-repo-policy-compliance%22%2Cjuju_model_uuid%3D%22e3901794-73c7-43f0-85ae-5179a6dc1b16%22%7D+%3D%3D+0&g0.tab=1
Alert: Postgresql exporter error (instance prod-repo-policy-compliance_e3901794-73c7-43f0-85ae-5179a6dc1b16_postgresql_postgresql/1) - critical

Description: Postgresql exporter is showing errors. A query may be buggy in query.yaml
  VALUE = 1
  LABELS = map[name:pg_exporter_last_scrape_error instance:prod-repo-policy-compliance_e3901794-73c7-43f0-85ae-5179a6dc1b16_postgresql_postgresql/1 job:juju_prod-repo-policy-compliance_e3901794_postgresql_prometheus_scrape-1_638a329e43b79c2385aeef8f96e0df8ed4864b1b4128b49c0b1215c36f0adff0 juju_application:postgresql juju_charm:postgresql-k8s juju_model:prod-repo-policy-compliance juju_model_uuid:e3901794-73c7-43f0-85ae-5179a6dc1b16 juju_unit:postgresql/1]

Details:
   • alertname: PostgresqlExporterError
   • instance: prod-repo-policy-compliance_e3901794-73c7-43f0-85ae-5179a6dc1b16_postgresql_postgresql/1
   • job: juju_prod-repo-policy-compliance_e3901794_postgresql_prometheus_scrape-1_638a329e43b79c2385aeef8f96e0df8ed4864b1b4128b49c0b1215c36f0adff0
   • juju_application: postgresql
   • juju_charm: postgresql-k8s
   • juju_model: prod-repo-policy-compliance
   • juju_model_uuid: e3901794-73c7-43f0-85ae-5179a6dc1b16
   • juju_unit: postgresql/1
   • severity: critical

Source:  http://prometheus-0.prometheus-endpoints.prod-cos-k8s-ps6-is-charms.svc.cluster.local:9090/prod-cos-k8s-ps6-is-charms-prometheus-0/graph?g0.expr=pg_exporter_last_scrape_error%7Bjuju_application%3D%22postgresql%22%2Cjuju_model%3D%22prod-repo-policy-compliance%22%2Cjuju_model_uuid%3D%22e3901794-73c7-43f0-85ae-5179a6dc1b16%22%7D+%3E+0&g0.tab=1

Logs indicate that postgresql-1 was shutdown due to
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=12 LOG:  received fast shutdown request
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=13 LOG:  aborting any active transactions
2024-08-07 06:58:22 UTC [8888]: user=monitoring,db=postgres,app=[unknown],client=[local],line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8867]: user=monitoring,db=postgres,app=[unknown],client=[local],line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8769]: user=operator,db=postgres,app=Patroni,client=<IP_ADDRESS>,line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=14 LOG:  background worker "logical replication launcher" (PID 8783) exited with exit code 1
2024-08-07 06:58:22 UTC [8765]: user=,db=,app=,client=,line=5 LOG:  shutting down

It healed itself quite quickly.
Versions

Operating system:

Juju CLI:  3.5.3

Juju agent:  3.5.3

Charm revision: 239

microk8s:
Log output
juju debug log
unit-postgresql-0: 06:54:06 DEBUG unit.postgresql/0.juju-log ops 2.12.0 up and running.
unit-postgresql-0: 06:54:06 DEBUG unit.postgresql/0.juju-log Emitting Juju event update_status.
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:54:09 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-0: 06:54:09 INFO unit.postgresql/0.juju-log Kubernetes service 'postgresql' patched successfully
unit-postgresql-0: 06:54:09 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)
unit-postgresql-1: 06:54:24 DEBUG unit.postgresql/1.juju-log ops 2.12.0 up and running.
unit-postgresql-1: 06:54:24 DEBUG unit.postgresql/1.juju-log Emitting Juju event update_status.
unit-postgresql-1: 06:54:25 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 06:54:25 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-1: 06:54:25 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 06:54:25 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-1: 06:54:25 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 06:54:25 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-1: 06:54:25 INFO unit.postgresql/1.juju-log Kubernetes service 'postgresql' patched successfully
unit-postgresql-1: 06:54:25 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log ops 2.12.0 up and running.
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log Emitting Juju event update_status.
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log Starting new HTTP connection (1): postgresql-2.postgresql-endpoints:8008
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log http://postgresql-2.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log Starting new HTTP connection (1): postgresql-2.postgresql-endpoints:8008
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log http://postgresql-2.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log Starting new HTTP connection (1): postgresql-2.postgresql-endpoints:8008
unit-postgresql-2: 06:56:46 DEBUG unit.postgresql/2.juju-log http://postgresql-2.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-2: 06:56:47 DEBUG unit.postgresql/2.juju-log Starting new HTTP connection (1): postgresql-2.postgresql-endpoints:8008
unit-postgresql-2: 06:56:47 DEBUG unit.postgresql/2.juju-log http://postgresql-2.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-2: 06:56:47 DEBUG unit.postgresql/2.juju-log Starting new HTTP connection (1): postgresql-2.postgresql-endpoints:8008
unit-postgresql-2: 06:56:47 DEBUG unit.postgresql/2.juju-log http://postgresql-2.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-2: 06:56:47 DEBUG unit.postgresql/2.juju-log Starting new HTTP connection (1): postgresql-2.postgresql-endpoints:8008
unit-postgresql-2: 06:56:47 DEBUG unit.postgresql/2.juju-log http://postgresql-2.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-2: 06:56:47 INFO unit.postgresql/2.juju-log Kubernetes service 'postgresql' patched successfully
unit-postgresql-2: 06:56:47 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)
unit-postgresql-0: 06:59:40 DEBUG unit.postgresql/0.juju-log ops 2.12.0 up and running.
unit-postgresql-0: 06:59:40 DEBUG unit.postgresql/0.juju-log Emitting Juju event update_status.
unit-postgresql-0: 06:59:42 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:59:42 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-0: 06:59:42 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:59:42 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-0: 06:59:42 DEBUG unit.postgresql/0.juju-log Starting new HTTP connection (1): postgresql-0.postgresql-endpoints:8008
unit-postgresql-0: 06:59:42 DEBUG unit.postgresql/0.juju-log http://postgresql-0.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-0: 06:59:42 INFO unit.postgresql/0.juju-log Kubernetes service 'postgresql' patched successfully
unit-postgresql-0: 06:59:42 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log ops 2.12.0 up and running.
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log Emitting Juju event update_status.
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /cluster HTTP/1.1" 200 None
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log Starting new HTTP connection (1): postgresql-1.postgresql-endpoints:8008
unit-postgresql-1: 07:00:02 DEBUG unit.postgresql/1.juju-log http://postgresql-1.postgresql-endpoints:8008 "GET /health HTTP/1.1" 200 None
unit-postgresql-1: 07:00:02 INFO unit.postgresql/1.juju-log Kubernetes service 'postgresql' patched successfully
unit-postgresql-1: 07:00:03 INFO juju.worker.uniter.operation ran "update-status" hook (via hook dispatching script: dispatch)

postgresql log
root@postgresql-1:/# cat /var/log/postgresql/postgresql-3_0658.log
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=12 LOG:  received fast shutdown request
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=13 LOG:  aborting any active transactions
2024-08-07 06:58:22 UTC [8888]: user=monitoring,db=postgres,app=[unknown],client=[local],line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8867]: user=monitoring,db=postgres,app=[unknown],client=[local],line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8769]: user=operator,db=postgres,app=Patroni,client=<IP_ADDRESS>,line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=14 LOG:  background worker "logical replication launcher" (PID 8783) exited with exit code 1
2024-08-07 06:58:22 UTC [8765]: user=,db=,app=,client=,line=5 LOG:  shutting down
2024-08-07 06:58:22 UTC [8765]: user=,db=,app=,client=,line=6 LOG:  checkpoint starting: shutdown immediate
2024-08-07 06:58:23 UTC [8765]: user=,db=,app=,client=,line=7 LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.015 s, sync=0.001 s, total=0.242 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16382 kB, estimate=16382 kB
2024-08-07 06:58:23 UTC [17415]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is shutting down
2024-08-07 06:58:33 UTC [17419]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is shutting down
2024-08-07 06:58:33 UTC [17421]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is shutting down
2024-08-07 06:58:34 UTC [8758]: user=,db=,app=,client=,line=15 LOG:  database system is shut down
2024-08-07 06:58:35 UTC [17577]: user=,db=,app=,client=,line=3 LOG:  starting PostgreSQL 14.12 (Ubuntu 14.12-0ubuntu<IP_ADDRESS>) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
2024-08-07 06:58:35 UTC [17577]: user=,db=,app=,client=,line=4 LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2024-08-07 06:58:37 UTC [17577]: user=,db=,app=,client=,line=5 LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=1 LOG:  database system was shut down at 2024-08-07 06:58:23 UTC
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=2 WARNING:  specified neither primary_conninfo nor restore_command
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=3 HINT:  The database server will regularly poll the pg_wal subdirectory to check for files placed there.
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=4 LOG:  entering standby mode
2024-08-07 06:58:37 UTC [17583]: user=rewind,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is starting up
2024-08-07 06:58:37 UTC [17584]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is starting up
2024-08-07 06:58:37 UTC [17586]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is starting up
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=5 LOG:  consistent recovery state reached at 0/2C0000A0
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=6 LOG:  invalid record length at 0/2C0000A0: wanted 24, got 0
2024-08-07 06:58:37 UTC [17577]: user=,db=,app=,client=,line=6 LOG:  database system is ready to accept read-only connections
2024-08-07 06:58:38 UTC [17590]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  no pg_hba.conf entry for replication connection from host "<IP_ADDRESS>", user "replication", no encryption
2024-08-07 06:58:38 UTC [17590]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 DETAIL:  Client IP address resolved to "192-168-102-57.postgresql-replicas.prod-repo-policy-compliance.svc.cluster.local", forward lookup not checked.
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=3 LOG:  received replication command: START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 65
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=4 STATEMENT:  START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 65
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=3 LOG:  received replication command: START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 65
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=4 STATEMENT:  START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 65
2024-08-07 06:58:45 UTC [17597]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:45 UTC [17597]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17599]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17599]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=7 LOG:  received promote request
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=8 LOG:  redo is not required
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=9 LOG:  selected new timeline ID: 66
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=10 LOG:  archive recovery complete
2024-08-07 06:58:46 UTC [17587]: user=,db=,app=,client=,line=1 LOG:  checkpoint starting: force
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=5 LOG:  received replication command: TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=6 STATEMENT:  TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=5 LOG:  received replication command: TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=6 STATEMENT:  TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17577]: user=,db=,app=,client=,line=7 LOG:  database system is ready to accept connections
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=7 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=8 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=7 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=8 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=9 LOG:  received replication command: START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=10 STATEMENT:  START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=9 LOG:  received replication command: START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=10 STATEMENT:  START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17587]: user=,db=,app=,client=,line=2 LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.020 s, sync=0.003 s, total=0.067 s; sync files=2, longest=0.002 s, average=0.002 s; distance=0 kB, estimate=0 kB
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=8 LOG:  received SIGHUP, reloading configuration files
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=9 LOG:  parameter "timezone" changed to "Etc/UTC"
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=10 LOG:  parameter "TimeZone" changed to "UTC"
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=11 LOG:  parameter "synchronous_standby_names" changed to ""postgresql-2""
2024-08-07 06:58:47 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=11 LOG:  standby "postgresql-2" is now a synchronous standby with priority 1
2024-08-07 06:58:47 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=12 STATEMENT:  START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 66
2024-08-07 06:58:56 UTC [17577]: user=,db=,app=,client=,line=12 LOG:  received immediate shutdown request
2024-08-07 06:58:56 UTC [17577]: user=,db=,app=,client=,line=13 LOG:  database system is shut down
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=3 LOG:  starting PostgreSQL 14.12 (Ubuntu 14.12-0ubuntu<IP_ADDRESS>) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=4 LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=5 LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=1 LOG:  database system was interrupted; last known up at 2024-08-07 06:58:46 UTC
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=2 WARNING:  specified neither primary_conninfo nor restore_command
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=3 HINT:  The database server will regularly poll the pg_wal subdirectory to check for files placed there.
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=4 LOG:  entering standby mode
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=5 LOG:  database system was not properly shut down; automatic recovery in progress
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=6 LOG:  redo starts at 0/2C0000D0
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=7 LOG:  invalid record length at 0/2C000218: wanted 24, got 0
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=8 LOG:  consistent recovery state reached at 0/2C000218
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=6 LOG:  database system is ready to accept read-only connections
2024-08-07 06:58:59 UTC [17784]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:59 UTC [17784]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:59:00 UTC [17771]: user=,db=,app=,client=,line=7 LOG:  received SIGHUP, reloading configuration files
root@postgresql-1:/# cat /var/log/postgresql/postgresql-3_0656.log
root@postgresql-1:/# cat /var/log/postgresql/postgresql-3_0655.log
root@postgresql-1:/# cat /var/log/postgresql/postgresql-3_0658.log
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=12 LOG:  received fast shutdown request
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=13 LOG:  aborting any active transactions
2024-08-07 06:58:22 UTC [8888]: user=monitoring,db=postgres,app=[unknown],client=[local],line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8867]: user=monitoring,db=postgres,app=[unknown],client=[local],line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8769]: user=operator,db=postgres,app=Patroni,client=<IP_ADDRESS>,line=1 FATAL:  terminating connection due to administrator command
2024-08-07 06:58:22 UTC [8758]: user=,db=,app=,client=,line=14 LOG:  background worker "logical replication launcher" (PID 8783) exited with exit code 1
2024-08-07 06:58:22 UTC [8765]: user=,db=,app=,client=,line=5 LOG:  shutting down
2024-08-07 06:58:22 UTC [8765]: user=,db=,app=,client=,line=6 LOG:  checkpoint starting: shutdown immediate
2024-08-07 06:58:23 UTC [8765]: user=,db=,app=,client=,line=7 LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 WAL file(s) added, 0 removed, 2 recycled; write=0.015 s, sync=0.001 s, total=0.242 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16382 kB, estimate=16382 kB
2024-08-07 06:58:23 UTC [17415]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is shutting down
2024-08-07 06:58:33 UTC [17419]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is shutting down
2024-08-07 06:58:33 UTC [17421]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is shutting down
2024-08-07 06:58:34 UTC [8758]: user=,db=,app=,client=,line=15 LOG:  database system is shut down
2024-08-07 06:58:35 UTC [17577]: user=,db=,app=,client=,line=3 LOG:  starting PostgreSQL 14.12 (Ubuntu 14.12-0ubuntu<IP_ADDRESS>) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
2024-08-07 06:58:35 UTC [17577]: user=,db=,app=,client=,line=4 LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2024-08-07 06:58:37 UTC [17577]: user=,db=,app=,client=,line=5 LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=1 LOG:  database system was shut down at 2024-08-07 06:58:23 UTC
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=2 WARNING:  specified neither primary_conninfo nor restore_command
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=3 HINT:  The database server will regularly poll the pg_wal subdirectory to check for files placed there.
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=4 LOG:  entering standby mode
2024-08-07 06:58:37 UTC [17583]: user=rewind,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is starting up
2024-08-07 06:58:37 UTC [17584]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is starting up
2024-08-07 06:58:37 UTC [17586]: user=operator,db=postgres,app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  the database system is starting up
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=5 LOG:  consistent recovery state reached at 0/2C0000A0
2024-08-07 06:58:37 UTC [17582]: user=,db=,app=,client=,line=6 LOG:  invalid record length at 0/2C0000A0: wanted 24, got 0
2024-08-07 06:58:37 UTC [17577]: user=,db=,app=,client=,line=6 LOG:  database system is ready to accept read-only connections
2024-08-07 06:58:38 UTC [17590]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 FATAL:  no pg_hba.conf entry for replication connection from host "<IP_ADDRESS>", user "replication", no encryption
2024-08-07 06:58:38 UTC [17590]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 DETAIL:  Client IP address resolved to "192-168-102-57.postgresql-replicas.prod-repo-policy-compliance.svc.cluster.local", forward lookup not checked.
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=3 LOG:  received replication command: START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 65
2024-08-07 06:58:39 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=4 STATEMENT:  START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 65
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=3 LOG:  received replication command: START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 65
2024-08-07 06:58:43 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=4 STATEMENT:  START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 65
2024-08-07 06:58:45 UTC [17597]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:45 UTC [17597]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17599]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17599]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=7 LOG:  received promote request
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=8 LOG:  redo is not required
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=9 LOG:  selected new timeline ID: 66
2024-08-07 06:58:46 UTC [17582]: user=,db=,app=,client=,line=10 LOG:  archive recovery complete
2024-08-07 06:58:46 UTC [17587]: user=,db=,app=,client=,line=1 LOG:  checkpoint starting: force
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=5 LOG:  received replication command: TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=6 STATEMENT:  TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=5 LOG:  received replication command: TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=6 STATEMENT:  TIMELINE_HISTORY 66
2024-08-07 06:58:46 UTC [17577]: user=,db=,app=,client=,line=7 LOG:  database system is ready to accept connections
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=7 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=8 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=7 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=8 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=9 LOG:  received replication command: START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17594]: user=replication,db=[unknown],app=postgresql-0,client=<IP_ADDRESS>,line=10 STATEMENT:  START_REPLICATION SLOT "postgresql_0" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=9 LOG:  received replication command: START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=10 STATEMENT:  START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 66
2024-08-07 06:58:46 UTC [17587]: user=,db=,app=,client=,line=2 LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.020 s, sync=0.003 s, total=0.067 s; sync files=2, longest=0.002 s, average=0.002 s; distance=0 kB, estimate=0 kB
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=8 LOG:  received SIGHUP, reloading configuration files
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=9 LOG:  parameter "timezone" changed to "Etc/UTC"
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=10 LOG:  parameter "TimeZone" changed to "UTC"
2024-08-07 06:58:47 UTC [17577]: user=,db=,app=,client=,line=11 LOG:  parameter "synchronous_standby_names" changed to ""postgresql-2""
2024-08-07 06:58:47 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=11 LOG:  standby "postgresql-2" is now a synchronous standby with priority 1
2024-08-07 06:58:47 UTC [17593]: user=replication,db=[unknown],app=postgresql-2,client=<IP_ADDRESS>,line=12 STATEMENT:  START_REPLICATION SLOT "postgresql_2" 0/2C000000 TIMELINE 66
2024-08-07 06:58:56 UTC [17577]: user=,db=,app=,client=,line=12 LOG:  received immediate shutdown request
2024-08-07 06:58:56 UTC [17577]: user=,db=,app=,client=,line=13 LOG:  database system is shut down
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=3 LOG:  starting PostgreSQL 14.12 (Ubuntu 14.12-0ubuntu<IP_ADDRESS>) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64-bit
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=4 LOG:  listening on IPv4 address "<IP_ADDRESS>", port 5432
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=5 LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=1 LOG:  database system was interrupted; last known up at 2024-08-07 06:58:46 UTC
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=2 WARNING:  specified neither primary_conninfo nor restore_command
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=3 HINT:  The database server will regularly poll the pg_wal subdirectory to check for files placed there.
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=4 LOG:  entering standby mode
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=5 LOG:  database system was not properly shut down; automatic recovery in progress
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=6 LOG:  redo starts at 0/2C0000D0
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=7 LOG:  invalid record length at 0/2C000218: wanted 24, got 0
2024-08-07 06:58:59 UTC [17775]: user=,db=,app=,client=,line=8 LOG:  consistent recovery state reached at 0/2C000218
2024-08-07 06:58:59 UTC [17771]: user=,db=,app=,client=,line=6 LOG:  database system is ready to accept read-only connections
2024-08-07 06:58:59 UTC [17784]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=1 LOG:  received replication command: IDENTIFY_SYSTEM
2024-08-07 06:58:59 UTC [17784]: user=replication,db=[unknown],app=[unknown],client=<IP_ADDRESS>,line=2 STATEMENT:  IDENTIFY_SYSTEM
2024-08-07 06:59:00 UTC [17771]: user=,db=,app=,client=,line=7 LOG:  received SIGHUP, reloading configuration files

patroni log
root@postgresql-1:/# cat /var/log/postgresql/patroni.log.110
2024-08-07 07:02:09 UTC [16]: INFO: no action. I am (postgresql-1), a secondary, and following a leader (postgresql-0)
2024-08-07 07:02:19 UTC [16]: INFO: no action. I am (postgresql-1), a secondary, and following a leader (postgresql-0)
2024-08-07 07:02:29 UTC [16]: INFO: no action. I am (postgresql-1), a secondary, and following a leader (postgresql-0)
2024-08-07 07:02:39 UTC [16]: INFO: no action. I am (postgresql-1), a secondary, and following a leader (postgresql-0)
root@postgresql-1:/# cat /var/log/postgresql/patroni.log.120
2024-08-07 06:58:58 UTC [16]: WARNING: Retry got exception: connection problems
2024-08-07 06:58:58 UTC [16]: INFO: Lock owner: postgresql-0; I am postgresql-1
2024-08-07 06:58:58 UTC [16]: INFO: starting after demotion in progress
2024-08-07 06:58:58 UTC [16]: INFO: Lock owner: postgresql-0; I am postgresql-1
2024-08-07 06:58:58 UTC [16]: INFO: starting after demotion in progress
2024-08-07 06:58:58 UTC [16]: WARNING: Retry got exception: connection problems
2024-08-07 06:58:59 UTC [16]: INFO: Lock owner: postgresql-0; I am postgresql-1
root@postgresql-1:/# cat /var/log/postgresql/patroni.log.121
2024-08-07 06:58:56 UTC [16]: ERROR: failed to update leader lock
2024-08-07 06:58:56 UTC [16]: INFO: Demoting self (immediate-nolock)
2024-08-07 06:58:56 UTC [16]: INFO: demoted self because failed to update leader lock in DCS
2024-08-07 06:58:56 UTC [16]: INFO: Lock owner: None; I am postgresql-1
2024-08-07 06:58:56 UTC [16]: INFO: not healthy enough for leader race
2024-08-07 06:58:56 UTC [16]: INFO: starting after demotion in progress
2024-08-07 06:58:56 UTC [16]: INFO: closed patroni connection to the postgresql cluster
2024-08-07 06:58:57 UTC [16]: INFO: postmaster pid=17771
root@postgresql-1:/# cat /var/log/postgresql/patroni.log.122
2024-08-07 06:58:56 UTC [16]: ERROR: Unexpected error from Kubernetes API
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/patroni/dcs/kubernetes.py", line 1159, in _update_leader_with_retry
    return bool(self._patch_or_create(self.leader_path, annotations, resource_version, ips=ips, retry=_retry))
  File "/usr/lib/python3/dist-packages/patroni/dcs/kubernetes.py", line 1090, in _patch_or_create
    ret = retry(func, self._namespace, body) if retry else func(self._namespace, body)
  File "/usr/lib/python3/dist-packages/patroni/dcs/kubernetes.py", line 1156, in _retry
    return retry(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/patroni/utils.py", line 599, in __call__
    return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/patroni/dcs/kubernetes.py", line 558, in wrapper
    return getattr(self._core_v1_api, func)(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/patroni/dcs/kubernetes.py", line 479, in wrapper
    return self._api_client.call_api(method, path, headers, body, **kwargs)
  File "/usr/lib/python3/dist-packages/patroni/dcs/kubernetes.py", line 447, in call_api
    return self._handle_server_response(response, _preload_content)
  File "/usr/lib/python3/dist-packages/patroni/dcs/kubernetes.py", line 266, in _handle_server_response
    raise k8s_client.rest.ApiException(http_resp=response)
patroni.dcs.kubernetes.K8sClient.rest.ApiException: (404)
Reason: Not Found
HTTP response headers: HTTPHeaderDict({'Audit-Id': 'da0b6ecb-8d42-4964-9819-41a2d385b2dd', 'Cache-Control': 'no-cache, private', 'Content-Type': 'application/json', 'X-Kubernetes-Pf-Flowschema-Uid': '37606d0c-8ddf-4cc4-9faa-563142648f97', 'X-Kubernetes-Pf-Prioritylevel-Uid': '296b2e7b-e274-4aed-9e4a-019ddda1c429', 'Date': 'Wed, 07 Aug 2024 06:58:56 GMT', 'Content-Length': '214'})
HTTP response body: b'{"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"endpoints \\"patroni-postgresql\\" not found","reason":"NotFound","details":{"name":"patroni-postgresql","kind":"endpoints"},"code":404}\n'

root@postgresql-1:/# cat /var/log/postgresql/patroni.log.123
2024-08-07 06:58:56 UTC [16]: INFO: Assigning synchronous standby status to ['postgresql-2']
2024-08-07 06:58:56 UTC [16]: INFO: Synchronous standby status assigned to ['postgresql-2']
2024-08-07 06:58:56 UTC [16]: INFO: acquired session lock as a leader
2024-08-07 06:58:56 UTC [16]: INFO: Lock owner: postgresql-1; I am postgresql-1

Additional context

Looks like Patroni was unable to access the K8s API to update the leader lock. We can potentially enable Patroni's DCS failsafe mode to try to mitigate this.

Hi, @cbartz latest 14/edge (revs. 468, 469) should have DCS failsafe mode enabled, so the primary should be kept if all postgresql units are reachable from the primary. Sorry for taking so long.


Hello

Can somebody help me to run it please ? I dont know how to use that chrome

new version was released. easier to run.


How to add defaults when using WithHttpRemoteStore

Hi,
I am wondering if there is a way to programmatically add defaults when using WithHttpRemoteStore? Or should I add the defaults in each config at the Http remote store?
Thanks!

Hi @paburgos
Can you give me a concrete example of what you'd like to do here? What kind of defaults are wanting to add?

fyi there was a bug with the json deserializer settings that is fixed in the 6.7.1 release


Add warning if relevant .exe is not in the suggested folder.

To give an obvious warning if people select the wrong folder.  Current warning is kind of generic and inscrutable.
@Idhrendur I don't know if you do this in V2-H4 already but if not it might be worth adding.

Thanks! It looks like I'm actually not, though I thought I had put in those kind of checks.

Fixed in 1.0H.


Does EF Core support bulk-insert/update/delete In MySql

@clpgit "Bulk" updates are not implemented in EF Core. Batching of updates is implemented, but whether or not it is supported in MySQL depends on whether it is implemented in the EF Core provider for MySQL that you are using. Please follow up with them.


Use new jquery api in monitor

The use of jquerys $( document ).ready( handler ) is deprecated and their docs suggest a new syntax to "Specify a function to execute when the DOM is fully loaded." This PR converts our usages to that new syntax.

I started up an instance on this branch and everything looks like its working well with no related warnings or errors in the dev console.

But, if jQuery has documented the longer style as deprecated, I'm fine with switching it to standardize on the preferred syntax.

Yea that is the case.


Cannot load BartPhoTokenizer from pretrained when work with huggingface/transformers

Hi authors,
I get an error when I load the tokenizer from pretrained as bellow:
from transformers import AutoModel, AutoTokenizer
bartpho_syllable = AutoModel.from_pretrained("vinai/bartpho-syllable")
syllable_tokenizer = AutoTokenizer.from_pretrained("vinai/bartpho-syllable", use_fast=True)

AttributeError: module transformers.models.bartpho has no attribute BartphoTokenizer

I'm using Google Colab. Could you guys let me know how to overcome this issue.
Thanks.

Have you tried install transformers v4.12+ or install transformers from its latest source?
git clone https://github.com/huggingface/transformers.git
cd transformers
pip3 install --upgrade .

And also clean/remove  your folder ~/.cache/huggingface/transformers, so it'd automatically re-download BARTpho properly. It should work.

Thank you for replying. I've tried all steps in your above comment. I also checked the transformers version and cleaned/removed the folder ~/.cache/huggingface/transformers, But I still get the same error!!!

@hduc-le use_fast=False BartphoTokenizer does not support a fast version atm.

Finally, I've figured out a solution for the issue. I've changed the way of loading the pre-trained tokenizer from importing 'AutoTokenizer' to 'BartphoTokenizer' directly. Here is my code:
from transformers import AutoModel, BartphoTokenizer
model = AutoModel.from_pretrained("vinai/bartpho-syllable")
tokenizer = BartphoTokenizer.from_pretrained("vinai/bartpho-syllable")
Note: make sure that you installed the 'sentencepiece' package before.
It works for me. But I don't know why does AutoTokenizer not figure out the 'BartphoTokenizer' on Google Colab.

it's weird.
Did this following example work?
#BARTpho-syllable
syllable_tokenizer = AutoTokenizer.from_pretrained("vinai/bartpho-syllable", use_fast=False)
bartpho_syllable = AutoModel.from_pretrained("vinai/bartpho-syllable")
TXT = 'Chúng tôi là những nghiên cứu viên.'
input_ids = syllable_tokenizer(TXT, return_tensors='pt')['input_ids']
features = bartpho_syllable(input_ids)

@datquocnguyen It's actually weird. I really have no idea what happened to my code. But your code example works for me now. Sorry for taking up so much of your time, I appreciate it!!!


Add option to ignore certain releases from gh-r

Is your feature request related to a problem? Please describe.
Given the following config you'll end up using the latest release of docker-compose. As of now this results in downloading version 1.26.0-rc4 and not 1.25.5 (the latest stable).
zinit light-mode lucid wait for \
  as"program" from"gh-r" mv"docker-c* -> docker-compose" \
  docker/compose

Describe the solution you'd like
I'd like to use an ice modifier to explicitly ignore releases based on a pattern ie.
zinit light-mode lucid wait for \
  as"program" from"gh-r" mv"docker-c* -> docker-compose" \
  !bpick"*rc*" \
  docker/compose

Describe alternatives you've considered
This here works as expected. But there might be repos that do not set the "latest" tag correctly.
zinit light-mode lucid wait for \
  as"program" from"gh-r" mv"docker-c* -> docker-compose" \
  ver"latest" \
  docker/compose

Or static version pinning:
zinit light-mode lucid wait for \
  as"program" from"gh-r" mv"docker-c* -> docker-compose" \
  ver"1.25.5" \
  docker/compose

Additional context
Add any other context or screenshots about the feature request here.

At the moment I have issue with using zinit for some binaries.
RKE newest version had me downgrade from RKE 1.2 RC and downgrade to RKE 1.1.3-rc4can very I was recently.
I would like for zinit to perhaps have the option to default to https://github.com/rancher/rke/releases/latest or alteast give me an option to define a version range.

So you would like to specify e.g.: zinit ignore-latest from"gh-r" for ... and have the latest version skipped? You can already do that with the bpick ice, as bpick'*~*some-version-matching-string-to-be-excluded*'

for my use case I want the actual "latest" what GitHub consider latest, not what is the most recent.


missing data  on postgres database

Hi there,
This is a really urgent request, because I could not see it come.
I tried to use a flynn pg dump on another postgres database with pg_restore this worked for one app but not for the other, there are missing primary keys.  Interestingly the app worked fine on the flynn cluster, but the same app on the other machine (manually, development) does not, there is missing data and missing keys.
Now going into the flynn pg psql I could see that the same data is missing there.  so the dumps since I don't know when - which should be backup - are also corrupt.  Interestingly the app on the flynn cluster worked well.  But then I did a sudo reboot on the machine (my cluster has only one at the moment) made the app not to start anymore.  Seems it could not restore its state from the database.
What can I do here?  Or is the work of a company now lost from the last I don't know how many weeks or months?
Thanks for this help!
Martin

Hi @grauschnabel, can you provide an isolated reproduction case of flynn pg dump / flynn pg restore losing data? We have not seen this before, so an example of how it can happen would be useful.


Make Skligga.Hack to 1.19

This mod is really cool, but its only for 1.18, so can you make it to 1.19?

Yes say am

how to download mod hack

can you make it to 1.19?

can you make it to 1.19?

How to make sklingga 1.19.2?


release scalacheck_sjs0.6_2.13.0-M1

@rickynils

ping

This is actually holding up a good chunk of the ecosystem, since most projects cannot release their SJS 2.13.0-M1 cross-builds without ScalaCheck and ScalaTest.

The doc task seems to fail due to changes in ScalaJS (bumped to 0.6.17 to get the 2.13.0-M1 release):
> doc
[info] Main Scala API documentation to /home/rickard/src/scalacheck/js/target/scala-2.13.0-M1/api...
[error] /home/rickard/src/scalacheck/src/main/scala/org/scalacheck/Prop.scala:25: @JSExportDescendentClasses is deprecated and will be removed in 1.0.0. For use cases where you want to simulate "reflective" instantiation, use @EnableReflectiveInstantion and scala.scalajs.reflect.Reflect.lookupInstantiatableClass instead.
[error]   (you can suppress this warning in 0.6.x by passing the option `-P:scalajs:suppressExportDeprecations` to scalac)
[error] @Platform.JSExportDescendentClasses
[error]  ^
[error] /home/rickard/src/scalacheck/src/main/scala/org/scalacheck/Prop.scala:26: @JSExportDescendentObjects is deprecated and will be removed in 1.0.0. For use cases where you want to simulate "reflective" loading, use @EnableReflectiveInstantion and scala.scalajs.reflect.Reflect.lookupLoadableModuleClass instead.
[error]   (you can suppress this warning in 0.6.x by passing the option `-P:scalajs:suppressExportDeprecations` to scalac)
[error] @Platform.JSExportDescendentObjects
[error]  ^
[error] /home/rickard/src/scalacheck/src/main/scala/org/scalacheck/Properties.scala:29: @JSExportDescendentClasses is deprecated and will be removed in 1.0.0. For use cases where you want to simulate "reflective" instantiation, use @EnableReflectiveInstantion and scala.scalajs.reflect.Reflect.lookupInstantiatableClass instead.
[error]   (you can suppress this warning in 0.6.x by passing the option `-P:scalajs:suppressExportDeprecations` to scalac)
[error] @Platform.JSExportDescendentClasses
[error]  ^
[error] /home/rickard/src/scalacheck/src/main/scala/org/scalacheck/Properties.scala:30: @JSExportDescendentObjects is deprecated and will be removed in 1.0.0. For use cases where you want to simulate "reflective" loading, use @EnableReflectiveInstantion and scala.scalajs.reflect.Reflect.lookupLoadableModuleClass instead.
[error]   (you can suppress this warning in 0.6.x by passing the option `-P:scalajs:suppressExportDeprecations` to scalac)
[error] @Platform.JSExportDescendentObjects
[error]  ^
[info] No documentation generated with unsuccessful compiler run
[error] four errors found
[error] (js/compile:doc) Scaladoc generation failed
[error] Total time: 6 s, completed Jun 8, 2017 4:37:47 PM

Ping @sjrd.

just remove -Xfatal-warnings ?
https://github.com/rickynils/scalacheck/blob/1.13.5/build.sbt#L51

That's an option: https://github.com/djspiewak/scalacheck/tree/wip/2.13  It'll have to be addressed eventually though.

http://www.scala-js.org/news/2017/03/21/announcing-scalajs-0.6.15/ explains the deprecation and how to migrate

As pointed by @SethTisue, the 0.6.15 announcement should explain everything you need to know to migrate. Feel free to ask further questions if it's not enough.

@rickynils is your wip on this on GitHub? I could try to finish it up.

@SethTisue No wip. I just bumbed the scalajs version in plugins.sbt. If PRs are provided for the 1.13.5_sonatype and 1.12.6_sonatype branches I can try to publish releases. But maybe we have to cut new releases if there are code changes.
Sorry for my unresponsiveness. It is mainly because I got a kid some weeks ago, and partly because I have never used ScalaJS.

please continue to prioritize your human children over your digital ones :-)
the release notes say that scalacOptions += "-P:scalajs:suppressExportDeprecations" will continue to work for Scala.js 0.6.x, so that seems like an acceptable minimal fix for now. I will send PRs on the two branches you suggest

trio of pull requests: #339, #340, #341

hmm, actually it's not that hard to go ahead and make the necessary changes to not use the deprecated stuff at all. revising the PRs now

hmm, well, probably better to make the minimal change on the release branches. I did the better version on master (#341); the other two are fine as-is I think.

Thanks!
https://oss.sonatype.org/content/repositories/releases/org/scalacheck/scalacheck_sjs0.6_2.13.0-M1/

@SethTisue Thanks for the PRs! I've published releases for ScalaCheck 1.12.6 and 1.13.5


Confidential elements to satoshi value format and viceversa

Before there was no option to convert from Satoshi to Elements value and vice verse.
After the methods SatoshiToElementsValue/ElementsToSatoshiValue are added, it is possible to convert from Satoshi to Elements value and vice verse.
Note that new package 'common' is created, which contains files previously located in the transaction package.
This was done in order to resolve a circular dependency issue.
It closes #75  .
Please @altafan can you review this?

@tiero do you think it is the case to merge the common and the internal/bufferutil packages into the bufferutil one?
At the end of the day the ReverseBytes function of the internal/bufferutil could be useful for users if they ever need to reverse a tx hash or whatever for any reason.
At the same time, It would be better to give a more meaningful name to the common package and bufferutil fits well IMO.

@tiero @sekulicd do you think it is the case to merge the common and the internal/bufferutil packages into the bufferutil one?

I think users of go packages should be able to grasp its purpose from just the package's name. Common makes it difficult. See https://blog.golang.org/package-names and https://rakyll.org/style-packages/

At the end of the day the ReverseBytes function of the internal/bufferutil could be useful for users if they ever need to reverse a tx hash or whatever for any reason.

I would keep it internally used only by the library and try to give high level interfaces to the user (eg. no need to revers). We could create a public package in a separate repository that does only this (if doesn't exist already)

I think users of go packages should be able to grasp its purpose from just the package's name. Common makes it difficult. See https://blog.golang.org/package-names and https://rakyll.org/style-packages/

Yes, I agree with this in fact my purpose was avoiding to use the name common for a package.

I would keep it internally used only by the library and try to give high level interfaces to the user (eg. no need to revers). We could create a public package in a separate repository that does only this (if doesn't exist already) and if it's really needed.

Ok, so what if we basically move the whole actual common package into internal/bufferutil?
I mean, like the user of the lib does not need to reverse a byte slice, he shouldn't  also need to use the Serializer and Deserializer low-level types.

Ok, so what if we basically move the whole actual common package into internal/bufferutil?

I prefer this way. Makes sense to you? @sekulicd

Ok, so what if we basically move the whole actual common package into internal/bufferutil?

I prefer this way. Makes sense to you? @sekulicd

In general project structure layout, in Golang, is bit gray area to me.
Its clear that the goal is to have simple, short packages that can be used by clients, but sometimes I would say, its hard to apply some architectural design pattern without having folder hierarchies.
Links you pasted in previous comments are well known and provides general guidance only.
I think that project structure layout should vary based on the type of the project (Api, SDK, CLI etc).
In previous projects I was trying to follow recommendations from here with some custom decisions.
As you know many important projects are written in Go and we can check and try to apply some patterns when starting new project.
In case of this project, which is sort of SDK, to be used by a various client I think we are on good track and that using internal package for code which is not meant to be used by client is good idea.

Agreed @sekulicd


Rclone output - Cleaner for easier parsing.

When filing an issue, please include the following information if possible as well as a description of the problem.  Make sure you test with the latest beta of rclone.
http://beta.rclone.org/
http://rclone.org/downloads/

If you've just got a question or aren't sure if you've found a bug then please use the rclone forum instead of filing an issue.

What is your rclone version (eg output from rclone -V)

Latest

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Windows

Which cloud storage system are you using? (eg Google Drive)

Any

The command you were trying to run (eg rclone copy /tmp remote:tmp)

It would be nice to have a very minimal output on things like lsd for easy parsing of the output.
While something like this works "rclone.exe lsd remote:| % {($_ -split ' -1')[2]}"
Its a lot of overhead on scripting.

Hi,
This is very nice idea. I know how it is annoying when you have to use sed or python to parse output... To remove whitespace, replace separator and etc...
I would like to work on this issue in this weekend and I have one idea.
I will add flags, which we can use in command ls/lsd/lsl (maybe also in lsjson?).
Example:
--format "nm" --sep ";"
How it works?
In flag --format each char represent one type of informations which will be printed. Order is important.
n - file/dir name
s - size
t - modTime
etc.
and flag --sep will contains information about string, which will be printed between informations (default one space).
For example:

$ rclone lsl drive:
3541475 2017-11-28 09:52:40.042000000 Presentation.pptx
25600 2014-05-19 12:05:49.018000000 Beijing2014.doc
0 2017-11-12 00:01:19.060000000 subdir
0 2006-01-02 01:00:00.000000000 file
248000 2017-11-24 20:37:18.357000000 b/b
13584 2017-11-24 20:53:31.444000000 b/animal.jpg

$ rclone lsl --format "ns" --sep " " drive:
Presentation.pptx 3541475
Beijing2014.doc 25600
subdir 0
file 0
b/b 248000
b/animal.jpg 13584

or

$ rclone lsl --format "ns" --sep "__SEP__" drive:
Presentation.pptx__SEP__3541475
Beijing2014.doc__SEP__25600
subdir__SEP__0
file__SEP__0
b/b__SEP__248000
b/animal.jpg__SEP__13584

Maybe I should implemented this as new function?
For example named it print.
And to better understand my idea, these command will give us almost this same output:

$ rclone ls drive:
$ rclone print --format "sn" --sep "\t"

and

$ rclone lsl drive:
$ rclone print --format "stn" --sep "\t"

I think I will be very easy to use.


Updated README. md

Centre Aligned the chat bagde under "Community Support" section .
resolve #3610  issue by @kendalldoescoding

As in https://github.com/EddieHubCommunity/support/issues/3610#issuecomment-1053658508 I also like it at the left alignment

-- hey, Tom that's a great  idea💡
-- you can check the left alignment as well.

Closing due the left alignment looking better as discussed in this PR.
Feel free to crap another issue and resolve this one.
Hope this is ok for you.
__
  Summary: :trophy: This code is awesome


Issues with bidirectionalRelations Generation in Entity Models

Describe the bug
I am encountering an issue with Mikro-ORM where the entity generator does not automatically create the relationship properties between Users and Licenses. Although I have defined the relationship in the database schema, the entities generated do not reflect this relationship as expected
Reproduction
import { MsSqlDriver, Options } from '@mikro-orm/mssql';
import { TsMorphMetadataProvider } from '@mikro-orm/reflection';
import dotenv from 'dotenv';
dotenv.config();

const config: Options = {
    driver: MsSqlDriver,
    host: process.env.DB_HOST,
    port: 1433,
    user: process.env.DB_USER,
    password: process.env.DB_PASS,
    dbName: process.env.DB_NAME,
    entities: ['dist/entities/**/*.js'],
    entitiesTs: ['src/entities/**/*.ts'],
    discovery: {
        warnWhenNoEntities: false,
    },
    metadataProvider: TsMorphMetadataProvider,
    baseDir: process.cwd(),
    debug: true,
};
export default config;

// scripts/generate-entities.ts
import { MikroORM } from '@mikro-orm/core';
import { EntityGenerator } from '@mikro-orm/entity-generator';
import config from '../src/config/mikro-orm.config';

const generateEntities = async () => {
    const orm = await MikroORM.init({
        ...config,
        discovery: { warnWhenNoEntities: false },
        extensions: [EntityGenerator],
    });
    const dump = await orm.entityGenerator.generate({
        save: true,
        path: process.cwd() + '/src/entities',
        bidirectionalRelations: true,
    });
    await orm.close(true);
};

generateEntities().catch((err) => {
    console.error(err);
    process.exit(1);
});

@Entity({ tableName: 'Users' })
export class Users {
  @PrimaryKey({ fieldName: 'UserID' })
  UserID!: number;

  @Property({ fieldName: 'Username', length: 255 })
  Username!: string;

}

@Entity({ tableName: 'Licenses' })
export class Licenses {
  @PrimaryKey({ fieldName: 'LicenseID' })
  LicenseID!: number;

 @ManyToOne({ entity: () => Users, fieldName: 'UserID', index: '<Index_License_UserID>' })
  UserID!: Users;

}

What driver are you using?
@mikro-orm/mssql
MikroORM version
^6.2.9
Node.js version
v22.3.0
Operating system
Windows 11
Validations

[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Slack.
[X] The provided reproduction is a minimal reproducible example of the bug.

Yes please, provide a schema, what you gave us is not a reproduction without it.

Closing as not reproducible, let's reopen with a reproduction.

My apologies for the wait. I kept getting a TypeError: Unknown file extension ".ts"  error when trying to run npx mikro-orm schema:create -d so instead I used the SchemaGenerator programmatically. with const createDump = await orm.schema.getCreateSchemaSQL();. Please see a stripped version of schema for users and licenses.
Schema create output below
exec sp_MSforeachtable 'alter table ? nocheck constraint all';

CREATE TABLE [Users] ([UserID] int identity(1,1) not null primary key, [Username] nvarchar(255) not null);
CREATE UNIQUE INDEX [IX_Users_Username] ON [Users] ([Username]) WHERE [Username] IS NOT NULL;

CREATE TABLE [Licenses] ([LicenseID] int identity(1,1) not null primary key, [UserID] int not null);
CREATE INDEX [<Index_License_UserID>] ON [Licenses] ([UserID]);

alter table [Licenses] add constraint [Licenses_UserID_foreign] foreign key ([UserID]) references [Users] ([UserID]) on update cascade;

exec sp_MSforeachtable 'alter table ? check constraint all';

If I try to test the User entity with the findOne() function, ignoring the fact that the license relationship isnt created I get a query error of
[query] select top (1) [u0].*, [u1].[id] as [u1__id] from [users] as [u0] left join [user_twitter_relation] as [u1] on [u0].[UserID] = [u1].[user_id] where [u0].[Username] = N'test' [took 27 ms]
Authentication error: TableNotFoundException: select top (1) [u0].*, [u1].[id] as [u1__id] from [users] as [u0] left join [user_twitter_relation] as [u1] on [u0].[UserID] = [u1].[user_id] where [u0].[Username] = N'test' - Invalid object name 'user_twitter_relation'.

I have tried to re-create the schema below with UserTwitterRelation added but I keep getting this schema gen error
ReferenceError: Cannot access 'Users' before initialization
    at file:///C:/Node/Mikro-orm/src/entities/UserTwitterRelation.ts:22:31

The schema you provided here works just fine, it produces the following entities, including the 1:m relations:
import { Entity, ManyToOne, PrimaryKey, PrimaryKeyProp } from '@mikro-orm/core';
import { Users } from './Users';

@Entity({ tableName: 'Licenses' })
export class Licenses {

  [PrimaryKeyProp]?: 'LicenseID';

  @PrimaryKey({ fieldName: 'LicenseID' })
  LicenseID!: number;

  @ManyToOne({ entity: () => Users, fieldName: 'UserID', updateRule: 'cascade', index: '<Index_License_UserID>' })
  UserID!: Users;

}

import { Collection, Entity, OneToMany, PrimaryKey, PrimaryKeyProp, Property, Unique } from '@mikro-orm/core';
import { Licenses } from './Licenses';

@Entity({ tableName: 'Users' })
@Unique({ name: 'IX_Users_Username', expression: 'create unique index [IX_Users_Username] on [Users] (where ([Username] IS NOT NULL))' })
export class Users {

  [PrimaryKeyProp]?: 'UserID';

  @PrimaryKey({ fieldName: 'UserID' })
  UserID!: number;

  @Unique({ name: 'IX_Users_Username' })
  @Property({ fieldName: 'Username' })
  Username!: string;

  @OneToMany({ entity: () => Licenses, mappedBy: 'UserID' })
  UserIDInverse = new Collection<Licenses>(this);

}

Note that I am trying this out on master, could be something already addressed in the last month, so maybe try the latest dev version instead of 6.2.9.

I am also not following why are you using ts-morph metadata provider if you are bootstrapping entities from an existing schema, which brings me again to my previous question - what kind of setup are you trying to build?

I am not following, you reported an issue with the entity generator, so you must have had a schema before - how is using the schema generator now relevant? We wanted to see your schema, not output from the schema generator. What kind of setup are you trying to build?

I cant return the whole schema for data privacy reasons hence why I just returned the schema that was generated from the current entities shown thinking that would help let you repro it in some way.

I am also not following why are you using ts-morph metadata provider if you are bootstrapping entities from an existing schema, which brings me again to my previous question - what kind of setup are you trying to build?

Yes I am generating my types from an existing schema. Is a metadata provider not recommended in that case? I assume regardless if they are generated or not I should still run an entity discovery process to ensure the entities are correct.

Note that I am trying this out on master, could be something already addressed in the last month, so maybe try the latest dev version instead of 6.2.9.

I have tried using the dev version but still no change. Something I noticed is that only one relationship that maps to UserID is created. In that case, I see the mapped field name is UserIDInverse. Now, what if I have multiple items mapped to UserID? How does Mikro-ORM handle that naming convention? Is it with UserIDInverse1, UserIDInverse2, etc.?
The reason I ask is that I have noticed many of my tables with a bidirectional connection mapped by UserID aren't showing, and only one is returned when generating. For example, here are some more of my entities stripped down. You can see only one UserIDInverse is created. Is that a possible bug? I am trying to generate the schema for you, as I can't return my production one here, but for now, hopefully, the entity example is helpful until I get past the TypeError: Unknown file extension ".ts" and ReferenceError: Cannot access 'Users' before initialization.

what kind of setup are you trying to build?

TS backend for a legacy mssql DB. Hopefully with auto generating entities (with bidirectional relationships). Nothing to complex
import { Collection, Entity, Index, ManyToMany, ManyToOne, OneToMany, OneToOne, type Opt, PrimaryKey, PrimaryKeyProp, Property, Unique } from '@mikro-orm/core';
import { WizardOrigin } from './WizardOrigin';

@Entity()
@Index({ name: 'Deleted', properties: ['deleted', 'userId'] })
export class Users {
    [PrimaryKeyProp]?: 'userId';

    @PrimaryKey({ fieldName: 'UserID' })
    userId!: number;

    @Unique({ name: 'IX_Users_Username' })
    @Property({ fieldName: 'Username', type: 'string', columnType: 'varchar(255)' })
    username!: string;

    @OneToMany({ entity: () => WizardOrigin, mappedBy: 'userId' })
    userIdInverse = new Collection<WizardOrigin>(this);
}

import { Entity, ManyToOne, PrimaryKey, PrimaryKeyProp, Property } from '@mikro-orm/core';
import { Users } from './Users';

@Entity()
export class WizardOrigin {
    [PrimaryKeyProp]?: 'wizardOriginId';

    @PrimaryKey({ fieldName: 'WizardOriginID' })
    wizardOriginId!: number;

    @ManyToOne({ entity: () => Users, fieldName: 'UserID' })
    userId!: Users;
}

import { Entity, OneToOne, PrimaryKey, PrimaryKeyProp } from '@mikro-orm/core';
import { Users } from './Users';

@Entity()
export class UserInfo {
    [PrimaryKeyProp]?: 'userInfoId';

    @PrimaryKey({ fieldName: 'UserInfoID' })
    userInfoId!: number;

    @OneToOne({ entity: () => Users, fieldName: 'UserID', nullable: true, unique: 'IX_UserID' })
    userId?: Users;
}

import { Entity, OneToOne, PrimaryKeyProp } from '@mikro-orm/core';
import { Users } from '../entities/Users';

@Entity()
export class TrialInfo {
    [PrimaryKeyProp]?: 'userId';

    @OneToOne({ entity: () => Users, fieldName: 'UserID', primary: true })
    userId!: Users;
}

import { Entity, ManyToOne, PrimaryKey, PrimaryKeyProp } from '@mikro-orm/core';
import { Users } from './Users';

@Entity()
export class Licenses {
    [PrimaryKeyProp]?: 'licenseId';

    @PrimaryKey({ fieldName: 'LicenseID' })
    licenseId!: number;

    @ManyToOne({ entity: () => Users, fieldName: 'UserID', index: '<Index_License_UserID>' })
    userId!: Users;
}

Ha, the duplicities might be actually it, looking at the code, we are not handling that apparently:
https://github.com/mikro-orm/mikro-orm/blob/master/packages/entity-generator/src/EntityGenerator.ts#L265
Btw no one is asking for your production schema, you should provide minimal reproduction, so make a copy of it, start dropping tables till it works correctly, then drop all columns till it starts working correctly, the result is what we need, and you can obfuscate the names as much as you wish. But I guess we don't need it now, since you identified the cause already, it should be easy to reproduce.
You don't need the ts-morph metadata provider if you generate entities via the generator, you are making your setup unnecessarily more complex with it, just use the defaults. Also, you don't need metadata provider to validate your schema, that is a component to load metadata from entity definitions on the ORM init, so it can work with them (e.g. when hydrating or creating queries or altering schema). The entity generator is not using this component at all, and it generates the definitions that are valid for the default reflect metadata provider. You can also opt in to generate the entities including the types, so even reflect-metadata wont be necessary, or use EntitySchema so you don't have decorators (in case you would like to compile with something like esbuild which doesn't support the legacy decorators).

Hmm fixing this actually feels a tiny bit breaking, since now we only define the last relation from the list of duplicities, if I add the suffix, they will change order (the one without suffix will be a different one than before potentially - it happens in the existing tests multiple times). I guess I will change the naming for the inverse sides completely and leave the Inverse suffix only for M:N relations where it makes some sense, and use the target entity name for the others. Now it's really meant for users to change it anyway, having an inverse called userIdInverse1/2/3 feels weird when it could be called wizardOrigins/userInfo/trialInfo. Will also make it configurable for anyone who could be already depending on those dummy names.


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-2.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 568

Questions ?
Please refer to the Backport tool documentation


GH-36518: [Java] Fix ArrowFlightJdbcTimeStampVectorAccessor to return Timestamp objects with date and time that corresponds with local time instead of UTC date and time

Rationale for this change
When calling the getTimestamp method from the ArrowFlightJdbcTimeStampVectorAccessor class, the timezone of the Timestamp object returned is incorrect. The timestamp itself appears to be in GMT/UTC time but the timezone field of the Timestamp object is populated with the timezone of the JDBC client instead.
Example
timestamp on db: 2021-03-28T00:15:00.000 (UTC)
timezone of JDBC client: PST/PDT (Vancouver Time)
Calendar cal <- Calendar with UTC timezone
calling getTimestamp(cal) on a result set will return a timestamp like this: 2021-03-28T00:15:00.000 (PST/PDT)
where 2021-03-28T00:15:00.000 appears to be in UTC time but the timezone of the object itself is PST/PDT
What changes are included in this PR?

Fixed: Correct behaviour is that the calendar object is used to extend the data into the timezone of the calendar object, essentially asserting that the data is at the timezone defined in the calendar object and returns a time-related object that has local date and time and local timezone
Fixed: for vectors that do store timezone information (ie. TimestampVector), the getter methods will use the timezone defined in vector as the timezone assertion and ignores the calendar object if one was passed in
Fixed: applyCalendarOffset now correctly creates a corresponding time-related object using the supplied calendar timezone and returns a time-related object that has local date and time and local timezone

Are these changes tested?
Many of the time related tests also face this issue and this fixes them all. Also tested the driver jar in a JDBC client and behaviour is fixed.
Are there any user-facing changes?

No. Closes: https://github.com/apache/arrow/issues/36518

Closes: #36518

I tried to do similar thing before: https://github.com/apache/arrow/pull/35139. After discussion with @lidavidm, we have agreed on the current behavior. Let me know if you have different opinion after going through the past discussion.

Hey @wgtmac! So I read through the discussion and although I agree on keeping the behaviour as is (ie. keeping the timestamp returned in UTC time) I still think its worth to address the issue where the actual "timezone" field of the object returned is not in UTC, which causes a lot of confusion when trying to utilize the timestamp object (ie. turning it into a formatted date string, converting the timestamp into local time easily, etc.)

I think based on your description, yes, we should return a timestamp that is properly in UTC. What I then don't understand is what the point of the Calendar argument is in the first place; I suppose if we pass a non-UTC Calendar, we should localize the UTC timestamp to the given timezone?

@lidavidm Yeah so I was also confused at first but according to this article: https://medium.com/@williampuk/sql-timestamp-and-jdbc-timestamp-deep-dive-7ae0ea91e237 it seems like the JDBC drivers for some of the major RDBMS, the provided calendar instance is used to assert that the date and time of the timestamp stored on the db is at the timezone specified by the calendar (ie. if the timestamp is 2022-07-13 00:15 and we pass in a calendar at UTC+8, then we are asserting that the timestamp is 2022-07-13 00:15 UTC+8) then when it is returned, we convert that timestamp into either local system time or UTC+0 (ie. we should see 2022-07-12 16:15 UTC+0 in the timestamp object returned by the method)
Quote from article findings:
Providing a Calendar instance We now look at the values returned from ResultSet::getTimestamp(int, Calendar), i.e. the values denoted by (using NY Cal) . The java.util.Calendar object provided to the call is an instance of Calendar at ‘America/New_York’ time zone. According to the Java docs, the method “uses the given calendar to construct an appropriate millisecond value for the timestamp if the underlying database does not store timezone information.” (https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/ResultSet.html#getTimestamp(int,java.util.Calendar)) In other words, by providing a Calendar instance, we are telling the driver that, we know the Date and Time value given by the query result is at the time zone of the provided Calendar instance, so please construct a java.sql.Timestamp storing the instant of time computed by all these pieces of information given. It also suggests it does not make sense to use this method if the target type already contains the time zone information, e.g. TIMESTAMP WITH TIME ZONE .

Ok, thanks for the references. I'll try to look at this more closely when I get a chance but my time for Java related work is limited these days, so it may be a while.

The logic is hard to follow (the original code sure does not help...) But I'm not sure if the changes here are defensible without more explanation of the logic in the code. It might help to make sure we have clear test cases of expected behavior first.

I think its worth to clarify what my logic/presumptions are.
So essentially, the logic in the change is that:

The timestamp value is retrieved from the database (ie. database shows (2013-03-28 00:00:00.000)). The database does not store any timezone information but the timestamp of 2013-03-28 00:00:00 has an inherent timezone that is either outlined by the database itself or the users themselves know what the timezone is for this timestamp. Thus, the calendar object that could be provided into the accessor methods allows users to assert this information.
When this value is retrieved from the database, the accessor method for getTimestamp first creates a LocalDateTime object using the epochMilliseconds of the timestamp (ArrowFlightJdbcTimeStampVectorAccessor: line 93)
We then determine what timezone the LocalDateTime should be (ArrowFlightJdbcTimeStampVectorAccessor: line 97-103).
Since in ArrowFlightJdbcTimeStampVectorAccessor#getTimestamp line 135 uses Timestamp.valueOf(LocalDateTime) to create the timestamp object that is returned to the client, ArrowFlightJdbcTimeStampVectorAccessor: line 105 essentially creates a ZonedDateTime using the LocalDateTime + the timezone determined in step 3, essentially attaching the timezone to the LocalDateTime value (no timezone conversion takes place yet). Then we convert the timestamp to the system default timezone and return the timestamp as a LocalDateTime.

What ended up happening before was that the LocalDateTime that was returned by the getLocalDateTime method reflects the timestamp being converted from the timezone of the calendar input (or system default when it is null) to UTC (since in the original code, the timezone of the vector defaulted to UTC). But Timestamp.valueOf(LocalDateTime) interprets the LocalDateTime passed in as it is in the system default timezone, thus causing the issue where we did get the correct time and date value  but the timezone of the Timestamp object is the system timezone instead of UTC (or whatever the timezone of the Vector is)

Sorry, I would like to sit down and make a few tests and compare them with other drivers to make sure I have a good handle on what's going on here. But I don't have much time for Arrow Java development beyond simple maintenance PRs.

@lidavidm Do you know any other expert can join the discussion? I'd like to follow up with it fix but my experience on this is limited.

No, I don't think any of the contributors that originally worked on the JDBC driver are still active in the project.

My experience is also limited, hence why I wanted to construct the test cases.

Thanks, I agree with you @lidavidm

@jhmannok , could you list the client applications that you've verified this change with? It'd be great to know what's been covered since this API is not that clear.

I might have missed this as well, but can you verify the behaviors of the Oracle and SQL Server drivers when using time with timezone vs raw time types?

Hi,
I see that this PR has been without movement for several months.  I am interested in continuing with the changes.
This PR is over Arrow 13.0.0, but current version is 16. What would be the better way?, creating a new PR with these changes but from current Arrow version, or continuing here?
@jhmannok, are you ok if I go on with this work?

I created a new PR with the changes https://github.com/apache/arrow/pull/43149


extension for remote access to Webservice via Python HLF client

Description
Extension of Python HLF to support remote access to Webservice via network. On the server side it's necessary to run RFEM with allowed SSL connection (installed certificates) and on client side it's necessary to run RFEM Python client with proper settings in connectionGlobals.py (url to remote PC: https://x.x.x.x and api_key from Extranet/MyData). As mandatory condition it's required to have allowed remote access to Webservice for given contact which is used to login to RFEM/RSTAB on server side (it's necessary to contact Dlubal admin for that)
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update

How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[x] Unit Tests
[x] Attached examples

Test Configuration:

RFEM version: 6.07.0001
Python version:

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Can you explain why some tests are skipped if they don't use or check any external file? Because this was the reason to skip them at the beginning. They just doesn't work?

All the skipped tests contain handling of external file or somehow work with directories and their paths.


pubsub: make sure to catch up sub in a transaction

So the last sent row and the last change ID values are consistent.
Otherwise it might skip all the changes happened between reading the rows
and querying the last change ID.

Not tested yet.


(SystemJS) XHR error (404 Not Found) loading http://localhost:3000/traceur

Hi i am using .net + angular 4 whenever i tried to import FusionChartModule i am getting the error as shown in image.... do i need to add anything in system.config.js file... please help me with this issue ?

I don't think this has something to do with semantic-UI?


DeviceSpec can have two different targets

Issue description
Creating a DeviceSpec object involves specifying a target device at two distinct places:

passing it as the target argument
specifying within the circuit template, as the layout in the spec argument. Such a layout contains a target field, an excerpt could look as follows:

name template_4x2_X8
version 1.0
target X8_01 (shots=1)

It is, however, not checked if these two values are equal. Therefore, in certain cases, different values are accepted, making it a (rare) edge case for DeviceSpec creation.

Expected behavior: (What you expect to happen)
The target values contained in a DeviceSpec object are the same.

Actual behavior: (What actually happens)
These target values can differ.

import strawberryfields as sf
import strawberryfields.ops as ops
from strawberryfields.utils import random_interferometer
U = random_interferometer(4)

from strawberryfields.api import DeviceSpec

import textwrap

test_spec = {
    "layout": textwrap.dedent(
        """\
        name template_4x2_X8
        version 1.0
        target X8_01 (shots=1)

        # for n spatial degrees, first n signal modes, then n idler modes, all phases zero
        S2gate({squeezing_amplitude_0}, 0.0) | [0, 4]
        S2gate({squeezing_amplitude_1}, 0.0) | [1, 5]
        S2gate({squeezing_amplitude_2}, 0.0) | [2, 6]
        S2gate({squeezing_amplitude_3}, 0.0) | [3, 7]

        # standard 4x4 interferometer for the signal modes (the lower ones in frequency)
        # even phase indices correspond to internal Mach-Zehnder interferometer phases
        # odd phase indices correspond to external Mach-Zehnder interferometer phases
        MZgate({phase_0}, {phase_1}) | [0, 1]
        MZgate({phase_2}, {phase_3}) | [2, 3]
        MZgate({phase_4}, {phase_5}) | [1, 2]
        MZgate({phase_6}, {phase_7}) | [0, 1]
        MZgate({phase_8}, {phase_9}) | [2, 3]
        MZgate({phase_10}, {phase_11}) | [1, 2]

        # duplicate the interferometer for the idler modes (the higher ones in frequency)
        MZgate({phase_0}, {phase_1}) | [4, 5]
        MZgate({phase_2}, {phase_3}) | [6, 7]
        MZgate({phase_4}, {phase_5}) | [5, 6]
        MZgate({phase_6}, {phase_7}) | [4, 5]
        MZgate({phase_8}, {phase_9}) | [6, 7]
        MZgate({phase_10}, {phase_11}) | [5, 6]

        # add final dummy phases to allow mapping any unitary to this template (these do not
        # affect the photon number measurement)
        Rgate({final_phase_0}) | [0]
        Rgate({final_phase_1}) | [1]
        Rgate({final_phase_2}) | [2]
        Rgate({final_phase_3}) | [3]
        Rgate({final_phase_4}) | [4]
        Rgate({final_phase_5}) | [5]
        Rgate({final_phase_6}) | [6]
        Rgate({final_phase_7}) | [7]

        # measurement in Fock basis
        MeasureFock() | [0, 1, 2, 3, 4, 5, 6, 7]
    """
    ),
    "modes": 8,
    "compiler": [],
    "gate_parameters": {
        "squeezing_amplitude_0": [0, 1],
        "squeezing_amplitude_1": [0, 1],
        "squeezing_amplitude_2": [0, 1],
        "squeezing_amplitude_3": [0, 1],
        "phase_0": [0, [0, 6.283185307179586]],
        "phase_1": [0, [0, 6.283185307179586]],
        "phase_2": [0, [0, 6.283185307179586]],
        "phase_3": [0, [0, 6.283185307179586]],
        "phase_4": [0, [0, 6.283185307179586]],
        "phase_5": [0, [0, 6.283185307179586]],
        "phase_6": [0, [0, 6.283185307179586]],
        "phase_7": [0, [0, 6.283185307179586]],
        "phase_8": [0, [0, 6.283185307179586]],
        "phase_9": [0, [0, 6.283185307179586]],
        "phase_10": [0, [0, 6.283185307179586]],
        "phase_11": [0, [0, 6.283185307179586]],
        "final_phase_0": [0, [0, 6.283185307179586]],
        "final_phase_1": [0, [0, 6.283185307179586]],
        "final_phase_2": [0, [0, 6.283185307179586]],
        "final_phase_3": [0, [0, 6.283185307179586]],
        "final_phase_4": [0, [0, 6.283185307179586]],
        "final_phase_5": [0, [0, 6.283185307179586]],
        "final_phase_6": [0, [0, 6.283185307179586]],
        "final_phase_7": [0, [0, 6.283185307179586]],
    },
}

def generate_X8_params(r, p):
    return {
        "squeezing_amplitude_0": r,
        "squeezing_amplitude_1": r,
        "squeezing_amplitude_2": r,
        "squeezing_amplitude_3": r,
        "phase_0": p,
        "phase_1": p,
        "phase_2": p,
        "phase_3": p,
        "phase_4": p,
        "phase_5": p,
        "phase_6": p,
        "phase_7": p,
        "phase_8": p,
        "phase_9": p,
        "phase_10": p,
        "phase_11": p,
        "final_phase_0": 1.24,
        "final_phase_1": 0.54,
        "final_phase_2": 4.12,
        "final_phase_3": 0,
        "final_phase_4": 1.24,
        "final_phase_5": 0.54,
        "final_phase_6": 4.12,
        "final_phase_7": 0,
    }

X8_spec = DeviceSpec(target="X8", connection=None, spec=test_spec) # <--- specifying X8 as target instead of X8_01

params = generate_X8_params(1, 0.3)

prog = X8_spec.create_program(**params)

eng = sf.RemoteEngine("X8_01")
device = eng.device_spec

res = eng.run(prog, shots=10)

Reproduces how often: (What percentage of the time does it reproduce?)
Rarely: the user has to explicitly pass a target different to the target defined in layout.

System information: (post the output of import strawberryfields as sf; sf.about())
SF 0.15.0

Additional information
The solution could involve removing the target argument and deriving target from the layout specified. This might be a breaking change to the stack though.

Perhaps a short term solution is to simply include validation on Spec creation, to ensure that the two target values are identical?

This has been fixed in #656. The DeviceSpec object uses the target value in the device specification dictionary. There could still potentially be two targets in the specification dictionary (in the layout and in the target field), although this is related to the device specifications on the platform and not an SF issue.


fix: nav background styles in dark mode

The background color of Nav component has unexpected behavior in dark mode. Image below was a screenshot from the official docs site of island

The background color of left side of the Nav component was just different

LGTM


Cannot rename ColumnGroup and its children at the same time

As the title says, renaming of columns inside column groups cannot be done if the column group itself is renamed in the same call.
For instance:
val myDf = dataFrameOf("a", "b", "c")(1, 2, 3).group("a", "b", "c").into("letters")
//⌌---------------------⌍
//|  |           letters|
//|--|------------------|
//| 0| { a:1, b:2, c:3 }|
//⌎---------------------⌏

myDf.rename {
    all().recursively()
    // or using the old notation
    allDfs(includeGroups = true)
}.into { it.name + "_renamed" }

//⌌---------------------⌍
//|  |   letters_renamed|
//|--|------------------|
//| 0| { a:1, b:2, c:3 }|
//⌎---------------------⌏

It needs to be done in two separate operations, like:
myDf
    .rename {
        cols { !it.isColumnGroup() }.recursively()
    }.into { it.name + "_renamed" }
    .rename {
        cols { it.isColumnGroup() }.recursively()
    }.into { it.name + "_renamed" }

//⌌--------------------------------------------⌍
//|  |                          letters_renamed|
//|--|-----------------------------------------|
//| 0| { a_renamed:1, b_renamed:2, c_renamed...|
//⌎--------------------------------------------⌏

From a user-perspective, this makes little sense and we should probably find a way to fix this.

This actually also breaks renameToCamelCase() which breaks running a test like:
val doublyNestedColumnGroup = dataFrameOf("test_name")(
    dataFrameOf("another_name")(
        dataFrameOf("third_name")(1).first()
    ).first()
)

val df = doublyNestedColumnGroup.renameToCamelCase()
df.columnNames() shouldBe listOf("testName")
df["testName"].asColumnGroup().columnNames() shouldBe listOf("anotherName") // still named "another_name"
df["testName"]["anotherName"].asColumnGroup().columnNames() shouldBe listOf("thirdName")

So an all-encompassing solution is needed.

The problem runs deeper... It also applies to
df.move { group and group.child }.into { ... }

and
df.replace { group and group.child }.with { ... }

If the name changes of a group, its children won't be updated since their path now differs from their new path.


Wolframalpha 3.0 usage guide error

I hope this is the right place to submit this. The code block:
for pod in res.pods:
  for sub in pod.subpods:
  print(sub.text)

at https://pypi.org/project/wolframalpha/ is incorrect. The code as written returns
  val = self[name] if name in self else self[attr_name]
KeyError: '@text'

During handling of the above exception, another exception occurred:

  raise AttributeError(name)
AttributeError: text

This error can be fixed by amending the code to read:
for pod in res.pods:
  for sub in pod.subpods:
      print(sub.plaintext)

Hi @C-Jameson, this is the repository for the codebase which powers https://pypi.org/.
The wolframalpha module's homepage is at https://github.com/jaraco/wolframalpha, you should open this issue there instead.


JUnitParamsRunner incorrectly fails test if a parameter class does not override equals()

Consider the simple test class below. The plain JUnit test passes but the JUnitParams version fails. The new Object() can be replaced by any class that does not override the Object.equals() method. I expect this does not happen often, as most classes do override it.
@RunWith(JUnitParamsRunner.class)
public class BugReportTest
{
    Object value = new Object();

    @Test
    @Parameters
    public void valueEqualsItself(Object sameValue)
    {
        assertEquals(value, sameValue);
    }

    private Object[][] parametersForValueEqualsItself()
    {
        return new Object[][]{{value}};
    }

    @Test
    public void valueEqualsItself()
    {
        assertEquals(value, value);
    }
}

This is a side-effect of how parameters are computed
Parameter computation occurs before the test invocation by instantiating an instance of the supplier class (either the current test class or the class specified by the source parameter). The parameter set is then computed; for each test a new test class instance is created and the test method is invoked with the parameters.
Therefore the source of the parameters parameterSource does not obey parameterSource == this for the invocation during the test therefore `parameterSource.value != this.value).
It is for this reason that the provided test fails because sameValue is not value according to Object#equals.


Respect positions when saving and loading a PCM

Done, but have to change order when columns move and find a way to move products


MINOR: Remove deprecated assertThat method usage from KafkaLog4jAppenderTest

Replace Assert.assertThat with MatcherAssert.assertThat.

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@ijuma Hotfix to fix the compilation issues in KafkaLog4jAppenderTest, This was due to Junit usage and changes  #6216 and #6248

Thanks, looks like the two PRs were merged somewhat concurrently. Will merge this now since it's just a compilation fix and that part has succeeded.


fresh install

size: tiny
Problem:
the tests failed with the new viewer, but everything seemed to be running fine. I was able to recreate the error from actions by doing npm ci locally
Solution
I deleted the current package-lock and did a full reinstall

I had to include this update in my other PR so that the tests would pass for that one too. So this is now redundant


Regenerate go.mod indirect dependencies

During the golang version bump we unintentionally introduced a too new
indirect dependency on kube-openapi:
<EMAIL_ADDRESS>This is not required by any of our direct deps and this is also a
version that required golang 1.21. If your system has golang 1.21
installed the this dependency might force go mod tidy to change the
golang version in the go.mod file to 1.21.
This patch removed all the indirect dependencies and let go mod tidy to
regenerate them to get rid of the too new kube-openapi version.

recheck memcached havent started

/test dataplane-operator-build-deploy-kuttl

rebased

/retest


Make components for Time and ApproximateTime

By the way google doesn't use mui time picker in gmaps http://cdn.makeuseof.com/wp-content/uploads/2016/07/estimate-traffic-google-maps.jpg?b34c28