|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp, shigeru(dot)hanada(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: inherit support for foreign tables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Sorry, this was no relation with this patch.
ForeignNext materializes the slot, which would be any of physical
and virtual tuple, when system column was requested. If it was a
virtual one, file_fdw makes this, heap_form_tuple generates the
tuple as DatumTuple. The result is a jumble of virtual and
physical. But the returning slot has tts_tuple so the caller
interprets it as a physical one.
Anyway the requests for xmin/xmax could not be prevented
beforehand in current framework, I did rewrite the physical tuple
header so as to really be a physical one.
This would be another patch, so I will put this into next CF if
this don't get any immediate objection.
> By the way, I tried xmin and xmax for the file_fdw tables.
> postgres=# select tableoid, xmin, xmax, * from passwd1;
> tableoid | xmin | xmax | uname | pass | uid | gid | ..
> 16396 | 244 | 4294967295 | root | x | 0 | 0 | root...
> 16396 | 252 | 4294967295 | bin | x | 1 | 1 | bin...
> 16396 | 284 | 4294967295 | daemon | x | 2 | 2 | daemon...
> The xmin and xmax apparently doesn't look sane. After some
> investigation, I found that they came from the following place in
> heap_form_tuple(), (call stach is show below)
NTT Open Source Software Center
|Next Message||Amit Kapila||2014-07-01 06:29:40||Re: Autonomous Transaction (WIP)|
|Previous Message||Pavel Stehule||2014-07-01 06:22:50||Re: Autonomous Transaction (WIP)|