On 2012-12-28 14:59:50 -0300, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2012-12-17 13:16:47 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
> > > >> But, if the day ever comes when 64 bits doesn't seem like enough, I bet
> > > >
Andres Freund escribió:
> On 2012-12-17 13:16:47 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
> > >> But, if the day ever comes when 64 bits doesn't seem like enough, I bet
> > >> we'd move to 128-bit integers, which will surely be available
On 2012-12-18 13:14:10 +0100, Dimitri Fontaine wrote:
> Andres Freund writes:
> > In 2) unfortunately one has to make decision in which way to simplify
> > negated XLByte(LT|LE) expressions. I tried to make that choice very
> > careful and when over every change several times after that, so I hope
Andres Freund writes:
> In 2) unfortunately one has to make decision in which way to simplify
> negated XLByte(LT|LE) expressions. I tried to make that choice very
> careful and when over every change several times after that, so I hope
> there aren't any bad changes, but more eyeballs are needed.
Pavan Deolasee writes:
> BTW, now that XLogRecPtr is uint64, can't we change the pd_lsn field
> to use the same type ?
No, at least not without breaking on-disk compatibility on little-endian
machines.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hac
On 2012-12-17 23:45:51 +0530, Pavan Deolasee wrote:
> On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee
> wrote:
>
> >>
> >
> > I probably did not mean increasing that to beyond 64-bit. OTOH I
> > wondered if we would ever want to steal a few bits from the LSN field,
> > given the numbers you just
Andres Freund writes:
> On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
>> But, if the day ever comes when 64 bits doesn't seem like enough, I bet
>> we'd move to 128-bit integers, which will surely be available on all
>> platforms by then. So +1 for using plain comparisons --- in fact, I'd
>> vote
On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee
wrote:
>>
>
> I probably did not mean increasing that to beyond 64-bit. OTOH I
> wondered if we would ever want to steal a few bits from the LSN field,
> given the numbers you just put out. But it was more of a question than
> objection.
>
BTW, no
On Mon, Dec 17, 2012 at 11:17 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 17.12.2012 11:04, Pavan Deolasee wrote:
>>> On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
>>> wrote:
I've still used XLByte* macros, but I agree that plain <=> are easier to
read. +1 for using <
On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 17.12.2012 11:04, Pavan Deolasee wrote:
> >> On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
> >> wrote:
> >>> I've still used XLByte* macros, but I agree that plain <=> are easier to
> >>> read. +1 for using <
Heikki Linnakangas writes:
> On 17.12.2012 11:04, Pavan Deolasee wrote:
>> On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
>> wrote:
>>> I've still used XLByte* macros, but I agree that plain <=> are easier to
>>> read. +1 for using <=> in new code.
>> Do we ever see us changing this from 6
On 17.12.2012 11:04, Pavan Deolasee wrote:
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
wrote:
On 16.12.2012 16:16, Andres Freund wrote:
Now that XLRecPtr's are plain 64bit integers what are we supposed to use
in code comparing and manipulating them? There already is plenty example
of
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
wrote:
> On 16.12.2012 16:16, Andres Freund wrote:
>>
>> Now that XLRecPtr's are plain 64bit integers what are we supposed to use
>> in code comparing and manipulating them? There already is plenty example
>> of both, but I would like new code to
On 16.12.2012 16:16, Andres Freund wrote:
Now that XLRecPtr's are plain 64bit integers what are we supposed to use
in code comparing and manipulating them? There already is plenty example
of both, but I would like new code to go into one direction not two...
I personally find direct comparisons/
14 matches
Mail list logo
