Re: pg_restore Question - Mailing list pgsql-admin

From Furkan Shaikh
Subject Re: pg_restore Question
Date
Msg-id CADqJLbWH4xgTGOWG+FMCEkJvyswsEa3g__keRXaAXXTRiaiY7A@mail.gmail.com
Whole thread Raw
In response to pg_restore Question  (Edwin UY <edwin.uy@gmail.com>)
List 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.uy@gmail.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


pgsql-admin by date:

Previous
From: Edwin UY
Date:
Subject: pg_restore Question
Next
From: Jeff Janes
Date:
Subject: Re: FATAL: connection requires a valid client certificate