Michael Paquier wrote on 1/26/22 9:14
PM:On Wed, Jan 26, 2022 at 05:30:01PM -0800, Ben Chobot wrote:Other things we've considered:- we run pg_repack, which certainly seems like it could make an error like this, but we see this error in places and times that pg_repack isn't currently runningIt could also take time for the issue to show up, depending on the state of the relcache. So.... tell me more about stale relcaches? It turns out I was totally wrong and this is being driven by pg_repack. I can even make it happen pretty easily: 1. Put some data in a table with a single btree index on a primary db. 2. Set up streaming replication to a secondary db. 3. In a loop on the primary, have pg_repack repack the indices of that table. (the -x flag) 4. In a loop on the secondary, have psql query the secondary db for an indexed value of that table. When I do this with replication, I can get the OID error consistently within 30 minutes. Without replication, I've been unable to get it to happen after 2 hours. Given that this fails much faster on the secondary than the primary (where it has yet to fail at all) I'm leaning towards a postgres bug, but I'm happy to do more research to point the blame at something pg_repack is doing, if you could point me at a thing to research. |
