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 check this out soon!
--
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 transaction mode for bot
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 quite typical to have ses
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 an xid. Andres thought that
>this
>> may bre
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 worth the risk.
>
> 2. App
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 2016-02-26 18:05:55 +0300, Konstantin Knizhnik wrote:
>>> > The reason of
On 02/27/2016 04:16 AM, Simon Riggs wrote:
On 27 February 2016 at 00:33, Simon Riggs mailto:si...@2ndquadrant.com>> wrote:
On 27 February 2016 at 00:29, Andres Freund mailto:and...@anarazel.de>> wrote:
On 2016-02-26 18:05:55 +0300, Konstantin Knizhnik wrote:
> The reason of
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 could,
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 WAL, since the catalo
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.
>
> heap_inplace_upda
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
>> > replica after the end of concurrent create
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 included in xlog as
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
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 performin
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, Васильев Дмитрий <
> d.vasi
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 planner doesn't pick it. Assumin
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 RENAME
17 matches
Mail list logo
