public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Johnson <[email protected]>
To: Pgsql-admin <[email protected]>
Subject: Re: pg_restore Question
Date: Sun, 22 Jun 2025 12:57:23 -0400
Message-ID: <CANzqJaAkrcTxKfPu_Ui92-ovDwpMf-wSf3n_25+Rf9P+4ZSoDA@mail.gmail.com> (raw)
In-Reply-To: <CA+wokJ_11i8tp-oDMkt_FRcx8xJV7ZOy2QWW80-fWk_bdGHQgw@mail.gmail.com>
References: <CA+wokJ_Qz9DYU39G3ABD6Qu95LjCT3FboYE6aW3yzcxMxSRwnw@mail.gmail.com>
<CADqJLbWH4xgTGOWG+FMCEkJvyswsEa3g__keRXaAXXTRiaiY7A@mail.gmail.com>
<CANzqJaCxnDC=Nzu2cNUCwHhkz3X3-txrh7L6V9OzFbb1Sqp_Sg@mail.gmail.com>
<CA+wokJ_11i8tp-oDMkt_FRcx8xJV7ZOy2QWW80-fWk_bdGHQgw@mail.gmail.com>
It would be handy if pg_class had created_on timestamp, created_by oid,
altered_on timestamp, altered_by oid fields, but alas they don't exist.
On Sun, Jun 22, 2025 at 6:52 AM Edwin UY <[email protected]> wrote:
> 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.
>
> On Sun, Jun 22, 2025 at 9:58 PM Ron Johnson <[email protected]>
> wrote:
>
>> This is why I do all backups, restores, upgrades, etc through cron.
>>
>> On Sat, Jun 21, 2025 at 8:59 AM Furkan Shaikh <[email protected]> wrote:
>>
>>>
>>> -
>>>
>>> *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, <[email protected]> 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
>>>>
>>>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: pg_restore Question
In-Reply-To: <CANzqJaAkrcTxKfPu_Ui92-ovDwpMf-wSf3n_25+Rf9P+4ZSoDA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox