Re: SELECT returning too many rows (?)

> 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
rob(at)dsvr(dot)net

www.dsvr.co.uk Development
Designer Servers Business Serve Plc

"I don't pretend to understand Brannigans Law. I merely enforce it"
- Zapp Brannigan