Re: BUG #8408: Not exactly correct error messages for failed check in presence of dropped columns. - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #8408: Not exactly correct error messages for failed check in presence of dropped columns.
Date
Msg-id CAB7nPqT6h3drLCb=btkZNnq8Yu5Rkxxg7ioG8XyQLYFPkEzMxg@mail.gmail.com
Whole thread Raw
In response to BUG #8408: Not exactly correct error messages for failed check in presence of dropped columns.  (maxim.boguk@gmail.com)
Responses Re: BUG #8408: Not exactly correct error messages for failed check in presence of dropped columns.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Fri, Aug 30, 2013 at 2:13 PM,  <maxim.boguk@gmail.com> wrote:
> However, I think error message should filter dropped column and strange null
> values (because if a table has a lot dropped column this error message
> quickly become completely unreadable).
Yes, this is not really user-friendly. This comes from
ExecBuildSlotValueDescription@execMain.c when generating a string
representation of a tuple. Attached is a patch to make this function
aware of dropped columns when generating the string (usable down to
9.2). However, after some debugging I am seeing that the dropped
column is not seen inside TupleDesc (only the column name is correct)
when calling this function in executor.
Breakpoint 1, ExecBuildSlotValueDescription (slot=0x7fc26412b8e0,
maxfieldlen=64) at execMain.c:1636
1636        TupleDesc    tupdesc = slot->tts_tupleDescriptor;
(gdb) p *tupdesc->attrs[0]
$1 = {
  attrelid = 0,
  attname = {
    data = "id", '\0' <repeats 61 times>
  },
  atttypid = 23,
  attstattarget = -1,
  attlen = 4,
  attnum = 1,
  attndims = 0,
  attcacheoff = 0,
  atttypmod = -1,
  attbyval = 1 '\001',
  attstorage = 112 'p',
  attalign = 105 'i',
  attnotnull = 0 '\0',
  atthasdef = 0 '\0',
  attisdropped = 0 '\0',
  attislocal = 1 '\001',
  attinhcount = 0,
  attcollation = 0
}
(gdb) p *tupdesc->attrs[1]
$2 = {
  attrelid = 0,
  attname = {
    data = "........pg.dropped.2........", '\0' <repeats 35 times>
  },
  atttypid = 23,
  attstattarget = -1,
  attlen = 4,
  attnum = 2,
  attndims = 0,
  attcacheoff = -1,
  atttypmod = -1,
  attbyval = 1 '\001',
  attstorage = 112 'p',
  attalign = 105 'i',
  attnotnull = 0 '\0',
  atthasdef = 0 '\0',
  attisdropped = 0 '\0',
  attislocal = 1 '\001',
  attinhcount = 0,
  attcollation = 0
}
attisdropped is not set to true, only attname is updated to its new value.

When removing an attribute in RemoveAttributeById, it is written in
comment that updating a pg_attribute row triggers a relcache flush for
target relation, but obviously it is not happening. I am missing
something perhaps?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #8410: out of binary heap slots
Next
From: cme@freefour.com
Date:
Subject: BUG #8432: installation sticks on "initializing the database cluster"