waits for COPY to finish, and only
then moves that temp files to data area, because of the large transaction
or something. Would be cool to understand the reason.
On Mon, Feb 3, 2025 at 22:31 Amit Kapila wrote:
> On Mon, Feb 3, 2025 at 5:51 PM Dmitry Koterov
> wrote:
> >
> > H
y on the
destination they are different, right after the copying. (There are not a
lot of writes to this table happening on the source happening while copying
BTW.)
Maybe that could hint on why temp files are used?
On Mon, Feb 3, 2025 at 4:21 AM Dmitry Koterov
wrote:
> Here is the list of tmp
/main/base/4
2.3M17/main/base/5
12G 17/main/base/pgsql_tmp
6.3G17/main/pg_wal
So the question, why does it use temp files. Why not just writes directly
to WAL+data.
On Mon, Feb 3, 2025 at 3:04 AM Dmitry Koterov
wrote:
> Hi.
>
> 1. Those are temp files on the destination n
when copying) definitely helps with
temp files.
Thanks!
On Sun, Feb 2, 2025 at 19:10 Amit Kapila wrote:
> On Sun, Feb 2, 2025 at 5:13 PM Dmitry Koterov
> wrote:
> >
> > Trying to monitor perf during the initial tablesync phase (COPY) right
> after CREATE SUBSCRIPTION. I not
Hi.
Trying to monitor perf during the initial tablesync phase (COPY) right
after CREATE SUBSCRIPTION. I noticed that the size
of 17/main/base/pgsql_tmp on the destination node grows (tens of gigabytes)
as the COPY command (running internally on the publisher) progresses. Then
in the end (when its
Hi.
Debugging some replication lag on a replica when the master node
experiences heavy writes.
PG "startup recovering" eats up a lot of CPU (like 65 %user and 30 %sys),
which is a little surprising (what is it doing with all those CPU cycles?
it looked like WAL replay should be more IO bound than
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 to
sigemptyset(&mask);
sa.sa_sigaction = &handler;
sa.sa_mask = mask;
sa.sa_flags = SA_SIGINFO;
sigaction(SIGINT, &sa, NULL);
while (wait(NULL) == -1);
} else {
if (execl("./my1.pl", "my1", NULL) == -1) {
perror("execl");
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 pa
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 (or
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
pg_last_wal_re
12 matches
Mail list logo
