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

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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 06:57:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
On Wed, Jun 1, 2011 at 7:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, May 26, 2011 at 12:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>> Excerpts from Euler Taveira de Oliveira's message of jue may 26 12:00:05 -0400 2011:
>>>> I think we should emit the real cause in those cases, if possible (not too
>>>> much overhead). The message would be "Unlogged table content is not available
>>>> in standby server".
>>> I guess what it should do is create an empty file in the slave.
>> Probably it should, because won't the table malfunction after the slave
>> is promoted to master, if there's no file at all there?  Or will the
>> process of coming live create an empty file even if there was none?
> Coming live creates an empty file.
>> But Euler is pointing out a different issue, which is usability.  If the
>> slave just acts like the table is present but empty, we are likely to
>> get bug reports about that too.  An error telling you you aren't allowed
>> to access such a table on slaves would be more user-friendly, if we can
>> do it without too much pain.
> I looked into this a bit.  A few observations:
> (1) This problem is actually not confined to unlogged tables;
> temporary tables have the same issue.  For example, if you create a
> temporary table on the master and then, on the slave, do SELECT * FROM
>  pg_temp_3.hi_mom (or whatever the name of the temp schema where the
> temp table is) you get the same error.  In fact I suspect if you took
> a base backup that included the temporary relation and matched the
> backend ID you could even manage to read out the old contents (modulo
> any fun and exciting XID wraparound issues).  But the problem is of
> course more noticeable for unlogged tables since they're not hidden
> away in a special funny schema.

Seems like you're trying to fix the problem directly, which as you
say, has problems.

At some point we resolve from a word mentioned in the FROM clause to a

Surely somewhere there we can notice its unlogged before we end up
down in the guts of smgr?

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Dave PageDate: 2011-06-07 07:09:13
Subject: Re: reducing the overhead of frequent table locks - now, with WIP patch
Previous:From: HuangQiDate: 2011-06-07 06:53:13
Subject: Re: gdb with postgres

pgsql-bugs by date

Next:From: Anton DedovDate: 2011-06-07 09:30:28
Subject: ON DELETE CASCADE with multiple paths in PostgreSQL 9.x
Previous:From: Alvaro HerreraDate: 2011-06-07 04:30:57
Subject: Re: [BUGS] BUG #6041: Unlogged table was created bad in slave node

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