On Tue, Jun 7, 2011 at 6:06 PM, Robert Haas wrote:
>> 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.
Seems to work beautifully, so committed that way.
--
Robert Haas
EnterpriseDB: http://www.enterprised
On Tue, Jun 7, 2011 at 5:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane 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-
Robert Haas writes:
> On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane 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
On Tue, Jun 7, 2011 at 3:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> I found a few other holes in my previous patch as well. I think this
>> plugs them all, but it's hard to be sure there aren't any other calls
>> to RelationGetNumberOfBlocks() that could bomb out.
>
> [ squint... ] Do we n
Robert Haas writes:
> I found a few other holes in my previous patch as well. I think this
> plugs them all, but it's hard to be sure there aren't any other calls
> to RelationGetNumberOfBlocks() that could bomb out.
[ squint... ] Do we need those additional tests in plancat.c? I
haven't paid
On Tue, Jun 7, 2011 at 2:05 PM, Robert Haas wrote:
> On Tue, Jun 7, 2011 at 11:50 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Patch along these lines attached.
>>
>> Frankly, I find this quite ugly, and much prefer the general approach of
>> your previous patch in .
>>
>> However, I don't lik
On Tue, Jun 7, 2011 at 11:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> Patch along these lines attached.
>
> Frankly, I find this quite ugly, and much prefer the general approach of
> your previous patch in .
>
> However, I don't like where you put the execution-time test there. I'd
> put it
On Tuesday, June 07, 2011 04:29:02 Robert Haas wrote:
> On Fri, Jun 3, 2011 at 1:01 PM, Alvaro Herrera
>
> wrote:
> > Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011:
> >> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas
wrote:
> >> > (4) It strikes me that it might be possible
Robert Haas writes:
> Patch along these lines attached.
Frankly, I find this quite ugly, and much prefer the general approach of
your previous patch in .
However, I don't like where you put the execution-time test there. I'd
put it in ExecOpenScanRelation instead, so that it covers both seqscan
Alvaro Herrera writes:
> Excerpts from Robert Haas's message of mar jun 07 08:16:01 -0400 2011:
>> Probably. I guess the question is whether we want this to fail in (a)
>> the parser, (b) the planner, or (c) the executor.
> Really? I thought it was the job of the parse analysis phase to figure
Excerpts from Robert Haas's message of mar jun 07 08:16:01 -0400 2011:
> On Tue, Jun 7, 2011 at 2:57 AM, Simon Riggs wrote:
> > 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
>
On Tue, Jun 7, 2011 at 2:57 AM, Simon Riggs wrote:
> 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
> relfilenode.
>
> Surely somewhere there we can notice its unlogged before we end
On Wed, Jun 1, 2011 at 7:28 PM, Robert Haas wrote:
> On Thu, May 26, 2011 at 12:34 PM, Tom Lane wrote:
>> Alvaro Herrera 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 (n
On Fri, Jun 3, 2011 at 1:01 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011:
>> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas wrote:
>
>> > (4) It strikes me that it might be possible to address this problem a
>> > bit more cleanly by allowing mdnbl
Excerpts from Robert Haas's message of vie jun 03 12:44:45 -0400 2011:
> On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas wrote:
> > (4) It strikes me that it might be possible to address this problem a
> > bit more cleanly by allowing mdnblocks() and smgrnblocks() and
> > RelationGetNumberOfBlocksInF
On Wed, Jun 1, 2011 at 2:28 PM, Robert Haas wrote:
> On Thu, May 26, 2011 at 12:34 PM, Tom Lane wrote:
>> Alvaro Herrera 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 (n
On Thu, May 26, 2011 at 12:34 PM, Tom Lane wrote:
> Alvaro Herrera 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
2011/5/26 Euler Taveira de Oliveira :
> Em 26-05-2011 08:37, Emanuel escreveu:
>
>> Description: Unlogged table was created bad in slave node
>>
> Unlogged table contents are not available to slave nodes [1].
>
I know it. But the error raised isn't pretty nice for common users.
IMHO it coul
Alvaro Herrera 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
Excerpts from Euler Taveira de Oliveira's message of jue may 26 12:00:05 -0400
2011:
> Em 26-05-2011 08:37, Emanuel escreveu:
>
> > Description:Unlogged table was created bad in slave node
> >
> Unlogged table contents are not available to slave nodes [1].
>
> > postgres=# select * from
Em 26-05-2011 08:37, Emanuel escreveu:
Description:Unlogged table was created bad in slave node
Unlogged table contents are not available to slave nodes [1].
postgres=# select * from voidy ;
ERROR: could not open file "base/12071/17034": No existe el archivo o
directorio
I think we
The following bug has been logged online:
Bug reference: 6041
Logged by: Emanuel
Email address: postgres@gmail.com
PostgreSQL version: 9.1 beta
Operating system: Ubuntu
Description:Unlogged table was created bad in slave node
Details:
MASTER=
SLAVE SYNC=6667
22 matches
Mail list logo
