-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> You think it is because slony is poking around pg_catalog.
>> schema, and it shouldn't , basically ?
> No, Slony 1.2.x pokes around in pg_catalog because in versions
> of postgres prior to 8.3 (which 1.2.x has to support) there was
> no bu
2010/5/12 Glyn Astill :
> --- On Wed, 12/5/10, Grzegorz Jaśkiewicz wrote:
>
>> Alban Hertroys
>>
>> wrote:
>> > On 12 May 2010, at 12:01, Glyn Astill wrote:
>> >
>> >> Did you not mention that this server was a slony
>> slave at some point though?
>> >>
>> >> Just because you have removed slony,
--- On Wed, 12/5/10, Grzegorz Jaśkiewicz wrote:
> Alban Hertroys
>
> wrote:
> > On 12 May 2010, at 12:01, Glyn Astill wrote:
> >
> >> Did you not mention that this server was a slony
> slave at some point though?
> >>
> >> Just because you have removed slony, and the error
> comes from postgresq
On Wed, May 12, 2010 at 11:09 AM, Alban Hertroys
wrote:
> On 12 May 2010, at 12:01, Glyn Astill wrote:
>
>> Did you not mention that this server was a slony slave at some point though?
>>
>> Just because you have removed slony, and the error comes from postgresql
>> itself does not mean the corru
I wonder if "when we ere adding/removing slony to the system for Nth
time (due to it sometimes going out of sync)" may be caused by that as well.
> --- On Wed, 12/5/10, Grzegorz Jaśkiewicz wrote:
>
>> From: Grzegorz Jaśkiewicz
>> Subject: Re: [GENERAL] 8.3.7, 'c
--- On Wed, 12/5/10, Grzegorz Jaśkiewicz wrote:
> Glyn Astill
> wrote:
> > Hi Grzegorz,
> >
> > Is it always the same OID(s)?
> >
> > Usually this means something somewhere has a link to
> an OID that has been removed.
> >
> > You could try digging through pg_catalog lookng for an
> oid column th
orz Jaśkiewicz
> Subject: Re: [GENERAL] 8.3.7, 'cache lookup failed' for a table
> To: "Alban Hertroys"
> Cc: pgsql-general@postgresql.org
> Date: Wednesday, 12 May, 2010, 10:57
> no it is not slony related.
> It is a postgresql problem.
>
> my original post:
On Wed, May 12, 2010 at 10:57 AM, Glyn Astill wrote:
> Hi Grzegorz,
>
> Is it always the same OID(s)?
>
> Usually this means something somewhere has a link to an OID that has been
> removed.
>
> You could try digging through pg_catalog lookng for an oid column that refers
> to the OID in questio
no it is not slony related.
It is a postgresql problem.
my original post:
http://archives.postgresql.org/pgsql-general/2010-05/msg00402.php
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> From: Grzegorz Jaśkiewicz
> Subject: Re: [GENERAL] 8.3.7, 'cache lookup failed' for a table
> To: pgsql-general@postgresql.org
> Date: Wednesday, 12 May, 2010, 10:33
> anyone please ?
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresq
On 11 May 2010, at 16:19, Grzegorz Jaśkiewicz wrote:
> Another thing that makes me think so, is what I've seen in pg_dump's output:
>
> CREATE TRIGGER _simreplic_denyaccess_208
>BEFORE INSERT OR DELETE OR UPDATE ON some_table
>FOR EACH ROW
>EXECUTE PROCEDURE 28799('_somereplic');
>
>
anyone please ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Having seen that all previous problems went unresolved, heres a bit
more info. The system is 32 bit, running on enterprise redhat 4.7. It
is slony's slave node, so it will be hit with quite few updates.
My guess is that it happened when we ere adding/removing slony to the
system for Nth time (due t
I got that sort of error on 8.3.7 (can't upgrade really), is it
something that can be easily resolved ? I do understand that OID is
gone from the pg catalogue , but still in memory.
Will restart of database help in this case ? Was it fixed in
following revisions ?? (8.3.x, x>7).
--
GJ
--
Se
14 matches
Mail list logo
