time server - Search results in mailing lists
Mailing lists >> pgsql-bugs >> Thread
2025-04-27 23:51:10 | Postgres 17.4 is much slower than Postgres 15.12 using RECURSIVE (marcos sicat)
TIME zone) WHERE prod.group_name = 'N' ) select * from stock where value is NOT NULL; Server
Mailing lists >> pgsql-bugs >> Thread
2025-04-24 09:04:59 | DSA refcnt overflow in pg_stat/could not attach to dynamic shared area (李园园)
server_node,t.source,t.test_result, t.cost_time,t.process
Mailing lists >> pgsql-bugs >> Thread >> Search in thread (2)
2025-04-17 02:54:23 | Re: BUG #18897: Logical replication conflict after using pg_createsubscriber under heavy load (Zane Duffield)
time > 15 )); then break fi done return 0 ) INSERT_PIDS=() start_insert_threads() { echo "*** STARTING $NUM_THREADS LOOPS INSERTING $INSERT_WIDTH RECORDS PER ITERATION ..." INSERT_PIDS=() for id in $(seq 0 $((NUM_THREADS
Mailing lists >> pgsql-bugs >> Thread
2025-04-12 06:34:59 | BUG #18893: Segfault during analyze pg_database (PG Bug reporting form)
server was lost. Attempting reset: Failed. Time: 3485.895 ms (00:03.486) !?> Backtrace ========= (gdb) bt #0 PopActiveSnapshot
Mailing lists >> pgsql-bugs >> Thread
2025-03-20 18:14:13 | PostgreSQL v15.12 fails to perform PG_UPGRADE from v13 and v9 on Windows (Ben Caspi)
Server 2016, which from our understanding is not supported in v16 and onwards). Upgrading our 15.6 machines to 15.12 has been going smoothly. However, *running PG_UPGRADE on PSQL v9.6/13.13 to v15.12 has been failing
Mailing lists >> pgsql-bugs >> Thread
2025-03-18 14:34:05 | BUG #18854: PostgreSQL chooses a suboptimal execution plan when using a specific WHERE filter (PG Bug reporting form)
server CPU when being ran by dozens of sessions simultaneously) instead of ~3 seconds (when commenting out that specific WHERE filter clause I mentioned below): Query #1 (runtime: ~90 seconds):: SELECT count(*) AS total FROM
Mailing lists >> pgsql-bugs >> Thread
2025-03-06 04:16:57 | BUG #18832: Segfault in GrantLockLocal (PG Bug reporting form)
timing of concurrent queries is relevant, although despite my best efforts I don't know / can't say what else runs concurrently to cause this. Thought I'd share here in case the backtraces helps
Mailing lists >> pgsql-bugs >> Thread
2025-03-05 20:49:38 | BUG #18831: Particular queries using gin-indexes are not interruptible, resulting is resource usage concerns (PG Bug reporting form)
server to a halt, which is what happened in our case. We have 120 seconds for statement timeout, and it was not being honored causing our services to reconnect after another timeout was triggered, created
Mailing lists >> pgsql-bugs >> Thread
2025-02-11 19:26:26 | BUG #18804: LISTEN on channel fails with "could not access status of transaction" (PG Bug reporting form)
times already, but none of the investigations cocluded with a solution except for recommendation to restart postmaster in order to clean up the LISTEN/NOTIFY queue (as far as I understood). This workaround works
Mailing lists >> pgsql-bugs >> Thread
2025-02-05 23:24:52 | Bug in recovery of drop database? (David Steele)
time = '2025-02-05 19:18:26.245167+00'" >> test/data/postgresql.auto.conf test/pg/bin/pg_ctl -D test/data -w start test/pg/bin/psql mytest -c 'select count(*) from pgbench_accounts' psql: error: connection to server
Mailing lists >> pgsql-bugs >> Thread
2024-12-25 22:37:00 | Re: psql v16.3 successfully connects via TLSv1.3 proxy, but psql v16.4 says "tlsv1 alert no (Tom Lane)
servers, and this builder might be following their lead. (The timing would be about right
Mailing lists >> pgsql-bugs >> Thread
2024-12-24 07:36:40 | BUG #18753: Unable to Recover a Deleted Database Using PITR (PG Bug reporting form)
time from log file when insert occurred, see step 2) recovery_target_action = promote 11) Created recovery.signal file in postgres data folder 12) Started postgres server
Mailing lists >> pgsql-bugs >> Thread
2024-12-03 15:23:01 | BUG #18732: Segfault in pgbench on max_connections starvation (PG Bug reporting form)
server with max_connections=900 2. Launch pgbench a couple of times with -c 2000 I was also
Mailing lists >> pgsql-bugs >> Thread
2024-11-25 15:26:52 | BUG #18724: High data disk utilization during log writing (PG Bug reporting form)
server setup looks like this: /dev/vda1 / - System disk - source system packages and utilities (including postgres) /dev/vdb1 /data - Data disk - a separate disk for storing data /dev/vdc1 /var/log/postgresql - Log disk - mounted on the /var/log/postgresql folder /dev/vdd1
Mailing lists >> pgsql-bugs >> Thread
2024-11-22 22:23:47 | Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now (Tom Lane)
time until we find a match in pg_database, relying on the + * assumption that the name as stored in pg_database is valid according to + * some server