From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Marti Raudsepp <marti(at)juffo(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: unlogged tables |
Date: | 2010-11-15 16:22:28 |
Message-ID: | AANLkTi=t+ukXuyCJmBhyYJvAKM3WKUQ9R9uFqnjOGeb3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 15, 2010 at 10:54 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> On Sun, Nov 14, 2010 at 02:16, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Here is a series of three patches related to unlogged tables.
>
> Just wondering, have you thought of any mechanisms how application
> code might detect that an unlogged table was truncated due to restart?
> While polling with something like "SELECT 1 FROM table LIMIT 1" might
> work, it's an awful hack.
>
> One obvious use case for these unlogged tables would be materalized
> views. I think it would be useful to execute e.g. a TRUNCATE trigger
> so that an the view could be initialized. If an exclusive lock were
> passed on to the trigger procedure, this could even be done in a
> race-condition-free manner as far as I can tell.
>
> Would there be a problem with invoking this trigger from the session
> that first touches the table?
Yeah, this infrastructure doesn't really allow that. The truncate
happens way too early on in startup to execute any user-provided code.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-15 16:25:15 | Re: unlogged tables |
Previous Message | Andres Freund | 2010-11-15 16:21:07 | Re: [PATCH] Custom code int(32|64) => text conversions out of performance reasons |