Thanks to everyone!
I will file a bug.
Anyways, I just built a tool to work-around it all. It allows to run psql
from processes which don't handle SIGINT in a proper shell-like manner
(like yarn for instance): https://github.com/dimikot/run-in-separate-pgrp
Basically, without this, an attempt
sa.sa_mask = mask;
sa.sa_flags = SA_SIGINFO;
sigaction(SIGINT, , NULL);
while (wait(NULL) == -1);
} else {
if (execl("./my1.pl", "my1", NULL) == -1) {
perror("execl");
}
}
return 0;
}
On Sat, Apr 13, 2024 at
Hi.
Preamble: this happens in MacOS only (in built-in Terminal and in iTerm2 at
least). In Linux, everything is as expected.
I almost lost my mind today trying to figure out why sending a SIGINT
precisely to a psql interactive process delivers this SIGINT not only to
that psql, but also to its
Hi.
PG13+. Assume we have two identical queries with no arguments (as a plain
text, e.g. passed to PQexec - NOT to PQexecParams!):
- one with "a=X AND b IN(...)"
- and one with "a=X and b=ANY('{...}')
The question: is it guaranteed that the planner will always choose
identical plans for them
Thank you for the detailed explanation!
I doubt many people from -general would actually be able to provide such
info since the spirit of that list is to find work-arounds for problems and
questions at user level rather than dig into the details on how something
actually works.
It's worth adding
Hi.
Suppose on master, I run a *multi-query* using PQexec and save the value
returned by pg_current_wal_insert_lsn:
master_lsn = query(master, "INSERT INTO some VALUES (...); SELECT
pg_current_wal_insert_lsn()")
Then I run a PQexec query on a replica and save the value returned by
