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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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