Re: cloudNativePg bootstrap from dump
| От | Alessandro Dentella |
|---|---|
| Тема | Re: cloudNativePg bootstrap from dump |
| Дата | |
| Msg-id | CAFhgWoKb7nFhHteZC9x14t9i7WPvr1UBBuMvBGgtQ=d6-vjNsA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: cloudNativePg bootstrap from dump (Scott Ribe <scott_ribe@elevated-dev.com>) |
| Ответы |
Re: cloudNativePg bootstrap from dump
Re: cloudNativePg bootstrap from dump |
| Список | pgsql-admin |
Il giorno ven 10 mag 2024 alle ore 17:49 Scott Ribe <scott_ribe@elevated-dev.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).
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).
В списке pgsql-admin по дате отправления: