Re: Assertion failure on UNLOGGED VIEW and SEQUENCE

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Assertion failure on UNLOGGED VIEW and SEQUENCE
Date: 2011-02-18 19:10:19
Message-ID: AANLkTimO-RxPBipBfQnLtnEW66Jyez1oz=APiBqvNGqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 18, 2011 at 10:02 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> If by the first option you mean causing the failure report to be "syntax
> error" rather than anything more specific, then I agree that option
> sucks.  I'd actually vote for putting the error test somewhere in
> statement execution code, well downstream of gram.y.  The parser's job
> is to produce a parse tree, not to encapsulate knowledge about which
> combinations of options are supported.

OK. Proposed patch attached. It looks to me like an unlogged view is
inherently nonsensical, whereas an unlogged sequence is sensible but
we don't implement it (and may never implement it, absent some
evidence that the overhead of WAL logging sequence changes is worth
getting excited about), so I wrote the error messages to reflect that
distinction. I also added a couple of matching regression tests, and
documented that UNLOGGED works with SELECT INTO. I put the check for
views in DefineView adjacent to the other check that already cares
about relpersistence, and I put the one in DefineSequence to match, at
the top for lack of any compelling theory of where it ought to go. I
looked at stuffing it all the way down into DefineRelation but that
looks like it would require some other rejiggering of existing logic
and assertions, which seems pointless and potentially prone to
breaking things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment Content-Type Size
unlogged-fixes.patch application/octet-stream 4.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-18 19:12:51 Re: pgsql: Separate messages for standby replies and hot standby feedback.
Previous Message Simon Riggs 2011-02-18 19:07:25 Re: pgsql: Separate messages for standby replies and hot standby feedback.