> Hmm, could you run the above including the system-columns ctid, xmin, > cmin, xmax, cmax?
processing=# select oid, ctid, xmin, cmin, xmax, cmax, id, aid, status
from q_certs where oid = 15282219 ;
oid | ctid | xmin | cmin | xmax | cmax | id
| aid | status
----------+-------+-----------+-----------+-----------+-----------+-----
+-------+--------
15282219 | (3,5) | 174011432 | 1 | 1 | 174214469 | 224
| 23604 | 1
15282219 | (5,5) | 174011432 | 1 | 1 | 174214469 | 224
| 23604 | 1
15282219 | (7,5) | 174011432 | 174700216 | 174700216 | 1 | 224
| 23604 | 1
(3 rows)
Since it wraps, I'll just select those columns :
processing=# select oid, ctid, xmin, cmin, xmax, cmax from q_certs
where oid = 15282219 ;
oid | ctid | xmin | cmin | xmax | cmax
----------+-------+-----------+-----------+-----------+-----------
15282219 | (3,5) | 174011432 | 1 | 1 | 174214469
15282219 | (5,5) | 174011432 | 1 | 1 | 174214469
15282219 | (7,5) | 174011432 | 174700216 | 174700216 | 1
Different results, that's interesting. I'm afraid I don't know what
those columns are for.
> Just for completeness sake, what is _q and what does the trigger do?
_q is the same table structure. I have used inheritance to create new
'queues' yet able to select across them all. I don't actually use this
in production since indexes don't work across inherited tables and it
turned out it was quicker to foreach through all my queues in perl/php
to utilise each tables native indexes and munge the data together
programmatically. That's all by-the-by.
The trigger logs insert and update into another table - my own home
brewed transaction and change log. The transaction table is foreign
keyed to 'id' and includes only one INSERT log, as expected. It was a
good job I didn't foreign key on 'oid' instead :)
Thanks for the info.
--
Rob Fielding
[EMAIL PROTECTED]
www.dsvr.co.uk Development
Designer Servers Business Serve Plc
"I don't pretend to understand Brannigans Law. I merely enforce it"
- Zapp Brannigan
signature.asc
Description: This is a digitally signed message part
