From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | [BUG?] tuples from file_fdw has strange xids. |
Date: | 2014-07-16 08:04:59 |
Message-ID: | 20140716.170459.194134171.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello, I found that tuples come from file_fdw has strange xmin and xmax.
> 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...
Back to 9.1 gives the same result.
These xmin and xmax are the simple interpretations of a
DatumTupleFields filled by ExecMaterializedSlot() beeing fed the
source virtual tuple slot from file_fdw. On the other hand,
postgres_fdw gives sane xids (xmin = 2, xmax = 0).
This is because ForeignNext returns physical tuples in which
their headers are DatumTupleFields regardless whether the system
columns are requested or not. The fdw machinary desn't seem to
provide fdw handlers with a means to reject requests for
unavailable system columns, so the tuple header should be fixed
with the sane values as HeapTupleFields.
The patch attached fixes the header of materialized tuple to be
sane (2, 0) if the source slot was a virtual tuple in mechanism().
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
nodeForeignScan_tuphead_fix_v1.patch | text/x-patch | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2014-07-16 08:13:04 | BUFFER_LOCK_EXCLUSIVE is used in ginbuildempty(). |
Previous Message | Petr Jelinek | 2014-07-16 08:04:13 | Re: Built-in binning functions |