Re: BUG #8578: loading a 33G (compressed) pg_dump into a fresh host and db instance crashes a postgresql process

re: *work_mem. They are the defaults. In fact, i only changed
checkpoint_segments to 64 because of too frequent checkpointing. All others
are still the defaults.

re: PostGIS. Yes, the table has 3 geometries. Most of the database is
tables with geometries and some are far larger than that one and most of
the largest will have been loaded before that one.

It's running again after changing the sysctl setting and i'm monitoring
memory. Will keep you posted.

Thanks

On Tue, Nov 5, 2013 at 9:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Nix <robert(at)urban4m(dot)com> writes:
> > Thanks for the quick response, Tom. Sure enough. I found the OOM message
> in
> > syslog. And thanks for the link. I'll try those suggestions. Just out of
> > curiosity, will using psql -f alter the behavior, in this case, with
> > respect to memory?
>
> No, since the memory consumption was happening on the server side.
>
> It is somewhat of interest why you're apparently getting a memory leak on
> the server side, though. Maybe you were using an unsafely large work_mem
> or maintenance_work_mem setting? I've also seen some reports lately
> suggesting that PostGIS might cause intra-query memory leaks, which might
> explain this if data_partitions.zone_municipality_demog_houston contains
> any PostGIS data types.
>
> regards, tom lane
>

--
.nix