Fix wording in the Tutorial document.
With suggentions from Tom Lane.
Branch
--
REL9_5_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/a397f8268a6a315b8c6579124637cddc8f79ea71
Modified Files
--
doc/src/sgml/start.sgml | 2 +-
1 file changed, 1 insertion(+), 1 delet
Fix wording in the Tutorial document.
With suggentions from Tom Lane.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/8fed3cc225a24c3c5a22cbf7afd9bd8615dcaf2d
Modified Files
--
doc/src/sgml/start.sgml | 2 +-
1 file changed, 1 insertion(+), 1 delet
Fix wording in the Tutorial document.
With suggentions from Tom Lane.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/902fd1f4e2457f6f04a988920491fffb90028035
Modified Files
--
doc/src/sgml/start.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Fix wording in the Tutorial document.
With suggentions from Tom Lane.
Branch
--
REL9_2_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/7cea53e2dcaa9100e8aab925e71fbc8a4b0c80d9
Modified Files
--
doc/src/sgml/start.sgml | 2 +-
1 file changed, 1 insertion(+), 1 delet
Fix wording in the Tutorial document.
With suggentions from Tom Lane.
Branch
--
REL9_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/5c4973118755c6294a1c823bb95427dadbb1c28e
Modified Files
--
doc/src/sgml/start.sgml | 2 +-
1 file changed, 1 insertion(+), 1 delet
Fix wording in the Tutorial document.
With suggentions from Tom Lane.
Branch
--
REL9_1_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/5d312ef1b2b38d0db90394691694238194172e84
Modified Files
--
doc/src/sgml/start.sgml | 2 +-
1 file changed, 1 insertion(+), 1 delet
Dean Rasheed writes:
> On 20 February 2016 at 17:24, Dean Rasheed wrote:
>> It looks to me as though it doesn't need long long anyway, since the
>> rotation it's doing can be done just as easily with ints, for example:
> Oh, scratch that -- I was assuming int would be 32-bit, which it might not
On 20 February 2016 at 17:24, Dean Rasheed wrote:
> It looks to me as though it doesn't need long long anyway, since the
> rotation it's doing can be done just as easily with ints, for example:
Oh, scratch that -- I was assuming int would be 32-bit, which it might not be.
Regards,
Dean
--
Sen
On 20 February 2016 at 16:32, Tom Lane wrote:
> After further thought about the portability implications of this ---
>
> 1. We probably gave up support for long-long-less compilers when we agreed
> to start requiring a working int64 type. On a 32-bit machine that's
> highly likely to be "long lon
After further thought about the portability implications of this ---
1. We probably gave up support for long-long-less compilers when we agreed
to start requiring a working int64 type. On a 32-bit machine that's
highly likely to be "long long", and 64-bit machines are mostly new enough
that they'
On 02/20/2016 02:32 AM, Vik Fearing wrote:
> On 02/20/2016 11:17 AM, Dean Rasheed wrote:
>> On 20 February 2016 at 10:12, Michael Paquier
>> wrote:
>>> Happy first commit.
>>
>> Arg. Not so much.
>>
>> Looks like I broke something -- looking into it now :-(
>
> Happy first commit anyway!
>
+1
Further fixing to make pg_size_bytes() portable.
Not all compilers support "long long" and the "LL" integer literal
suffix, so use a cast to int64 instead.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/740d71842b8e0e798c80f4f841227b6de81b5f43
Modified Files
--
Dean Rasheed writes:
> On 20 February 2016 at 14:54, Tom Lane wrote:
>> Project style is to use something like "(uint64) 1024" instead.
> BTW, I found a couple of instances of 'LL' in ecpglib/prepare.c, which
> is why I thought it was OK to use it.
[ squint... ] Don't know how long that code h
On 20 February 2016 at 14:54, Tom Lane wrote:
> Dean Rasheed writes:
>> Fix pg_size_bytes() to be more portable.
>> Commit 53874c5228fe16589a4d01b3e1fab3678e0fd8e3 broke various 32-bit
>> buildfarm machines because it incorrectly used an 'L' suffix for what
>> needed to be a 64-bit literal. Thank
Dean Rasheed writes:
> Fix pg_size_bytes() to be more portable.
> Commit 53874c5228fe16589a4d01b3e1fab3678e0fd8e3 broke various 32-bit
> buildfarm machines because it incorrectly used an 'L' suffix for what
> needed to be a 64-bit literal. Thanks to Michael Paquier for helping
> to diagnose this.
2016-02-20 11:07 GMT+01:00 Dean Rasheed :
> Add pg_size_bytes() to parse human-readable size strings.
>
> This will parse strings in the format produced by pg_size_pretty() and
> return sizes in bytes. This allows queries to be written with clauses
> like "pg_total_relation_size(oid) > pg_size_byt
Fix pg_size_bytes() to be more portable.
Commit 53874c5228fe16589a4d01b3e1fab3678e0fd8e3 broke various 32-bit
buildfarm machines because it incorrectly used an 'L' suffix for what
needed to be a 64-bit literal. Thanks to Michael Paquier for helping
to diagnose this.
Branch
--
master
Details
On 20 February 2016 at 10:33, Michael Paquier wrote:
> On Sat, Feb 20, 2016 at 7:17 PM, Dean Rasheed
> wrote:
>> On 20 February 2016 at 10:12, Michael Paquier
>> wrote:
>>> Happy first commit.
>>
>> Arg. Not so much.
>>
>> Looks like I broke something -- looking into it now :-(
>
> The terabyt
On Sat, Feb 20, 2016 at 7:17 PM, Dean Rasheed wrote:
> On 20 February 2016 at 10:12, Michael Paquier
> wrote:
>> Happy first commit.
>
> Arg. Not so much.
>
> Looks like I broke something -- looking into it now :-(
The terabyte conversion is at fault:
Expected:
! -1tb |-1099511627776
On 02/20/2016 11:17 AM, Dean Rasheed wrote:
> On 20 February 2016 at 10:12, Michael Paquier
> wrote:
>> Happy first commit.
>
> Arg. Not so much.
>
> Looks like I broke something -- looking into it now :-(
Happy first commit anyway!
--
Vik Fearing +33
On 20 February 2016 at 10:12, Michael Paquier wrote:
> Happy first commit.
Arg. Not so much.
Looks like I broke something -- looking into it now :-(
Regards,
Dean
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.post
On Sat, Feb 20, 2016 at 7:12 PM, Michael Paquier
wrote:
> On Sat, Feb 20, 2016 at 7:07 PM, Dean Rasheed
> wrote:
>> Add pg_size_bytes() to parse human-readable size strings.
>>
>> This will parse strings in the format produced by pg_size_pretty() and
>> return sizes in bytes. This allows queries
On Sat, Feb 20, 2016 at 7:07 PM, Dean Rasheed wrote:
> Add pg_size_bytes() to parse human-readable size strings.
>
> This will parse strings in the format produced by pg_size_pretty() and
> return sizes in bytes. This allows queries to be written with clauses
> like "pg_total_relation_size(oid) >
Add pg_size_bytes() to parse human-readable size strings.
This will parse strings in the format produced by pg_size_pretty() and
return sizes in bytes. This allows queries to be written with clauses
like "pg_total_relation_size(oid) > pg_size_bytes('10 GB')".
Author: Pavel Stehule with various im
24 matches
Mail list logo