"PostgreSQL 8.2.4 on i386-pc-solaris2.10, compiled by
GCC gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)"


Week-old install....still tuning and tweaking this
thing.

Over last 2 days, have spotted 10 "Out of Memory"
errors in postgres logs (never saw before with same
app/usage patterns on tuned hardware/postgres under
FreeBSD)

Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
local0.warning] [6-1] 2007-08-22 18:08:24 CDT   ERROR:
 out of memory.
Aug 22 18:08:24 db-1 postgres[16452]: [ID 748848
local0.warning] [6-2] 2007-08-22 18:08:24 CDT  
DETAIL:  Failed on request of size 536870910.

What I found interesting is that It's ALWAYS the same
size....536870910

I am running autovacuum and slony.....but I see
nothing in the logs anywhere near the "out of memory"
errors related to either (autovacuum used to under
8.0.X log INFO messages every time it vacuumed which
came in handy...I assume it doesn't so this any more?)
 

The events are fairly spread out...and cannot (by
looking at app logs and rest of DB logs) correlate to
any specific query or activity.

Any help would be appreciated

Box is a Sun X4600 with 8 dual-core processors and 32
gig of ram.

# su - pgsql
Sun Microsystems Inc.   SunOS 5.10      Generic
January 2005
-bash-3.00$ ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 256
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 10240
cpu time             (seconds, -t) unlimited
max user processes            (-u) 16357
virtual memory        (kbytes, -v) unlimited

shared_buffers = 3GB                    # min 128kB or
max_connections*16kB
temp_buffers = 1000                     # min 800kB  
was 8MB
max_prepared_transactions = 450         # can be 0 or
more
work_mem = 100MB                                # min
64kB
maintenance_work_mem = 512MB            # min 1MB
#max_stack_depth = 2MB                  # min 100kB
max_fsm_pages = 208000          # min
max_fsm_relations*16, 6 bytes each
max_fsm_relations = 10000               # min 100, ~70
bytes each
#max_files_per_process = 1000           # min 25
#shared_preload_libraries = ''          # (change
requires restart)
fsync = on                              # turns forced
synchronization on or off
wal_sync_method = fdatasync             # the default
is the first option
full_page_writes = off                  # recover from
partial page writes
wal_buffers = 2300                      # min 32kB
commit_delay = 10                       # range
0-100000, in microseconds
#commit_siblings = 5                    # range 1-1000
checkpoint_segments = 128               # in logfile
segments, min 1, 16MB each
checkpoint_timeout = 5min               # range 30s-1h
checkpoint_warning = 99s                # 0 is off


Marko Kreen:

> I've experienced something similar.  The reason turned out to be
> combination of overcommit=off, big maint_mem and several parallel
> vacuums for fast-changing tables.  Seems like VACUUM allocates
> full maint_mem before start, whatever the actual size of the table.

From: Alvaro Herrera
Hmm.  Maybe we should have VACUUM estimate how much is the maximum
amount of memory that would be used, given the size of the table, and
allocate only that much.

From: Tom Lane
Yeah --- given the likelihood of parallel vacuum activity in 8.3,
it'd be good to not expend memory we certainly aren't going to need.

We could set a hard limit at RelationGetNumberOfBlocks *
MaxHeapTuplesPerPage TIDs, but that is *extremely* conservative
(it'd work out to allocating about a quarter of the table's actual size
in bytes, if I did the math right).

Given that the worst-case consequence is extra index vacuum passes,
which don't hurt that much when a table is small, maybe some smaller
estimate like 100 TIDs per page would be enough.  Or, instead of
using a hard-wired constant, look at pg_class.reltuples/relpages
to estimate the average tuple density ...


[COMMITED]

Reduce the size of memory allocations by lazy vacuum when processing a small
table, by allocating just enough for a hardcoded number of dead tuples per
page.  The current estimate is 200 dead tuples per page.

Per reports from Jeff Amiel, Erik Jones and Marko Kreen, and subsequent
discussion.
