On 10-09-21 04:08 PM, Aleksey Tsalolikhin wrote:
> Yesterday, I had twelve thousand  "cache lookup failed for type N"
> messages, like this:
>
> 2010-09-20 00:00:00 PDT ERROR:  cache lookup failed for type 14237017
> 2010-09-20 00:00:00 PDT CONTEXT:  SQL statement "INSERT INTO
> mycluster.sl_log_2 (log_origin, log_xid, log_tableid, log_actionseq,
> log_cmdtype, log_cmddata) VALUES (1, $1, $2,
> nextval('mycluster.sl_action_seq'), $3, $4);"
>
> The context is always Slony sl_log_2 table.  All twelve thousand
> errors occurred within 40 minutes.  This did happen right after a
> Slony cluster set drop and recreate.
>
> What does "type 14237017" mean?  What cache are we talking about?
>
> I am concerned because of PostgreSQL classification of ERROR rather
> than WARNING.  What does this mean?  I want to understand what
> happened if there is anything I can do about it.
>

I'm assuming you got these errors on the master.


What I suspect happened was this.

1.  Your application created a database connection and did some inserts 
on replicated tables.  This caused the slony log triggers to prepare a 
plan for inserting data into sl_log_1.  This database connection stayed 
open.
2. You uninstalled slony on the database. This dropped sl_log_1
3. You reinstalled slony on this database.  It recreated sl_log_1
but with a different oid.
4. Your application connection from (1) did something else on a
replicated table that caused the log_trigger to fire.
The C shared library was still loaded in the backend and it
tries to re-use the plan from 1 that is pointing at the old
sl_log_1 table (which no longer exists, since you deleted it).

This is an  ERROR because the slony trigger isn't letting the 
transaction proceed.  (I would expect you to also find errors in your 
application logs at this time).

If your application disconnects from the database and reconnects (after 
the slony re-install) you will get a new database connection with a new 
plan that points at the correct sl_log_1.  If your using a connection 
pool you will also need to cycle the connection pool to force reconnections.





> PostgreSQL 8.4.4
> Slony1 1.2.20
>
> Thanks,
> Aleksey
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general