From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Finding tables dropped by DROP TABLE CASCADE |
Date: | 2011-08-17 01:10:20 |
Message-ID: | CA+TgmoZ7qc2GK9m3BR7CA2tZU72oyaT6gwgkLNa-As5G4ex0RA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 16, 2011 at 8:52 PM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> Presumably it would also need to invalidated if someone did ALTER
>> TABLE (which might recurse into unspecified children).
>
> Good point. For DROP TABLE/ALTER TABLE, I need to take care of its chidren.
>
>> It sort of seems like what you want to do is snoop the sinval traffic...
>
> It's hard for pgpool-II since there's no API in PostgreSQL for
> that. Maybe I will look into the system catalog to find out
> children. I'm not sure if I can deal with CASCADE by the same method
> though.
It's possible, but not too easy.
Maybe we should have a special LISTEN channel that plays back (some
subset of? some decoded version of?) the sinval messaging. I bet the
pgAdmin guys would like an automated way of knowing when tables had
been created/dropped, too...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2011-08-17 01:44:56 | Re: synchronized snapshots |
Previous Message | Robert Haas | 2011-08-17 01:08:48 | Re: synchronized snapshots |