Marko Kreen <[EMAIL PROTECTED]> writes:
> When will 64bit be a requirement?
As far as I'm concerned, it will *never* be a requirement,
at least not for the foreseeable future.
I do want the option to compile with 8-byte OID and/or XID types.
That's not a requirement.
reg
> > The first thought that comes to mind is that XIDs should be promoted to
> > eight bytes. However there are several practical problems with this:
> > * portability --- I don't believe long long int exists on all the
> > platforms we support.
> > regards, tom lane
How long
I think the XID wraparound matter might be handled a bit more simply.
Given a global variable X which is the earliest XID value in use at
some event (e.g. startup) you can compare two XIDs x and y, using
unsigned arithmetic, with just (x-X < y-X). This has the further
advantage that old transa
I have added this email thread to TODO.detail.
> We've expended a lot of worry and discussion in the past about what
> happens if the OID generator wraps around. However, there is another
> 4-byte counter in the system: the transaction ID (XID) generator.
> While OID wraparound is survivable, i
On Sun, Nov 05, 2000 at 03:48:13PM +0200, Hannu Krosing wrote:
> Tom Lane wrote:
> >
> > Philip Warner <[EMAIL PROTECTED]> writes:
> > >> * disk space --- letting pg_log grow without bound isn't a pleasant
> > >> prospect either.
> >
> > > Maybe this can be achieved by wrapping XID for the log f
Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > Required frequency of *successful* vacuum over *all* tables.
> > We would have to remember something in pg_class/pg_database
> > and somehow force vacuum over "too-long-unvacuumed-tables"
> > *automatically*.
>
> I don't think this
Tom Lane wrote:
>
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> * disk space --- letting pg_log grow without bound isn't a pleasant
> >> prospect either.
>
> > Maybe this can be achieved by wrapping XID for the log file only.
>
> How's that going to improve matters? pg_log is ground truth f
> > OK, 2^64 isn't mathematically unbounded, but let's see you
> > buy a disk that will hold it ;-). My point is that if we want
> > to think about allowing >4G transactions, part of the answer
> > has to be a way to recycle pg_log space. Otherwise it's still
> > not really practical.
>
> I kin
On Sunday 05 November 2000 13:02, Tom Lane wrote:
> OK, 2^64 isn't mathematically unbounded, but let's see you buy a disk
> that will hold it ;-). My point is that if we want to think about
> allowing >4G transactions, part of the answer has to be a way to recycle
> pg_log space. Otherwise it's
* Hannu Krosing <[EMAIL PROTECTED]> [001105 15:21]:
> Peter Eisentraut wrote:
> >
> I suspect that we do on many platforms (like *BSD, Linux and Win32).
Many, but not *ALL*. I prefer to build my stuff using the Native
UnixWare 7 (UDK) Compiler. As of the Feature Supplement (due out any
week now
Peter Eisentraut wrote:
>
> Hannu Krosing writes:
>
> > > The first thought that comes to mind is that XIDs should be promoted to
> > > eight bytes. However there are several practical problems with this:
> > > * portability --- I don't believe long long int exists on all the
> > > platforms we
* Tom Lane <[EMAIL PROTECTED]> [001105 12:07]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> >> Uh, we don't want to depend on gcc, do we?
>
> > Doesn't C99 *REQUIRE* long long?
>
> What difference does that make? It'll be a very long time before
> Postgres can REQUIRE that people have a C99-c
Larry Rosenman <[EMAIL PROTECTED]> writes:
>> Uh, we don't want to depend on gcc, do we?
> Doesn't C99 *REQUIRE* long long?
What difference does that make? It'll be a very long time before
Postgres can REQUIRE that people have a C99-compliant compiler.
Portability does not mean "we work great o
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> * disk space --- letting pg_log grow without bound isn't a pleasant
>> prospect either.
> How will 2x size increase of xid cause "boundless" growth of pg_log ;)
OK, 2^64 isn't mathematically unbounded, but let's see you buy a disk
that will hold it ;-
* Peter Eisentraut <[EMAIL PROTECTED]> [001105 09:39]:
> Hannu Krosing writes:
>
> > > The first thought that comes to mind is that XIDs should be promoted to
> > > eight bytes. However there are several practical problems with this:
> > > * portability --- I don't believe long long int exists o
Hannu Krosing writes:
> > The first thought that comes to mind is that XIDs should be promoted to
> > eight bytes. However there are several practical problems with this:
> > * portability --- I don't believe long long int exists on all the
> > platforms we support.
>
> I suspect that gcc at le
Tom Lane wrote:
>
> We've expended a lot of worry and discussion in the past about what
> happens if the OID generator wraps around. However, there is another
> 4-byte counter in the system: the transaction ID (XID) generator.
> While OID wraparound is survivable, if XIDs wrap around then we rea
> One idea I had from this is actually truncating pg_log at some point if
> we know all the tuples have the special committed xid. It would prevent
> the file from growing without bounds.
Not truncating, but implementing pg_log as set of files - we could remove
files for old xids.
> Vadim, can
> > So, we'll have to abort some long running transaction.
>
> Well, yes, some transaction that continues running while ~ 500 million
> other transactions come and go might give us trouble. I wasn't really
> planning to worry about that case ;-)
Agreed, I just don't like to rely on assumptions
One idea I had from this is actually truncating pg_log at some point if
we know all the tuples have the special committed xid. It would prevent
the file from growing without bounds.
Vadim, can you explain how WAL will make pg_log unnecessary someday?
> We've expended a lot of worry and discuss
Tom Lane wrote:
>
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> * disk space --- letting pg_log grow without bound isn't a pleasant
> >> prospect either.
>
> > Maybe this can be achieved by wrapping XID for the log file only.
>
> How's that going to improve matters? pg_log is ground truth f
Philip Warner <[EMAIL PROTECTED]> writes:
>> * disk space --- letting pg_log grow without bound isn't a pleasant
>> prospect either.
> Maybe this can be achieved by wrapping XID for the log file only.
How's that going to improve matters? pg_log is ground truth for XIDs;
if you can't distinguish
At 17:47 3/11/00 -0500, Tom Lane wrote:
>* portability --- I don't believe long long int exists on all the
>platforms we support.
Are you sure of this, or is it just a 'last time I looked' statement. If
the latter, it might be worth verifying.
>* performance --- except on true 64-bit platforms,
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> So, we'll have to abort some long running transaction.
Well, yes, some transaction that continues running while ~ 500 million
other transactions come and go might give us trouble. I wasn't really
planning to worry about that case ;-)
> Required fre
> This comparison will work as long as the range of interesting XIDs
> never exceeds WRAPLIMIT/2. Essentially, we envision the actual value
> of XID as being the low-order bits of a logical XID that always
> increases, and we assume that no extant XID is more than WRAPLIMIT/2
> transactions old,
We've expended a lot of worry and discussion in the past about what
happens if the OID generator wraps around. However, there is another
4-byte counter in the system: the transaction ID (XID) generator.
While OID wraparound is survivable, if XIDs wrap around then we really
do have a Ragnarok scen
26 matches
Mail list logo
