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

From Andres Freund
Subject Re: [HACKERS] Relation cache invalidation on replica
Date
Msg-id 8B83B90B-3968-41BF-9309-16F9F37FD56A@anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Relation cache invalidation on replica  (Victor Yegorov <vyegorov@gmail.com>)
Responses Re: [HACKERS] Relation cache invalidation on replica  (Victor Yegorov <vyegorov@gmail.com>)
List pgsql-hackers

On March 12, 2017 11:22:22 PM PDT, Victor Yegorov <vyegorov@gmail.com> wrote:
>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?

I'm not at my computer right now, but I recall committing something like my approach.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Changing references of password encryption to hashing
Next
From: Jeevan Chalke
Date:
Subject: Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]