Re: ERROR: invalid memory alloc request size 18446744073709551613



On Jun 22, 2020, at 8:13 AM, Flaris Feller <flaris.feller@gmail.com> wrote:

Hello all,

When using Postgres 9.6.15 on "CentOS Linux release 7.5.1804 (Core)" on Intel x86_64 I noticed "invalid memory alloc request size" error at PostgreSQL logs.

This is the postgresq.log file's fragment of log where the error was found.

2020-06-22 00:29:18 BRT [16987]: [1-1] db=bxs,user=postgres ERRO:  invalid memory alloc request size 18446744073709551613
2020-06-22 00:29:18 BRT [16987]: [2-1] db=bxs,user=postgres COMANDO:  COPY public.cham_chamada....

PostgreSQL was installed using official PGDG repository through yum.

This is the list of postgresql.conf settings used in the cluster.

listen_addresses = '*'
log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%a.log'
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 0
autovacuum = off
datestyle = 'iso, mdy'
lc_messages = 'pt_BR'                  
lc_monetary = 'pt_BR'                  
lc_numeric = 'pt_BR'                    
lc_time = 'pt_BR'                              
default_text_search_config = 'pg_catalog.portuguese'
max_connections=150
shared_buffers=2GB
effective_cache_size=4GB
work_mem=13981kB
maintenance_work_mem=256MB
log_min_duration_statement = 300000
log_line_prefix = '%t [%p]: [%l-1] db=%d,user=%u '
log_lock_waits = on
timezone='America/Sao_paulo'
log_timezone = 'Brazil/East'
min_wal_size = 1GB
max_wal_size = 2GB

Looking at previous list's messages I've found this could be a data corruption issue and I've followed the recommended procedures.

But even removing the corrupted records, doing a vacuum full and re-indexing the table the problem keep going recurrently.

So I would like some guidance to find the root cause of the table corruption on the database.

Any help would be appreciated.

Thanks in advance,

Flaris Feller.

I there an application generating this value perhaps?

1111111111111111111111111111111111111111111111111111111111111101

Looks a little like a signed/un-signed mismatch