Hi Peter, I just installed and used amcheck_next, I have used your sample query on the git page (changed the schema name) and that listed all indexes different schemes and produced same outputs like yours with bt_index_check field as empty, that means no error. Am I doing right?
2017-12-31 16:58 GMT+03:00 Peter Geoghegan <p...@bowt.ie>: > On Sun, Dec 31, 2017 at 1:50 PM, Ibrahim Edib Kokdemir > <kokde...@gmail.com> wrote:> * write_cache is disabled > > * there is no incorrect work_mem parameter setting. > > * logical dump is working, (maybe) no curruption in data. > > * there is streaming replication, we do not repeat the error in the > > replicas. (replicas in different minor versions, 9.6.4, 9.6.3 > accordingly) > > * we have large_object field, logical_dump also works with large_objects > > fields. > > > > Any idea? > > This is very likely to be corruption. It's important to determine the > cause and extent of this corruption. I suggest using amcheck for this, > which is available for those Postgres versions from: > > https://github.com/petergeoghegan/amcheck > > Note that there are Debian and Redhat packages available. > > You'll definitely want to use the "heapallindexed" option here, at > least for primary key indexes (pass "pg_index.indisprimary" as > "heapallindexed" argument, while generalizing from the example SQL > query for bt_index_check()). This process has a good chance of > isolating the problem, especially if you let this list see any errors > raised by the tool. > > -- > Peter Geoghegan >
