hi Peter,
today, we took the dump of database and restored to another empty cluster
and run the queries on it for test purposes, no problem at all. All errors
are gone.
>
> > As I mentioned earlier, if this takes too long, you could only do
> > heapallindexed checking once per table (not once per index) by giving
> > "indisprimary" as the heapallindexed argument. That way, only primary
> > keys would be verified against the heap, which is potentially a lot
> > fas
On Sun, Dec 31, 2017 at 1:39 PM, Peter Geoghegan wrote:
> SELECT bt_index_check(index => c.oid, heapallindexed => true),
> c.relname,
> c.relpages
> FROM pg_index i
> JOIN pg_opclass op ON i.indclass[0] = op.oid
> JOIN pg_am am ON op.opcmethod = am.oid
> JOIN pg_class
On Sun, Dec 31, 2017 at 1:10 PM, Ibrahim Edib Kokdemir
wrote:
> 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
> empt
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
On Sun, Dec 31, 2017 at 1:50 PM, Ibrahim Edib Kokdemir
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
Hi,
We are getting same error a lot for more than 1 days from different schemas
in the same db.
< user=myuser db=mydb host=mydbip pid=18883 app=[unknown] time=2017-12-31
14:28:16.056 +03 > ERROR: invalid memory alloc request size
576460752438159360
CentOS Linux release 7.4.1708 (Co
