On Tue, 8 Feb 2005, Mike Tamburro wrote:
> Hello,
>
> However, my company is now planning a large scale enterprise database
> system with accompanying API's and web UI's. Of course, I proposed we use
> PostgreSQL again, but one of our technology partners objected.
>
> The objection is the wrap-around problem with XID's. We read together the
> v8.0 docs and saw the work-around solution (section 21.1.3), using the
> VACUUM command. However, our technology partner still warned against using
> PostgreSQL.
Then they have no experience with PostgreSQL, IMHO.
>
> What I need:
>
> 1) More detail on the use of XID's by PostgreSQL, so I can better
> understand the problem.
XIDs provide two mechanisms: they are used to determine data visibility
for concurrent transactions and they allow us to atomically mark data as
commited or aborted.
> 2) An explanation that the work-around is sufficient.
VACUUMing every 500 million transactions is sufficient. Most systems I've
seen would not top 200 transactions per second. This gives you, say, 30
days before you need to vacuum.
I have only come across one installation which had issues with XID
wraparound and that was because they were attempting to load 1 TB a day
and had no time to vacuum.
>
> 3) I see that PostgreSQL has an 8-byte data type (bigint) which would all
> but the solve the problem. Are there any plans to offer 8-byte XID's in
> future versions of PostgreSQL?
It is not as trivial as that. As mentioned abov, we must store a COMMIT or
ABORT bit for transactions. These are stored in a sort of bitmap. If we
had 64 bit XIDs and told people they no longer needed to vacuum (for the
purpose of XID wraparound) we have to accept that the bitmap will grow
toward 2^61 bytes in size -- a very large number. This means, I believe,
that we need a more novel approach to implementing 64 bit XIDs.
Putting that to one side, the fact is that 32 bit XIDs only present a
problem to people who cannot vacuum their systems.
Gavin
