Re: [HACKERS] Relation cache invalidation on replica

2017-04-19 23:08 GMT+03:00 Andres Freund : > I was thinking of c6ff84b06a68b71719aa1aaa5f6704d8db1b51f8 > Thanks a lot! I found, that this got into 9.6 already via the Release Notes: https://www.postgresql.org/docs/current/static/release-9-6.html#AEN131397 Will certainly

Re: [HACKERS] Relation cache invalidation on replica

On 2017-04-19 17:07:49 +0300, Victor Yegorov wrote: > 2017-03-13 9:22 GMT+02:00 Andres Freund : > > > >I think we're hitting this particular issue quite frequently when > > >rebuilding indexes on master after big-volume data manipulations. > > > > > >We have `pgbouncer` in

Re: [HACKERS] Relation cache invalidation on replica

2017-03-13 9:22 GMT+02:00 Andres Freund : > >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

Re: [HACKERS] Relation cache invalidation on replica

On March 12, 2017 11:22:22 PM PDT, Victor Yegorov wrote: >2016-02-28 11:53 GMT+02:00 Simon Riggs : > >> 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

Re: [HACKERS] Relation cache invalidation on replica

2016-02-28 11:53 GMT+02:00 Simon Riggs : > 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

Re: [HACKERS] Relation cache invalidation on replica

On 27 February 2016 at 07:52, Konstantin Knizhnik wrote: > On 02/27/2016 04:16 AM, Simon Riggs wrote: > > On 27 February 2016 at 00:33, Simon Riggs wrote: > >> On 27 February 2016 at 00:29, Andres Freund wrote: >> >>> On

Re: [HACKERS] Relation cache invalidation on replica

On 02/27/2016 04:16 AM, Simon Riggs wrote: On 27 February 2016 at 00:33, Simon Riggs > wrote: On 27 February 2016 at 00:29, Andres Freund > wrote: On 2016-02-26 18:05:55 +0300,

Re: [HACKERS] Relation cache invalidation on replica

On 2016-02-27 01:45:57 +, Simon Riggs wrote: > Surely then the fix is to make heap_inplace_update() assign an xid? That > way any catalog change will always generate a commit record containing the > invalidation that goes with the change. No need to fix up the breakage > later. Well, we

Re: [HACKERS] Relation cache invalidation on replica

On 27 February 2016 at 01:23, Andres Freund wrote: > On 2016-02-27 01:16:34 +, Simon Riggs wrote: > > If the above is true, then the proposed fix wouldn't work either. > > > > No point in sending a cache invalidation message on the standby if you > > haven't also written

Re: [HACKERS] Relation cache invalidation on replica

On 2016-02-27 01:16:34 +, Simon Riggs wrote: > If the above is true, then the proposed fix wouldn't work either. > > No point in sending a cache invalidation message on the standby if you > haven't also written WAL, since the catalog re-read would just see the old > row. > >

Re: [HACKERS] Relation cache invalidation on replica

On 27 February 2016 at 00:33, Simon Riggs wrote: > On 27 February 2016 at 00:29, Andres Freund wrote: > >> On 2016-02-26 18:05:55 +0300, Konstantin Knizhnik wrote: >> > The reason of the problem is that invalidation messages are not >> delivered to >>

Re: [HACKERS] Relation cache invalidation on replica

On 27 February 2016 at 00:29, Andres Freund wrote: > On 2016-02-26 18:05:55 +0300, Konstantin Knizhnik wrote: > > The reason of the problem is that invalidation messages are not > delivered to > > replica after the end of concurrent create index. > > Invalidation messages are

Re: [HACKERS] Relation cache invalidation on replica

On 2016-02-26 18:05:55 +0300, Konstantin Knizhnik wrote: > The reason of the problem is that invalidation messages are not delivered to > replica after the end of concurrent create index. > Invalidation messages are included in xlog as part of transaction commit > record. > Concurrent index create

Re: [HACKERS] Relation cache invalidation on replica

The reason of the problem is that invalidation messages are not delivered to replica after the end of concurrent create index. Invalidation messages are included in xlog as part of transaction commit record. Concurrent index create is split into three transaction, last of which is just

Re: [HACKERS] Relation cache invalidation on replica

This is obviously a bug because without "concurrently" create index this do not reproduce. --- Dmitry Vasilyev Postgres Professional: http://www.postgrespro.com Russian Postgres Company 2016-02-26 16:36 GMT+03:00 Alexander Korotkov : > On Fri, Feb 26, 2016 at 3:41 PM,

Re: [HACKERS] Relation cache invalidation on replica

On Fri, Feb 26, 2016 at 3:41 PM, Васильев Дмитрий wrote: > Session opened on replica doesn't see concurrently created indexes at this > time on master. > As I get, on standby index is visible when you run SQL queries on catalog tables (that is what \d+ does), but

[HACKERS] Relation cache invalidation on replica

Session opened on replica doesn't see concurrently created indexes at this time on master. We have master and replica: 1. master: pgbench -i -s 10 2. replica: explain (analyze,verbose) select * from pgbench_accounts where abalance = 1; 3. master: ALTER INDEX pgbench_accounts_abalance_idx