Move to Linux. :-) In our case, everything but the database servers
were already Linux so it was an easy choice. Things have been rock
solid since then.
Once things get stuck, I don't think there is an alternative besides
"stop -m immediate". However, since the problem is caused by an idle
backend holding onto an old WAL segment, maybe having your middle
tier/connection pool close and reopen the connections to the database
every so often would function as a workaround. Somebody with more
knowledge of PG internals than I would have to define "every so often"
though (if the idea is viable at all).
>>> "Thomas H." <me(at)alternize(dot)com> 23.10.2006 20:00 >>>
is there any workaround? how did you get around that problem of having
In response to
pgsql-bugs by date
|Next:||From: Tom Lane||Date: 2006-10-23 19:47:14|
|Subject: Re: BUG #2712: could not fsync segment: Permission |
|Previous:||From: Peter Brant||Date: 2006-10-23 18:59:39|
|Subject: Re: BUG #2712: could not fsync segment: Permission|
pgsql-patches by date
|Next:||From: Zdenek Kotala||Date: 2006-10-23 19:43:47|
|Subject: COPY does not work with regproc and aclitem|
|Previous:||From: Tom Lane||Date: 2006-10-23 19:08:03|
|Subject: Re: [PATCHES] smartvacuum() instead of autovacuum |