Re: Index (primary key) corrupt?

[Adrian Klaver]

On 10/10/25 05:28, Wim Rouquart wrote:

Internal

Hi,

Apologies for the late response, had other fish to fry...

In response to your questions:


What is full(15.x) version of Postgres are you using?


15.14


Is it the community version or a fork or SaaS?


Standard release indeed, running on RHAT8


What do you get for queries below?:



select * from pg_opclass where oid = 3124;


|oid|opcmethod  |opcname|opcnamespace|opcowner  |opcfamily  
|opcintype  |opcdefault |opckeytype
|3124   |403|int8_ops   |11 |10 
|1976   |20 |true   |0


select * from pg_opclass where opcname = 'int8_ops';


|oid|opcmethod  |opcname|opcnamespace   |opcowner   
|opcfamily  |opcintype  |opcdefault |opckeytype|
|3124   |403|int8_ops   |11 |10 
|1976   |20 |true   |0 |
|10021  |405|int8_ops   |11 |10 
|1977   |20 |true   |0 |



Was the above done before or after you did the reindex?

From original post:

"
When doing a pg_dump of one of our databases one of the tables primary 
keys doesn't get exported. Pg_dump just skips this index, without any 
warning whatsoever (verbose mode was used to doublecheck).



When doing a REINDEX the issue is fixed.
"

That would imply that after the successful REINDEX and dump some action 
is taken that makes the index disappear.


What is the table used for?

Are there any sort of 'unusual' operations done on it?




--
Adrian Klaver
adrian.kla...@aklaver.com

Upgrade & Rollback plan: My customer requests rollback via old-version standby (13 ↔ 17) — need community advice

[Vu Le (JData - HN)]

Hi all,

I'm currently planning a major version upgrade from PostgreSQL 13.x to
17.x in a production environment.

My customer has requested the following rollback approach, and I’d
like to confirm if it’s technically feasible or advisable before
proceeding.

Scenario:
1. They have a **Primary–Standby setup** (streaming replication).
2. Their idea is to **upgrade only the Primary** (to v17) first, while
keeping the **Standby** on v13 (the old version).
   - The upgraded Primary will run read/write traffic for about a week
to validate stability.
   - If any serious issue occurs, the plan is to **switch over**
(promote the v13 Standby), adjust IPs, and resume operations there —
minimizing downtime.
3. They also asked whether it’s possible for **data generated on the
v17 Primary** to still be **replicated back to the v13 Standby**, so
that rollback would be fast and without data loss.

Constraints:
- They **cannot use a Blue/Green or clone-based approach**, because of
**limited storage resources**.
- They also doesn’t want the old data directory to become outdated
(they expects it could stay in sync with the upgraded node).
- They only have **UAT and Production environments** (no dedicated Staging).

Questions:
1. Is there **any supported or practical method** to replicate data
*backward* (from PostgreSQL 17 to 13) — even temporarily, for rollback
purposes?
2. If not, what are the **recommended real-world rollback strategies**
for a low-downtime upgrade under these constraints?
3. Are there open-source tools or logical replication setups (e.g.,
pglogical, Bucardo, etc.) that could safely achieve something similar?

Any insight, best practice, or reference architecture from the
community would be very helpful.
Thank you for your time and guidance. Have a good day!

-- 
Best Regards,

Miles Le | Vu (Mr.)