Skip site navigation (1) Skip section navigation (2)

Re: xlog location arithmetic

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Magnus Hagander" <magnus(at)hagander(dot)net>, "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Euler Taveira de Oliveira" <euler(at)timbira(dot)com>
Subject: Re: xlog location arithmetic
Date: 2012-03-09 19:37:43
Message-ID: 4F5A07A7020000250004608E@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
 
>> The whole thing was built around the lack of 64 bit integers.  If
>> we bit the bullet and changed the whole thing to be just a single
>> 64-bit counter, we could probably delete thousands of lines of
>> code.
> 
> Hm.  I think "thousands" is an overestimate, but yeah the logic
> could be greatly simplified.  However, I'm not sure we could avoid
> breaking the existing naming convention for WAL files.  How much
> do we care about that?
 
We have a few scripts in our backup area that are based around the
current WAL file naming convention, so there would be some impact;
but I have to believe it would be pretty minor.  Most of the pain
would be related to the need to support both naming conventions for
some transition period.  If it simplifies the WAL-related logic, it
seems well worth it to me.  We just have to know it's coming and be
clear on what the new naming rules are.
 
-Kevin

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-03-09 19:39:26
Subject: Re: xlog location arithmetic
Previous:From: Robert HaasDate: 2012-03-09 19:34:40
Subject: Re: Rules containing INSERT/UPDATE lack dependencies on target columns

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group