Re: cloudNativePg bootstrap from dump

Thanks for pointing out that, but alas no news.
pg_stat_activity shows exactly the same rows as before the import, I also
looked at pg_locks, that show nothing new.
Iotop doesn't show anything relevant to me.

Here is the output from postgres, but I think it doesn't say anything
interesting

postgres=# select * from pg_locks;
locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtualtransaction | pid |
mode | granted | fastpath | waitstart
------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-----+-----------------+---------+----------+-----------
relation | 5 | 12073 | | | |
| | | | 3/155 | 104 | AccessShareLock
| t | t |
virtualxid | | | | | 3/155 |
| | | | 3/155 | 104 | ExclusiveLock
| t | t |
(2 rows)

postgres=# select * from pg_stat_activity ;
datid | datname | pid | leader_pid | usesysid | usename |
application_name | client_addr | client_hostname | client_port |
backend_start | xact_start |
query_start | state_change | wait_event_type |
wait_event | state | backend_xid | backend_xmin | query_id |
query | backend_type
-------+----------+-----+------------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+-------------------------------+-------------------------------+------------------------------+-----------------+---------------------+--------+-------------+--------------+----------+----------------------------------+------------------------------
| | 26 | | | |
| | | | 2024-05-11
11:14:05.407952+00 | |
| | Activity | AutoVacuumMain
| | | | |
| autovacuum launcher
| | 28 | | 10 | postgres |
| | | | 2024-05-11
11:14:05.408858+00 | |
| | Activity |
LogicalLauncherMain | | | | |
| logical replication launcher
5 | postgres | 104 | | 10 | postgres | psql
| | | -1 | 2024-05-11
11:14:07.77121+00 | 2024-05-11 11:17:19.589227+00 | 2024-05-11
11:17:19.589227+00 | 2024-05-11 11:17:19.58923+00 | |
| active | | 1192 | | select *
from pg_stat_activity ; | client backend
| | 23 | | | |
| | | | 2024-05-11
11:14:05.395614+00 | |
| | Activity |
BgWriterHibernate | | | | |
| background writer
| | 27 | | | |
| | | | 2024-05-11
11:14:05.408225+00 | |
| | Activity | ArchiverMain
| | | | |
| archiver
| | 22 | | | |
| | | | 2024-05-11
11:14:05.39521+00 | |
| | Activity | CheckpointerMain
| | | | |
| checkpointer
| | 25 | | | |
| | | | 2024-05-11
11:14:05.407708+00 | |
| | Activity | WalWriterMain
| | | | |
| walwriter
(7 rows)

Il giorno ven 10 mag 2024 alle ore 19:45 Ron Johnson <
ronljohnsonjr(at)gmail(dot)com> ha scritto:

> 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.
>
>