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.Grittner@wicourts.gov> wrote:
> Gerhard Hintermayer <gerhard.hintermayer@gmail.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