Skip site navigation (1) Skip section navigation (2)

Re: BUG #6041: Unlogged table was created bad in slave node

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Emanuel <postgres(dot)arg(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #6041: Unlogged table was created bad in slave node
Date: 2011-06-07 22:06:18
Message-ID: BANLkTikt5E74LBSL6h_PoiOY1F3dpqOBqw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On Tue, Jun 7, 2011 at 5:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> It might be that it'd be best just to have both the planner and executor
>>> throwing errors on unlogged tables, rather than rejiggering pieces of
>>> the planner to sort-of not fail on an unlogged table.
>
>> Mmm, that's not a bad thought either.  Although I think if we can be
>> certain that the planner will error out, the executor checks aren't
>> necessary.  It would disallow preparing a statement and then executing
>> it after promotion, but that doesn't seem terribly important.  Any
>> idea where to put the check?
>
> Well, I'd recommend keeping the test in ExecOpenScanRelation, since it's
> cheap insurance against the situation changing since the plan was made.

Well, the system can't very well go back into recovery once it's
emerged.  I guess it's possible that a table could be switched from
LOGGED to UNLOGGED during recovery though, in some hypothetical future
release.  No one's proposed that feature yet, but since there IS a
proposal to go the other way it doesn't seem unlikely we may see the
other direction eventually too.  I can't get too excited about
blocking this in multiple places just for the sake of preserving a
nicer error message in the face of a possible future feature
development, though.

> But for the planner, why not just put the same kind of test in
> get_relation_info, just after it does heap_open?

OK, let me try that.

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

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2011-06-07 22:14:04
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous:From: Robert HaasDate: 2011-06-07 21:58:49
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch

pgsql-bugs by date

Next:From: The Fuzzy ChefDate: 2011-06-07 23:18:40
Subject: psql's \copy incompatible with :variables
Previous:From: Tom LaneDate: 2011-06-07 21:05:06
Subject: Re: BUG #6041: Unlogged table was created bad in slave node

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group