Possible index issue on 9.5 slave - Mailing list pgsql-hackers

From Ian Barwick
Subject Possible index issue on 9.5 slave
Date
Msg-id 53A242D7.5080209@2ndquadrant.com
Whole thread Raw
Responses Re: Possible index issue on 9.5 slave
List pgsql-hackers
Hi

I've just run into an index issue on 9.5 HEAD on a slave (master and slave
both compiled from 66802246e22d51858cd543877fcfddf24e6812f2); details
below (I have only found one index on the slave where the issue occurs so far).
The setup is admittedly slightly unusual; master is OS X 10.7.5, slave is
CentOS on a Virtualbox guest VM on the same system. The issue only occurs
with this combination of master and slave; I haven't been able to reproduce
it with master and slave running natively on OS X, or with a Linux guest VM
on a Linux machine. I have reproduced it several times on the OS X/Linux guest VM
combination.

I can't dig any further into this at the moment but can happily provide further
details etc.

Master
======
   $ uname -a   Darwin nara.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012;
root:xnu-1699.32.7~1/RELEASE_X86_64x86_64
 
   tgg_current=> SELECT version();                                                    version
----------------------------------------------------------------------------------------------------------   PostgreSQL
9.5develon x86_64-apple-darwin11.4.2, compiled by gcc (MacPorts gcc48 4.8.2_2) 4.8.2, 64-bit   (1 row)
 
   tgg_current=> select user_id, login from tgg_user where login ='admin';    user_id | login   ---------+-------
  1 | admin   (1 row)
 


Slave
=====
   $ uname -a   Linux localhost.localdomain 2.6.32-358.el6.x86_64 #1 SMP Fri Feb 22 00:31:26 UTC 2013 x86_64 x86_64
x86_64GNU/Linux
 
   tgg_current=> select version();                                                        version
-----------------------------------------------------------------------------------------------------------------
PostgreSQL9.5devel on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3), 64-bit   (1
row)
   tgg_current=> select user_id,login from tgg_user where login ='admin';    user_id | login   ---------+-------   (0
rows)
   tgg_current=> explain select user_id,login from tgg_user where login ='admin';
QUERY PLAN   ------------------------------------------------------------------------------------    Index Scan using
tgg_user_login_keyon tgg_user  (cost=0.28..8.30 rows=1 width=15)      Index Cond: ((login)::text = 'admin'::text)
Planningtime: 0.105 ms   (3 rows)
 
   tgg_current=> set enable_bitmapscan=off;   SET   tgg_current=> set enable_indexscan =off;   SET   tgg_current=>
selectuser_id,login from tgg_user where login ='admin';    user_id | login   ---------+-------          1 | admin   (1
row)

   tgg_current=> \d tgg_user_login_key          Index "epp.tgg_user_login_key"    Column |         Type          |
Definition  --------+-----------------------+------------    login  | character varying(32) | login   unique, btree,
fortable "epp.tgg_user"
 


Regards

Ian Barwick

-- Ian Barwick                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Matheus de Oliveira
Date:
Subject: Re: How about a proper TEMPORARY TABLESPACE?
Next
From: Tom Lane
Date:
Subject: Re: [bug fix] Memory leak in dblink