Re: unlogged tables

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

In response to

Responses

Browse pgsql-hackers by date

  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