daveg writes:
> We have had this deployed in our test and production environments for a
> couple weeks now. We have not seen any further instance of the problem.
> Without the patch, we would have expected to see at least a few by now.
> So the patch appears to be effective.
Cool, thanks for the
On Fri, Oct 02, 2009 at 07:57:13PM -0700, daveg wrote:
> On Fri, Oct 02, 2009 at 10:41:07AM -0400, Alvaro Herrera wrote:
> > daveg escribió:
> >
> > > I work with Kunal and have been looking into this. It appears to be the
> > > same
> > > as the bug described in:
> > >
> > > http://archives.p
On Fri, Oct 02, 2009 at 10:41:07AM -0400, Alvaro Herrera wrote:
> daveg escribió:
>
> > I work with Kunal and have been looking into this. It appears to be the same
> > as the bug described in:
> >
> > http://archives.postgresql.org/pgsql-bugs/2009-09/msg00355.php
> >
> > as I have localized i
daveg escribió:
> I work with Kunal and have been looking into this. It appears to be the same
> as the bug described in:
>
> http://archives.postgresql.org/pgsql-bugs/2009-09/msg00355.php
>
> as I have localized it to a NULL pointer deference in
> RelationCacheInitializePhase2() as well. Tom
On Tue, Sep 29, 2009 at 09:52:06PM +0530, kunal sharma wrote:
> Hi ,
> We are using Postgres 8.4 and its been found going into recovery
> mode couple of times. The server process seems to fork another child process
> which is another postgres server running under same data directory and aft
gdb backtrce-
(gdb) bt full
#0 0x2ad6d7b8c2b3 in __select_nocancel () from /lib64/libc.so.6
No symbol table info available.
#1 0x005a39bc in ServerLoop () at postmaster.c:1304
timeout = {tv_sec = 55, tv_usec = 352000}
rmask = {fds_bits = {24, 0 }}
selres =
kunal sharma wrote:
Hi ,
We are using Postgres 8.4 and its been found going into
recovery mode couple of times. The server process seems to fork
another child process which is another postgres server running under
same data directory and after some time it goes away while the old
se
