Yes, Samurai Jack, I mean Ron --- just kidding. That is my preference too.
When you work with several people who are 'Senior' DBA, it's difficult to go to a debate / argument of sort that we should be doing it like this :( Will continue to check things around.
Kinda hoping there are some kind of timestamps when a table / index gets created.
P.S.:
I really wish I can properly learn PostgreSQL hands-on in the real world as a remote intern somewhere.
This is why I do all backups, restores, upgrades, etc through cron.
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
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
-- Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
