[COMMITTERS] pgsql: Fix wording in the Tutorial document.

[Tatsuo Ishii]

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 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix wording in the Tutorial document.

[Tatsuo Ishii]

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 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix wording in the Tutorial document.

[Tatsuo Ishii]

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(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix wording in the Tutorial document.

[Tatsuo Ishii]

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 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix wording in the Tutorial document.

[Tatsuo Ishii]

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 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Fix wording in the Tutorial document.

[Tatsuo Ishii]

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 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Tom Lane]

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 be.

There's quite a lot of our code that does assume "int" is 32 bits.
(It would be better to write int32 where it matters, but I really doubt
we've been completely consistent about that.)  It probably isn't worth
worrying about; I think the platforms where "int" means int16 are all dead
and buried, or at least far too underpowered to run modern Postgres.
At some point we might have to contend with "int" meaning int64, but
I haven't heard of any such platforms yet.  The real issue is with
"long" and "long long", which definitely do vary in width across supported
platforms.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Dean Rasheed]

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


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Dean Rasheed]

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 long", and 64-bit machines are mostly new enough
> that they'd have C99-compliant compilers.
>
> 2. Nonetheless, LL is not the same as int64; on modern 64-bit machines it
> probably means int128.  So the right thing to do when writing a constant
> you mean to be int64 is to use a cast or [U]INT64CONST().  (You need that
> macro if the constant value might be too wide for plain int, since pickier
> compilers may reject an unsuffixed constant wider than int.)
>

OK, thanks that's all good to know.


> Your updated code looks fine from here.  I looked into changing that code
> in ecpg, but it would be more invasive than I thought because ecpg doesn't
> use c.h.  Some rearrangement of the ecpg headers would be required, and
> in view of point #1, it's unlikely to be worth it; it might buy a bit of
> micro-efficiency but not much.
>

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:

int hashVal = 0;
for (...)
{
hashVal = hashVal + (int) ecpgQuery[stmtIx];
hashVal = (((unsigned int) hashVal) >> 19) | (hashVal << 13);
}

but it's probably not worth changing, for risk of breaking it.

Regards,
Dean


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Tom Lane]

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'd have C99-compliant compilers.

2. Nonetheless, LL is not the same as int64; on modern 64-bit machines it
probably means int128.  So the right thing to do when writing a constant
you mean to be int64 is to use a cast or [U]INT64CONST().  (You need that
macro if the constant value might be too wide for plain int, since pickier
compilers may reject an unsuffixed constant wider than int.)

Your updated code looks fine from here.  I looked into changing that code
in ecpg, but it would be more invasive than I thought because ecpg doesn't
use c.h.  Some rearrangement of the ecpg headers would be required, and
in view of point #1, it's unlikely to be worth it; it might buy a bit of
micro-efficiency but not much.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Joe Conway]

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

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

[COMMITTERS] pgsql: Further fixing to make pg_size_bytes() portable.

[Dean Rasheed]

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
--
src/backend/utils/adt/dbsize.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Tom Lane]

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 has been there, but it's
gratuitously unportable.  Even if you grant that "long long" exists
in the compiler, there's no promises whatever as to what width it is.
This code looks to be assuming that it's int64, but just using int64
would be a better answer.

BTW, I now remember that we have an INT64CONST macro in c.h, which
would be another solution if you don't like the cast for some reason.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Dean Rasheed]

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. Thanks to Michael Paquier for helping
>> to diagnose this.
>
> That's still not right: not all compilers support "long long", and the
> ones that don't won't have "LL" notation either.
>
> Project style is to use something like "(uint64) 1024" instead.
>

OK, will fix.

BTW, I found a couple of instances of 'LL' in ecpglib/prepare.c, which
is why I thought it was OK to use it.

Regards,
Dean


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Tom Lane]

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.

That's still not right: not all compilers support "long long", and the
ones that don't won't have "LL" notation either.

Project style is to use something like "(uint64) 1024" instead.

regards, tom lane


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Pavel Stehule]

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_bytes('10 GB')".
>
> Author: Pavel Stehule with various improvements by Vitaly Burovoy
> Discussion:
> http://www.postgresql.org/message-id/cafj8prd-tgodknxdygecza4on01_urqprwf-8ldkse-6bdh...@mail.gmail.com
> Reviewed-by: Vitaly Burovoy, Oleksandr Shulgin, Kyotaro Horiguchi,
> Michael Paquier and Robert Haas
>
> Branch
> --
> master
>
> Details
> ---
>
> http://git.postgresql.org/pg/commitdiff/53874c5228fe16589a4d01b3e1fab3678e0fd8e3
>
> Modified Files
> --
> doc/src/sgml/func.sgml   |  32 +++-
> src/backend/utils/adt/dbsize.c   | 149
> +++
> src/include/catalog/catversion.h |   2 +-
> src/include/catalog/pg_proc.h|   2 +
> src/include/utils/builtins.h |   1 +
> src/test/regress/expected/dbsize.out | 109 +
> src/test/regress/sql/dbsize.sql  |  39 +
> 7 files changed, 331 insertions(+), 3 deletions(-)
>

great :)

Thank you very much

Regards

Pavel


>
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers
>

[COMMITTERS] pgsql: Fix pg_size_bytes() to be more portable.

[Dean Rasheed]

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
---
http://git.postgresql.org/pg/commitdiff/ad7cc1c554980145b226a066afe56d9c777ce7ae

Modified Files
--
src/backend/utils/adt/dbsize.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Dean Rasheed]

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 terabyte conversion is at fault:
> Expected:
> !  -1tb  |-1099511627776
> Result:
> !  -1tb  |-1
>
> +   else if (pg_strcasecmp(strptr, "gb") == 0)
> +   multiplier = 1024 * 1024 * 1024;
> +   else if (pg_strcasecmp(strptr, "tb") == 0)
> +   multiplier = 1024 * 1024 * 1024 * 1024L;
> Why adding an 'L' here?

Ah, looks like it needs to be 'LL' because it needs to be a 64-bit literal.

Regards,
Dean


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Michael Paquier]

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
Result:
!  -1tb  |-1

+   else if (pg_strcasecmp(strptr, "gb") == 0)
+   multiplier = 1024 * 1024 * 1024;
+   else if (pg_strcasecmp(strptr, "tb") == 0)
+   multiplier = 1024 * 1024 * 1024 * 1024L;
Why adding an 'L' here?
-- 
Michael


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Vik Fearing]

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 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Dean Rasheed]

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.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Michael Paquier]

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 to be written with clauses
>> like "pg_total_relation_size(oid) > pg_size_bytes('10 GB')".
>>
>> Author: Pavel Stehule with various improvements by Vitaly Burovoy
>> Discussion: 
>> http://www.postgresql.org/message-id/cafj8prd-tgodknxdygecza4on01_urqprwf-8ldkse-6bdh...@mail.gmail.com
>> Reviewed-by: Vitaly Burovoy, Oleksandr Shulgin, Kyotaro Horiguchi,
>> Michael Paquier and Robert Haas
>
> Happy first commit.

And happy first buildfarm breakage :)
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=termite=2016-02-20%2010%3A10%3A07
-- 
Michael


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Re: [COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[Michael Paquier]

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) > pg_size_bytes('10 GB')".
>
> Author: Pavel Stehule with various improvements by Vitaly Burovoy
> Discussion: 
> http://www.postgresql.org/message-id/cafj8prd-tgodknxdygecza4on01_urqprwf-8ldkse-6bdh...@mail.gmail.com
> Reviewed-by: Vitaly Burovoy, Oleksandr Shulgin, Kyotaro Horiguchi,
> Michael Paquier and Robert Haas

Happy first commit.
-- 
Michael


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

[COMMITTERS] pgsql: Add pg_size_bytes() to parse human-readable size strings.

[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_bytes('10 GB')".

Author: Pavel Stehule with various improvements by Vitaly Burovoy
Discussion: 
http://www.postgresql.org/message-id/cafj8prd-tgodknxdygecza4on01_urqprwf-8ldkse-6bdh...@mail.gmail.com
Reviewed-by: Vitaly Burovoy, Oleksandr Shulgin, Kyotaro Horiguchi,
Michael Paquier and Robert Haas

Branch
--
master

Details
---
http://git.postgresql.org/pg/commitdiff/53874c5228fe16589a4d01b3e1fab3678e0fd8e3

Modified Files
--
doc/src/sgml/func.sgml   |  32 +++-
src/backend/utils/adt/dbsize.c   | 149 +++
src/include/catalog/catversion.h |   2 +-
src/include/catalog/pg_proc.h|   2 +
src/include/utils/builtins.h |   1 +
src/test/regress/expected/dbsize.out | 109 +
src/test/regress/sql/dbsize.sql  |  39 +
7 files changed, 331 insertions(+), 3 deletions(-)


-- 
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers