| From: | Furkan Shaikh <fs626261(at)gmail(dot)com> |
|---|---|
| To: | Edwin UY <edwin(dot)uy(at)gmail(dot)com> |
| Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_restore Question |
| Date: | 2025-06-21 12:58:39 |
| Message-ID: | CADqJLbWH4xgTGOWG+FMCEkJvyswsEa3g__keRXaAXXTRiaiY7A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
-
*No Definitive Proof:* Without logs, you cannot get a timestamped log
entry saying "pg_restore started/finished." All these methods provide
indirect evidence.
-
*Requires Prior Knowledge:* Most effective indicators rely on you having
some memory or previous records of the database's state (e.g., typical
sequence values, expected bloat, average last-vacuum times).
-
*Other Causes:* Some of these patterns (like recent statistics) could
also be caused by an aggressive VACUUM FULL, a major data import through
other means, or an application bug that resets sequences.
Conclusion
The most reliable indicators without direct logs are a *sudden and uniform
resetting of last_vacuum/last_analyze timestamps to NULL or very recent
values across all user tables*, combined with a potential change in object
OIDs (if you tracked them) or unexpected sequence values. If you see most
of your tables
On Sat, 21 Jun, 2025, 3:41 pm Edwin UY, <edwin(dot)uy(at)gmail(dot)com> wrote:
> Hi,
>
> Without access to the dumpfile or log file, is there any way to check
> whether a database has been restore either by pg_restore or other means?
>
> Regards,
> Edd
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Janes | 2025-06-21 17:28:55 | Re: FATAL: connection requires a valid client certificate |
| Previous Message | Edwin UY | 2025-06-21 10:10:52 | pg_restore Question |