Re: [HACKERS] BRIN index bug due to WAL refactoring

2015-06-26 Thread Alvaro Herrera
Jeff Janes wrote: > The way the blkno and buffer refer to different block/buffers is pretty > confusing. Could we rename a variable to make it clearer which buffer's > number is contained in blkno? Sure thing. Pushed that way. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ Postg

Re: [HACKERS] BRIN index bug due to WAL refactoring

2015-06-26 Thread Jeff Janes
On Fri, Jun 26, 2015 at 11:35 AM, Alvaro Herrera wrote: > Jeff Janes wrote: > > > On replica: > > > > set enable_seqscan TO off; > > explain (analyze) select count(*) from foobar ; > > ERROR: corrupted BRIN index: inconsistent range map > > Nice. As I understand it, the problem is that the repl

Re: [HACKERS] BRIN index bug due to WAL refactoring

2015-06-26 Thread Alvaro Herrera
Jeff Janes wrote: > On replica: > > set enable_seqscan TO off; > explain (analyze) select count(*) from foobar ; > ERROR: corrupted BRIN index: inconsistent range map Nice. As I understand it, the problem is that the replay is using the block number of the revmap page as target blkno of the re

Re: [HACKERS] BRIN index bug due to WAL refactoring

2015-06-25 Thread Alvaro Herrera
Jeff Janes wrote: > BRIN index WAL is broken in HEAD. Thanks for all the details. Looking into it. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

[HACKERS] BRIN index bug due to WAL refactoring

2015-06-25 Thread Jeff Janes
BRIN index WAL is broken in HEAD. Commit 2c03216d831160bedd72d4, the Revamp the WAL record format, is the culprit. The easiest way to see this is via streaming replication. On master: create table foobar as select * from generate_series(1,1); create index on foobar using brin (generate_seri