Tom Lane wrote:
> Bill Moran <wmoran at collaborativefusion.com> writes:
>   
>> The full error (with the single modification that I changed the schema
>> name to protect the identity of the DB user):
>> 2009 Aug 26 18:41:06 -04:00 bdb00 [slon][72046] [local2] [err] slon[72046]: [54-1] [72046] ERROR  remoteListenThread_1: "listen "_schema_hidden_Event"; " - ERROR:  could not
>> read block 1 of relation
>> 2009 Aug 26 18:41:06 -04:00 bdb00 [slon][72046] [local2] [err] slon[72046]: [54-2]  1663/5969035/2614: read only 0 of 8192 bytes
>>     
>
> Huh, that's a bit interesting.  Relation 2614 is pg_listener, so it's
> hardly surprising that the command is trying to scan it.  But this
> suggests that something concurrently truncated pg_listener, and that
> should be impossible given the locking that is done.  Has slony
> done anything that changes the locking behavior of LISTEN, VACUUM, etc?
>   
I'm not sure what would modify that behavior; the only "interesting" 
thing about Slony-I's use of pg_listener is that, up thru the 1.2 
branch, every event generated generally raises a notice, so there is the 
potential of quite a lot of updating taking place to pg_listener.

We've removed nearly all of that in 2.0 - it mostly polls, instead - so 
if one is on 2.0, there should be vanishingly little usage of pg_listener.

I'm not sure if that helps; I hope so...