Re: [HACKERS] XLByte* usage

2012-12-28 Thread Alvaro Herrera
Andres Freund escribió: On 2012-12-17 13:16:47 -0500, Tom Lane wrote: Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] XLByte* usage

2012-12-28 Thread Andres Freund
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 and...@2ndquadrant.com 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

Re: [HACKERS] XLByte* usage

2012-12-18 Thread Dimitri Fontaine
Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] XLByte* usage

2012-12-18 Thread Andres Freund
On 2012-12-18 13:14:10 +0100, Dimitri Fontaine wrote: Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Heikki Linnakangas
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

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Pavan Deolasee
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas hlinnakan...@vmware.com 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

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Heikki Linnakangas
On 17.12.2012 11:04, Pavan Deolasee wrote: On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas hlinnakan...@vmware.com 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

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Tom Lane
Heikki Linnakangas hlinnakan...@vmware.com writes: On 17.12.2012 11:04, Pavan Deolasee wrote: On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: I've still used XLByte* macros, but I agree that plain = are easier to read. +1 for using = in new code. Do we

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Andres Freund
On 2012-12-17 12:47:41 -0500, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 17.12.2012 11:04, Pavan Deolasee wrote: On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: I've still used XLByte* macros, but I agree that plain = are

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Pavan Deolasee
On Mon, Dec 17, 2012 at 11:17 PM, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 17.12.2012 11:04, Pavan Deolasee wrote: On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: I've still used XLByte* macros, but I agree

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Pavan Deolasee
On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee pavan.deola...@gmail.com 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

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Tom Lane
Andres Freund and...@2ndquadrant.com 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

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Andres Freund
On 2012-12-17 23:45:51 +0530, Pavan Deolasee wrote: On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee pavan.deola...@gmail.com 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

Re: [HACKERS] XLByte* usage

2012-12-17 Thread Tom Lane
Pavan Deolasee pavan.deola...@gmail.com 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

[HACKERS] XLByte* usage

2012-12-16 Thread Andres Freund
Hi, 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/manipulations far easier to read than