On Fri, Mar 2, 2012 at 4:15 AM, Nie, Guocong <guocong(dot)nie(at)capgemini(dot)com> wrote:
> I use slony version “slony1-1.2.20” , and postgresql version 9.1
You should really take this over to the Slony mailing list, it's not a
generic Postgres problem.
> LOG: server process (PID 30019) was terminated by signal 11: Segmentation
It seems pretty likely that this indicates some problem with compiling
the C functions for the log triggers. If something goes wrong (which
is a broad matter), and the function accesses an undefined chunk of
memory, that would cause that one backend to have a segmentation
fault, which, as it may invalidate shared memory, leads to the
segfault being passed to the postmaster, which then tells all the
other backends of the problem. Which is consistent with the
phenomenon you are seeing.
I observe that you're running a version that's several years old,
which predates Postgres 9.1.
Version 1.2.20 of Slony was released in December 2009, which was
before either Postgres 9.0 *or* 9.1 were released. And commonly,
enough header stuff changes that we have usually needed to make some
minor modifications to get versions of Slony to work with new PG
I would not expect 1.2.20 to be compatible with Postgres 9.1, and it's
an ancient enough branch that we're not doing much with 1.2 to try to
keep it compatible. I wouldn't recommend using 1.2.20, certainly not
for a new installation. You might want to try Slony 2.0 (better) or
2.1 (quite a lot further better).
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
In response to
pgsql-bugs by date
|Next:||From: Peter Eisentraut||Date: 2012-03-02 18:58:59|
|Subject: Re: BUG #6480: NLS text width problem|
|Previous:||From: j.vreven||Date: 2012-03-02 17:01:37|
|Subject: BUG #6503: Idle in transaction while lazy loading in JSF renderresponse|