Re: Re: multiple hot standby streaming replication scenario with "rotating" the primary server

On Mon, Apr 11, 2011 at 7:25 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Gerhard Hintermayer <gerhard(dot)hintermayer(at)gmail(dot)com> wrote:
>
>> Because tests & docs say so:
>>
> http://www.postgresql.org/docs/9.0/static/continuous-archiving.html#CONTINUOUS-ARCHIVING-CAVEATS
>
> I asked because I didn't remember any mention of hashed indexes.  I
> still don't know for sure that you have any, much less that you have
> so many that it makes sense to reindex the entire database.
>
> Or are you saying you've seen a problem with indexes of other types?
>
> -Kevin
>

I have e.g. a table with:

Table "public.auftrag_l1"
Column | Type | Modifiers
------------+------------------------+-----------
a_nr | integer |
sub_nr | integer |
ch_nr_ofm | real |
case_nr | integer |
datum | date |
zeit | time without time zone |
dauer | integer |
print | text |
format | character(1) |
gramm | real |
brand | text |
outrate | smallint |
reliab | smallint |
tech | character varying(3) |
gramm_dekl | real |
ch_nr_fl | real |
ch_nr | real |
fuell_gew | real |
p_code | text |
Indexes:
"idx_auftrag_l1" hash (a_nr)

when I do query this table on the newly awakened primary with
something like a_nr=1234, I get an empty result, but when I query all
tuples and manually search for the one with a_nr=1234, I see that the
tuple is there.
Seeing this and reading the docs about the caveats I see no other
solution as to REINDEX all of my DB's :-(
I have lot's of tables with primary key a_nr as above (though I know
it is not reflected in the table definition, but should result in the
same result, i.e. a_nr integer PRIMARY KEY would create an index to
lookup the table).

Gerhard