Re: [HACKERS] Relation cache invalidation on replica - Mailing list pgsql-hackers

From Victor Yegorov
Subject Re: [HACKERS] Relation cache invalidation on replica
Date
Msg-id CAGnEboihavcf2L8MepW6U10qdCjJ=Kbq6+rEXK1rmVwKBi4cOQ@mail.gmail.com
Whole thread Raw
In response to Re: Relation cache invalidation on replica  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: [HACKERS] Relation cache invalidation on replica  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
2016-02-28 11:53 GMT+02:00 Simon Riggs <simon@2ndquadrant.com>:
We have various proposals for fixing this, so on consideration here's what I think we should do...

1. Ignore my first patch to always set an xid. Andres thought that this may break something else could be true, so is not worth the risk.

2. Apply Konstantin's patch to fix this situation for the specific case only.

3. Take Andres' idea and build that in as protection. We currently check that nrels != 0 and throw an ERROR. We should do the same thing if there is an invalidation event, so that we catch errors not just ignore them and issue the commit anyway. This will check that there are no other cases in other code.

I have come across this old thread.

I think we're hitting this particular issue quite frequently when rebuilding indexes on master after big-volume data manipulations.

We have `pgbouncer` in transaction mode for both, master and slave, therefore it's quite typical to have sessions on slave, that
were using indexes before those we're re-created. Sad, but right now maintenance is a big performance hit for our applications,
we have to re-connect them to start using indexes again.

Are there any chances to get fix for this issue released in 10.0 and, perhaps, backpatched also?


--
Victor Yegorov

pgsql-hackers by date:

Previous
From: Nico Williams
Date:
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL
Next
From: Nico Williams
Date:
Subject: Re: [HACKERS] SQL/JSON in PostgreSQL