From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: DROP DATABASE vs patch to not remove files right away |
Date: | 2008-04-16 14:41:16 |
Message-ID: | 7765.1208356876@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Florian suggested a scheme where the xid and epoch is embedded in the
> filename, but that's unnecessarily complex. We could just make
> relfilenode a 64-bit integer. 2^64 should be enough for everyone.
Doesn't fix the problem unless DB and TS OIDs become int64 too;
in fact, given that we generate relfilenodes off the OID counter,
it's difficult to see how you do this without making *all* OIDs
64-bit.
Plus you're assuming that the machine has working 64-bit ints.
There's a large difference in my mind between saying "bigint
doesn't work right if you don't have working int64" and "we don't
guarantee the safety of your data if you don't have int64".
I'm not prepared to rip out the non-collision code until such
time as we irrevocably refuse to build on machines without int64.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2008-04-16 14:51:22 | Re: count(*) performance improvement ideas |
Previous Message | Alexander Wöhrer | 2008-04-16 14:36:22 | [Pljava-dev] stack depth limit exceeded - patch possible? |