Many thanks for the explanation, Tom and Greg. That all makes sense.
Cheers
Huan
Hi Patrick
Thanks for your reply.
>
>
> My guess is that temp table entries will still be in your catalog until
> you do a VACUUM FULL of the pg_class / pg_attribute tables.
>
> But you should not care about these entries if these tables are vacuumed
> at regular intervals.
>
What I observed in o
Hi All
Let's say at T0 a database has N session based temp tables. They would have
corresponding records in the catalog tables like pg_class and pg_attribute
that are visible to other sessions.
At T1, I do a PITR to T0. That recovered database should not have those
temp tables because the session
Hi Tomas
The records have a timestamp column so we do know the time they were
written. We didn't find any I/O issues that match that time but
unfortunately as it's been a while we are not confident with that finding.
> Are there any other corrupted indexes on the table?
That was one of my first
HI Alvaro
Unfortunately those records were written a while ago and we no longer keep
their WAL logs. Thanks for your help anyway.
Huan
On Fri, 27 Nov 2020 at 08:40, Huan Ruan wrote:
> Thanks Alvaro for pointing me to pageinspect. I will give it a try and
>> report back. It might t
>
> Thanks Alvaro for pointing me to pageinspect. I will give it a try and
> report back. It might take a few days. I knew this module but have never
> tried it before.
>
Hi All
We have a table with 623 million records. It appears a BRIN index of this
table on a timestamp column is missing some records, as illustrated below
in a cut-down version with additional columns and indices omitted.
We cannot work out a reproducible case but we have a copy of the offending
