[Postgres-xl-bugs] Missing 3 Attribute(s)

Shaun Thomas sthomas at peak6.com
Thu Apr 21 06:23:46 PDT 2016


> Turning off the autovacuum does't prevent this issue just reduce the
> possibility of its occurrence!

If this is the case, Postgres-XL shouldn't even be available for public consumption.
A database that corrupts its own metadata isn't a database; it's a toy. We were going
to use this for a 40-500TB installation, but the series of issues we've run into has put
it on the backburner until Postgres-XL can fix the major problems. What we've
encountered thus far:

1. No Triggers. Fine, we can get around that in a warehouse.
2. SAVEPOINT isn't supported? Sigh. Ok, fine.
3. No ORDER BY in subselects? That's pretty bad and basically breaks
    INSERT INTO ... SELECT DISTINCT ON, as that gets transformed internally to a subquery.
    But we can get around it by using a CTE.
4. Using temporary tables in functions is fine, as long as you don't call the same function
    twice in the same session. Then you get this error "could not open relation with OID 28514".
    That's a regression from Postgres-XC, by the way. So fine, we'll use unlogged tables instead
    because they have stable OIDs.
5. This, where tables will randomly lose all associated attributes. No. That's it. I'm done.

The first few were annoying, the third one was weird and using a CTE to get the same effect
was a little odd, but at least some equivalent functionality was there. The fourth one was
starting to worry me, but I thought we could get around it with unlogged tables, since they
at least have stable OIDs so wouldn't trigger that particular problem. Then our unlogged
tables couldn't be truncated anymore because of "missing attributes." We can't even drop
them and try again, because dropping them results in the same error. That's fine for
unlogged tables, but I can't risk that happening to our actual data.

So I'm reverting our semi-prod conversion and keeping an eye on our QA instance until this
is resolved, and the temp-table reversion is corrected. Bugs where objects get lost and
OIDs are not properly propagated remove the D from ACID, and are not acceptable.

Thanks for reporting this and then the heads-up that there's no way to currently avoid it.

--
Shaun Thomas
PEAK6 Investments, LP | 141 W. Jackson Blvd | Suite 500 | Chicago IL, 60604
312-444-8105
sthomas at peak6.com





______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email




More information about the postgres-xl-bugs mailing list