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

The sysctl change worked. Thanks for helping, Tom. Very much appreciated.

On Tue, Nov 5, 2013 at 10:05 PM, Robert Nix <robert(at)urban4m(dot)com> wrote:

> 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
>

--
.nix