From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: cloudNativePg bootstrap from dump |
Date: | 2024-05-10 17:45:37 |
Message-ID: | CANzqJaBf69-+stEP=uDXXgBJtkbEgnMmWgMaBw4O97P0oV+dUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Fri, May 10, 2024 at 12:16 PM Alessandro Dentella <
sandro(dot)dentella(at)gmail(dot)com> wrote:
>
>
> Il giorno ven 10 mag 2024 alle ore 17:49 Scott Ribe <
> scott_ribe(at)elevated-dev(dot)com> ha scritto:
>
>> Is it possible that it is not stuck, but simply processing rows of a
>> large table? Try with the -e option, then you'll see.
>
>
> I'd say no. based on the fact tat If I query the dimension with \l+ I see
> 85 MB, that is exactly the same dim I find in a db initialized with the
> same dump. where the import finishes correctly (not in k8s).
>
> On the other side If I add -e and look at the issued SQL statement, many
> create table statement are missing (but the table are there).
>
iotop and pg_stat_activity will tell you what is (or is not) happening.
From | Date | Subject | |
---|---|---|---|
Next Message | Wells Oliver | 2024-05-10 18:40:37 | Re: Request for featu VACUUM FULL updates pg_stat_all_tables.last_vacuum |
Previous Message | Wells Oliver | 2024-05-10 16:20:28 | Re: Observation with Postgres table size |