Re: [HACKERS] \timing interval

2016-07-09 Thread Gavin Flower

On 10/07/16 12:08, Andrew Gierth wrote:

"Gavin" == Gavin Flower  writes:

  >> How about
  >>
  >> Time: 1234567.666 ms (20m 34.6s)

  Gavin> I like that, but I think the human form should retain the 3
  Gavin> decimal places.

Scale it.

Time: 12.345 ms (0.012345s)

Time: 1234.567 ms (1.235s)

Time: 98765.432 ms (98.8s)

Time: 123456.789 ms (2m 3.5s)

Time: 12345678.666 ms (3h 24m 46s)

  Gavin> In a few years, we may well have enormously multiprocessor
  Gavin> computers with massive very fast permanent 'RAM' where the
  Gavin> entire database is always in memory, so timing to the nearest
  Gavin> microsecond could be useful.

But the original microsecond-resolution value is still right there, so I
don't see the issue.


Sorry misunderstood, thought it was milliseconds!




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


Re: [HACKERS] \timing interval

2016-07-09 Thread Andrew Gierth
> "Gavin" == Gavin Flower  writes:

 >> How about
 >> 
 >> Time: 1234567.666 ms (20m 34.6s)

 Gavin> I like that, but I think the human form should retain the 3
 Gavin> decimal places.

Scale it.

Time: 12.345 ms (0.012345s)

Time: 1234.567 ms (1.235s)

Time: 98765.432 ms (98.8s)

Time: 123456.789 ms (2m 3.5s)

Time: 12345678.666 ms (3h 24m 46s)

 Gavin> In a few years, we may well have enormously multiprocessor
 Gavin> computers with massive very fast permanent 'RAM' where the
 Gavin> entire database is always in memory, so timing to the nearest
 Gavin> microsecond could be useful.

But the original microsecond-resolution value is still right there, so I
don't see the issue.

-- 
Andrew (irc:RhodiumToad)


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Gavin Flower

On 10/07/16 08:00, Andrew Gierth wrote:

"Tom" == Tom Lane  writes:

  > Peter Eisentraut  writes:
  >> I'm not quite sure what you mean by wanting to do arithmetic on the
  >> numbers.  My phrasing of the problem is that after a long query, you
  >> might get output like this:
  >> Time: 1234567.666 ms
  >> which is pretty useless.

  Tom> What I mean by that is that not infrequently, I'll run the same
  Tom> query several times and then want to average the results.  That's
  Tom> easy with awk or similar scripts as long as the numbers are in
  Tom> straight decimal.

  Tom> I don't mind if we provide a way to print in Babylonian-inspired
  Tom> notation(s) as well, but I'm going to be seriously annoyed if
  Tom> that's the only way to get the output.

How about

Time: 1234567.666 ms (20m 34.6s)

?


I like that, but I think the human form should retain the 3 decimal places.

In a few years, we may well have enormously multiprocessor computers 
with massive very fast permanent 'RAM' where the entire database is 
always in memory, so timing to the nearest microsecond could be useful.  
Obviously microsecond precision would be silly now, and would probably 
never warrant being the default (I'd be happy to be proved wrong here!), 
but it might be worthwhile putting in as an option - while people are 
looking at the relevant areas of the code.


Am inspired by the man page for 'ls': [...] The  SIZE  argument is  an  
integer and optional unit (example: 10K is 10*1024). Units are 
K,M,G,T,P,E,Z,Y  (powers  of  1024) [...]" Obviously learnt from the 
lessons of "640KB should be enough for everyone" stupidity!



Cheers,
Gavin



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


Re: [HACKERS] \timing interval

2016-07-09 Thread Peter Geoghegan
On Sat, Jul 9, 2016 at 1:48 PM, Alvaro Herrera  wrote:
>> How about
>>
>> Time: 1234567.666 ms (20m 34.6s)
>>
>> ?
>
> +1 LGTM

+1


-- 
Peter Geoghegan


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


Re: [HACKERS] remove checkpoint_warning

2016-07-09 Thread Tom Lane
Alvaro Herrera  writes:
> the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
> in November 2002 when we didn't have any logging of checkpointing at
> all.  I propose to remove it: surely anyone who cares about analyzing
> checkpointing behavior nowadays is using the log_checkpoint feature
> instead, which contains much more detail.  The other one is just noise
> now, and probably ignored amidst the number of other warning traffic.

Hmm, not sure.  ISTM log_checkpoint is oriented to people who know what
they are doing, whereas checkpoint_warning is more targeted to trying
to help people who don't.  Perhaps you could make an argument that
checkpoint_warning is useless because the people whom it's meant to help
won't notice the warning anyway --- but I doubt that it's been
"superseded" by log_checkpoint, because the latter would only be enabled
by people who already have a clue that checkpoint performance is something
to worry about.

Or in short, this may be a fine change to make, but I don't like your
argument for it.

regards, tom lane


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


Re: [HACKERS] remove checkpoint_warning

2016-07-09 Thread Andres Freund
On 2016-07-09 16:46:32 -0400, Alvaro Herrera wrote:
> the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
> in November 2002 when we didn't have any logging of checkpointing at
> all.  I propose to remove it: surely anyone who cares about analyzing
> checkpointing behavior nowadays is using the log_checkpoint feature
> instead, which contains much more detail.  The other one is just noise
> now, and probably ignored amidst the number of other warning traffic.

I think we could do that, if we enable log_checkpoints by default, but
right now we don't...


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


[HACKERS] remove checkpoint_warning

2016-07-09 Thread Alvaro Herrera
the checkpoint_warning feature was added by commit 2986aa6a668bce3cfb836
in November 2002 when we didn't have any logging of checkpointing at
all.  I propose to remove it: surely anyone who cares about analyzing
checkpointing behavior nowadays is using the log_checkpoint feature
instead, which contains much more detail.  The other one is just noise
now, and probably ignored amidst the number of other warning traffic.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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


Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

2016-07-09 Thread Peter Baumann
Hi Stefan,

On 07/09/2016 04:03 PM, Stefan Keller wrote:
> Hi Peter, hi all,
>
> I wrote 2016-07-06 13:19 GMT+02:00:
>> ...
>> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>>> ... But ISO/IEC CD 9075-15
>>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to
>>> Working Group".  Is that how they say "returned with feedback"?
>>> ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has also reached stage
>>> 30.60.  Does anyone know what that one is about?  ...
> @Peter B. Can you clarify the stage?

there were comments from the national delegations which have to be worked
through by providing a draft that implements changes where considered
applicable, and justifying when not implemented. This is in accordance with ISO
"bureaucracy", if you will, which defines a fine-grain, therefore transparent,
process. Personally, I find this many-eyes principle very fruitful.

> Regarding the differences of array functions of the ISO proposal, I
> have no clue why the working group did not follow the implementation
> of PostgreSQL.
>
> @Peter B. You know PostgreSQL well. Can you explain?

the WG has discussed all relevant approaches and decided in favour of the one it
found most suitable.

cheers,
Peter

>
> :Stefan
>
> P.S. 2016-07-02 17:11 GMT+02:00 Tom Lane  wrote:
>> Peter E. had observer status at one point, don't know if he still does.
> @Peter E.: Do you still have observer status at the ISO committee?
>
>
>
> 2016-07-06 13:19 GMT+02:00 Stefan Keller :
>> Thomas
>>
>> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>>> ... But ISO/IEC CD 9075-15
>>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to
>>> Working Group".  Is that how they say "returned with feedback"?
>>> ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has also reached stage
>>> 30.60.  Does anyone know what that one is about?  Maybe something like
>> Peter surely would know: https://www.jacobs-university.de/directory/pbaumann
>>
>> :Stefan
>>
>> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>>> On Wed, Jun 29, 2016 at 11:51 AM, Stefan Keller  wrote:
 Hi,

 FYI: I'd just like to point you to following two forthcoming standard
 parts from "ISO/IEC JTS 1/SC 32" comittee: one on JSON, and one on
 "Multi-Dimensional Arrays" (SQL/MDA).

 They define there some things different as already in PG. See also
 Peter Baumann's slides [1] and e.g. [2]

 :Stefan

 [1] 
 https://www.unibw.de/inf4/professors/geoinformatics/agile-2016-workshop-gis-with-nosql
 [2] 
 http://jtc1sc32.org/doc/N2501-2550/32N2528-WG3-Tutorial-Opening-Plenary.pdf
>>> Thanks for these pointers.  On the "standards under development"
>>> page[1], I see that ISO/IEC PDTR 19075-6 (SQL/JSON) is at stage 30.60
>>> "Close of voting/ comment period".  But ISO/IEC CD 9075-15
>>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to
>>> Working Group".  Is that how they say "returned with feedback"?
>>> ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has also reached stage
>>> 30.60.  Does anyone know what that one is about?  Maybe something like
>>> MATCH_RECOGNIZE in Oracle?
>>>
>>> [1] 
>>> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=45342=on
>>>
>>> --
>>> Thomas Munro
>>> http://www.enterprisedb.com

-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   www.faculty.jacobs-university.de/pbaumann
   mail: p.baum...@jacobs-university.de
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   www.rasdaman.com, mail: baum...@rasdaman.com
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis
dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec
preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)




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


Re: [HACKERS] [CF2016-9] Allow spaces in working path on tap-tests

2016-07-09 Thread Tom Lane
Kyotaro HORIGUCHI  writes:
> At Tue, 5 Jul 2016 13:44:08 +0900, Michael Paquier 
>  wrote in 
> 
>> Attached is the patch I have in mind. After more investigation zic.exe
>> is indeed broken, $target can be a full path, and if it contains a
>> space things blow up. The commands of vcregress upgradecheck need a
>> cleanup as well. I have merged both patches together and the part for
>> src/tools/msvc needs a backpatch. Separating both things is trivial
>> anyway as the MSVC and the TAP stuff are on two completely separate
>> paths.

> Agreed. Grep'ing "system" in the source tree, I see no more place
> where needs the same fix.

This seemed like a bug fix to me, so I went ahead and pushed it.  I don't
have any ability to test the Windows parts, so it's possible I missed
something in the back-patching; please review.

regards, tom lane


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Alvaro Herrera
Andrew Gierth wrote:

> How about
> 
> Time: 1234567.666 ms (20m 34.6s)
> 
> ?

+1 LGTM

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Corey Huinker
On Sat, Jul 9, 2016 at 4:00 PM, Andrew Gierth 
wrote:

> > "Tom" == Tom Lane  writes:
>
>  > Peter Eisentraut  writes:
>  >> I'm not quite sure what you mean by wanting to do arithmetic on the
>  >> numbers.  My phrasing of the problem is that after a long query, you
>  >> might get output like this:
>  >> Time: 1234567.666 ms
>  >> which is pretty useless.
>
>  Tom> What I mean by that is that not infrequently, I'll run the same
>  Tom> query several times and then want to average the results.  That's
>  Tom> easy with awk or similar scripts as long as the numbers are in
>  Tom> straight decimal.
>
>  Tom> I don't mind if we provide a way to print in Babylonian-inspired
>  Tom> notation(s) as well, but I'm going to be seriously annoyed if
>  Tom> that's the only way to get the output.
>
> How about
>
> Time: 1234567.666 ms (20m 34.6s)
>
>
That'd be fine too, it's not like we're doing anything with the rest of
that line.


Re: [HACKERS] \timing interval

2016-07-09 Thread Corey Huinker
On Sat, Jul 9, 2016 at 3:35 PM, Tom Lane  wrote:

> Peter Eisentraut  writes:
> > I'm not quite sure what you mean by wanting to do arithmetic on the
> > numbers.  My phrasing of the problem is that after a long query, you
> > might get output like this:
> > Time: 1234567.666 ms
> > which is pretty useless.
>
> What I mean by that is that not infrequently, I'll run the same query
> several times and then want to average the results.  That's easy with awk
> or similar scripts as long as the numbers are in straight decimal.
>
> I don't mind if we provide a way to print in Babylonian-inspired
> notation(s) as well, but I'm going to be seriously annoyed if that's
> the only way to get the output.
>
> regards, tom lane
>

I thought about a pset option as well, and I'd be fine with that, and I
don't think it'd be any harder to do it that way.

As for the leading zeros, I was following the format of the namesake
interval, adjusting for psql's existing max-3 decimal points on the
milliseconds.

# select INTERVAL '1 hours 2 minutes 3 seconds 4.567 milliseconds';
interval
-
 01:02:03.004567

# select INTERVAL '112345689 milliseconds';
   interval
--
 31:12:25.689

# select INTERVAL '1123456890 milliseconds';
   interval
--
 312:04:16.89


I'm not wild about the leading zero either, but I see where it's needed for
context absent d/h/m/s units, and I had concerns about internationalization
issues with unit abbreviations.

A quick googling of "iso time duration format" yielded more heat than
light. My one takeaway was that they require the leading zeros.

So what's everybody think of this?:
Keep \timing as-is.
Add \pset timing_format (or a better name, please suggest one), which can
have at least some of these options:

- milliseconds - this would be the default value with current behavior, and
an unset pset would assume this value.

- seconds - current ms value / 1000 and re-labeld s
- minutes - current ms value / 6 and re-labeled m
- interval -  follows the output format that we already use for INTERVAL
types.
- short - just like "interval" but trimming leading zeros and places.
Precision is kept at .xxx ms for context
- pretty - 4d, 3h, 2m, 11s, 45.678ms

The actual act of printing the timing value only happens in two places, so
replacing each with a single function is trivial.


Re: [HACKERS] \timing interval

2016-07-09 Thread Tom Lane
Andrew Gierth  writes:
> How about
> Time: 1234567.666 ms (20m 34.6s)

Hmm ... worksforme.

regards, tom lane


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Andrew Gierth
> "Tom" == Tom Lane  writes:

 > Peter Eisentraut  writes:
 >> I'm not quite sure what you mean by wanting to do arithmetic on the 
 >> numbers.  My phrasing of the problem is that after a long query, you 
 >> might get output like this:
 >> Time: 1234567.666 ms
 >> which is pretty useless.

 Tom> What I mean by that is that not infrequently, I'll run the same
 Tom> query several times and then want to average the results.  That's
 Tom> easy with awk or similar scripts as long as the numbers are in
 Tom> straight decimal.

 Tom> I don't mind if we provide a way to print in Babylonian-inspired
 Tom> notation(s) as well, but I'm going to be seriously annoyed if
 Tom> that's the only way to get the output.

How about

Time: 1234567.666 ms (20m 34.6s)

?

-- 
Andrew (irc:RhodiumToad)


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Tom Lane
Peter Eisentraut  writes:
> I'm not quite sure what you mean by wanting to do arithmetic on the 
> numbers.  My phrasing of the problem is that after a long query, you 
> might get output like this:
> Time: 1234567.666 ms
> which is pretty useless.

What I mean by that is that not infrequently, I'll run the same query
several times and then want to average the results.  That's easy with awk
or similar scripts as long as the numbers are in straight decimal.

I don't mind if we provide a way to print in Babylonian-inspired
notation(s) as well, but I'm going to be seriously annoyed if that's
the only way to get the output.

regards, tom lane


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Peter Eisentraut

On 7/9/16 12:59 PM, Tom Lane wrote:

NAK --- if you're trying to do arithmetic on the numbers, converting
them to hh:mm:ss notation isn't the best first step.  I think a separate
setting somewhere to select the format would be good.  Please *don't*
do "\timing interval" as that confuses the on/off state with the
formatting selection.  Maybe a \pset option?


I'm not quite sure what you mean by wanting to do arithmetic on the 
numbers.  My phrasing of the problem is that after a long query, you 
might get output like this:


Time: 1234567.666 ms

which is pretty useless.

So I would like to have a format that is a bit more sensitive to the 
scale of the numbers.  And I would like that by default, because I don't 
really want to have to fiddle with the format and then have to re-run 
the long query.  (Then I'd just do the division by 3600 or whatever 
myself, and we haven't really improved usability.)


I'm not wedded to any particular format, but I think we can come up with 
one that works in most situations.


--
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Pavel Stehule
2016-07-09 18:59 GMT+02:00 Tom Lane :

> Peter Eisentraut  writes:
> > On 7/7/16 5:52 PM, Corey Huinker wrote:
> >> Wouldn't it be great if we had a way of printing timing in more human
> >> friendly formats?
>
> > Something like what you are proposing might as well be the default and
> > only format.
>
> NAK --- if you're trying to do arithmetic on the numbers, converting
> them to hh:mm:ss notation isn't the best first step.  I think a separate
> setting somewhere to select the format would be good.  Please *don't*
> do "\timing interval" as that confuses the on/off state with the
> formatting selection.  Maybe a \pset option?
>
>
\pset is good idea


> Also, might I suggest that leading zeroes in such a format are not
> helpful?  That is, I'd want to see "1:02.345" not "00:01:02.345".
>

the value without units and without leading zeroes is not clear

Regards

Pavel


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Greg Stark
On Sat, Jul 9, 2016 at 5:59 PM, Tom Lane  wrote:
> Also, might I suggest that leading zeroes in such a format are not
> helpful?  That is, I'd want to see "1:02.345" not "00:01:02.345".


Or 1m 2s 345ms

-- 
greg


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


Re: [HACKERS] \timing interval

2016-07-09 Thread Tom Lane
Peter Eisentraut  writes:
> On 7/7/16 5:52 PM, Corey Huinker wrote:
>> Wouldn't it be great if we had a way of printing timing in more human
>> friendly formats?

> Something like what you are proposing might as well be the default and 
> only format.

NAK --- if you're trying to do arithmetic on the numbers, converting
them to hh:mm:ss notation isn't the best first step.  I think a separate
setting somewhere to select the format would be good.  Please *don't*
do "\timing interval" as that confuses the on/off state with the
formatting selection.  Maybe a \pset option?

Also, might I suggest that leading zeroes in such a format are not
helpful?  That is, I'd want to see "1:02.345" not "00:01:02.345".

regards, tom lane


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


Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

2016-07-09 Thread Magnus Hagander
On Jul 9, 2016 4:52 AM, "Noah Misch"  wrote:
>
> On Thu, Jul 07, 2016 at 03:38:26PM +0900, Michael Paquier wrote:
> > On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
> >  wrote:
> > > After further analysis, the issue is that we retrieve the starttli
from
> > > the ControlFile structure, but it was using ThisTimeLineID when
writing
> > > the backup label.
> > >
> > > I've attached a very simple patch that fixes it.
> >
> > ThisTimeLineID is always set at 0 on purpose on a standby, so we
> > cannot rely on it (well it is set temporarily when recycling old
> > segments). At recovery when parsing the backup_label file there is no
> > actual use of the start segment name, so that's only a cosmetic
> > change. But surely it would be better to get that fixed, because
> > that's useful for debugging.
> >
> > While looking at your patch, I thought that it would have been
> > tempting to use GetXLogReplayRecPtr() to get the timeline ID when in
> > recovery, but what we really want to know here is the timeline of the
> > last REDO pointer, which is starttli, and that's more consistent with
> > the fact that we use startpoint when writing the backup_label file. In
> > short, +1 for this fix.
> >
> > I am adding that in the list of open items, adding Magnus in CC whose
> > commit for non-exclusive backups is at the origin of this defect.
>
> [Action required within 72 hours.  This is a generic notification.]
>
> The above-described topic is currently a PostgreSQL 9.6 open item.
Magnus,
> since you committed the patch believed to have created it, you own this
open
> item.  If some other commit is more relevant or if this does not belong
as a
> 9.6 open item, please let us know.  Otherwise, please observe the policy
on
> open item ownership[1] and send a status update within 72 hours of this
> message.  Include a date for your subsequent status update.  Testers may
> discover new open items at any time, and I want to plan to get them all
fixed
> well in advance of shipping 9.6rc1.  Consequently, I will appreciate your
> efforts toward speedy resolution.  Thanks.
>
> [1]
http://www.postgresql.org/message-id/20160527025039.ga447...@tornado.leadboat.com

I'll take a look at this on Monday when I'm back home from Russia. It looks
like people have it under control, so hopefully that just means committing
the available solution in which case it'll be finished by then.

/Magnus


Re: [HACKERS] \timing interval

2016-07-09 Thread Peter Eisentraut

On 7/7/16 5:52 PM, Corey Huinker wrote:

Wouldn't it be great if we had a way of printing timing in more human
friendly formats?


Something like what you are proposing might as well be the default and 
only format.


--
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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


Re: [HACKERS] Forthcoming SQL standards about JSON and Multi-Dimensional Arrays (FYI)

2016-07-09 Thread Stefan Keller
Hi Peter, hi all,

I wrote 2016-07-06 13:19 GMT+02:00:
> ...
> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>> ... But ISO/IEC CD 9075-15
>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to
>> Working Group".  Is that how they say "returned with feedback"?
>> ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has also reached stage
>> 30.60.  Does anyone know what that one is about?  ...

@Peter B. Can you clarify the stage?

Regarding the differences of array functions of the ISO proposal, I
have no clue why the working group did not follow the implementation
of PostgreSQL.

@Peter B. You know PostgreSQL well. Can you explain?

:Stefan

P.S. 2016-07-02 17:11 GMT+02:00 Tom Lane  wrote:
> Peter E. had observer status at one point, don't know if he still does.
@Peter E.: Do you still have observer status at the ISO committee?



2016-07-06 13:19 GMT+02:00 Stefan Keller :
> Thomas
>
> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>> ... But ISO/IEC CD 9075-15
>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to
>> Working Group".  Is that how they say "returned with feedback"?
>> ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has also reached stage
>> 30.60.  Does anyone know what that one is about?  Maybe something like
>
> Peter surely would know: https://www.jacobs-university.de/directory/pbaumann
>
> :Stefan
>
> 2016-07-04 6:44 GMT+02:00 Thomas Munro :
>> On Wed, Jun 29, 2016 at 11:51 AM, Stefan Keller  wrote:
>>> Hi,
>>>
>>> FYI: I'd just like to point you to following two forthcoming standard
>>> parts from "ISO/IEC JTS 1/SC 32" comittee: one on JSON, and one on
>>> "Multi-Dimensional Arrays" (SQL/MDA).
>>>
>>> They define there some things different as already in PG. See also
>>> Peter Baumann's slides [1] and e.g. [2]
>>>
>>> :Stefan
>>>
>>> [1] 
>>> https://www.unibw.de/inf4/professors/geoinformatics/agile-2016-workshop-gis-with-nosql
>>> [2] 
>>> http://jtc1sc32.org/doc/N2501-2550/32N2528-WG3-Tutorial-Opening-Plenary.pdf
>>
>> Thanks for these pointers.  On the "standards under development"
>> page[1], I see that ISO/IEC PDTR 19075-6 (SQL/JSON) is at stage 30.60
>> "Close of voting/ comment period".  But ISO/IEC CD 9075-15
>> (Multi-Dimensional Arrays) is in stage 30.92 "CD referred back to
>> Working Group".  Is that how they say "returned with feedback"?
>> ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has also reached stage
>> 30.60.  Does anyone know what that one is about?  Maybe something like
>> MATCH_RECOGNIZE in Oracle?
>>
>> [1] 
>> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=45342=on
>>
>> --
>> Thomas Munro
>> http://www.enterprisedb.com


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


Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-09 Thread Fabien COELHO



Also a more subjective argument: I do not like the gset automagic naming
feature. I got more inspired by PL/pgSQL and ECPG which both have an "into"
syntax with explicit variable names that let nothing to guessing. I like
things to be simple and explicit, hence the proposed into.


the gset was originally designed differently - but now it is here - and it
is not practical to have two different, but pretty similar statements in
psql and pgbench.


In my view they are unrelated: on the one hand "gset" is really an 
interactive feature, where typing is costly so "automagic" might make 
sense; on the other hand "into" is a scripting feature, where you want to 
understand the code and have something as readable as possible, without 
surprises.


The commands are named differently and behave differently.

If someone thinks that "gset" is a good idea for pgbench, which I don't, 
it could be implemented. I think that an "into" feature, like PL/pgSQL & 
ECPG, makes more sense for scripting.


--
Fabien.


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


Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-09 Thread Pavel Stehule
2016-07-09 11:19 GMT+02:00 Fabien COELHO :

>
> Hello Pavel,
>
> Why you are introducing \into and not \gset like psql does?
>>
>
> Good question.
>
> The \into syntax I implemented is more generic, you can send a bunch of
> queries together and extract the results, which makes sense from a client
> perspective where reducing latency is important:
>
>SELECT 1, 2 \; SELECT 3;
>\into one two three
>

I understand, but it looks little bit scary - but the argument of reducing
latency can be valid

>
> However "gset" only works on the last SELECT and if all columns have a
> name. This feature probably makes sense interactively, but for a script it
> seems more useful to allow batch processing and collect results afterwards.
>
> Also a more subjective argument: I do not like the gset automagic naming
> feature. I got more inspired by PL/pgSQL and ECPG which both have an "into"
> syntax with explicit variable names that let nothing to guessing. I like
> things to be simple and explicit, hence the proposed into.
>

the gset was originally designed differently - but now it is here - and it
is not practical to have two different, but pretty similar statements in
psql and pgbench.

Regards

Pavel



>
> --
> Fabien.
>


Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-09 Thread Fabien COELHO


Hello Pavel,


Why you are introducing \into and not \gset like psql does?


Good question.

The \into syntax I implemented is more generic, you can send a bunch of 
queries together and extract the results, which makes sense from a client 
perspective where reducing latency is important:


   SELECT 1, 2 \; SELECT 3;
   \into one two three

However "gset" only works on the last SELECT and if all columns have a 
name. This feature probably makes sense interactively, but for a script it 
seems more useful to allow batch processing and collect results 
afterwards.


Also a more subjective argument: I do not like the gset automagic naming 
feature. I got more inspired by PL/pgSQL and ECPG which both have an 
"into" syntax with explicit variable names that let nothing to guessing. I 
like things to be simple and explicit, hence the proposed into.


--
Fabien.


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


Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-09 Thread Pavel Stehule
Hi

2016-07-09 10:20 GMT+02:00 Fabien COELHO :

>
> Hello devs,
>
> I mentionned my intention to add some features to pgbench back in March:
>
> https://www.postgresql.org/message-id/alpine.DEB.2.10.1603301618570.5677@sto
>
> The attached patch adds an \into meta command to store results of
> preceding SELECTs into pgbench variables, so that they can be reused
> afterwards.
>
> The feature is useful to make more realistic scripts, currently pgbench
> script cannot really interact with the database as results are discarded.
>
> The chosen syntax is easy to understand and the implementation is quite
> light, with minimal impact on the code base. I think that this is a
> reasonnable compromise.
>
> The SELECTs must yield exactly one row, the number of variables must be
> less than the number of columns.
>
> Also attached a set of test scripts, especially to trigger various error
> cases.
>
>
Why you are introducing \into and not \gset like psql does?

Regards

Pavel


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


[HACKERS] pgbench - compute & show latency consistently

2016-07-09 Thread Fabien COELHO


Currently the latency is not computed and displayed consistently:

 - the computation is wrong under -t (duration is zero...)

 - depending on the conditions it is shown with a ":" syntax or
   a "=" syntax.

The attached minor patch makes the computation & display more consistent.

--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f3afedb..26c030e 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -1254,8 +1254,8 @@ number of clients: 10
 number of threads: 1
 number of transactions per client: 1000
 number of transactions actually processed: 1/1
-latency average = 15.844 ms
-latency stddev = 2.715 ms
+latency average: 15.844 ms
+latency stddev: 2.715 ms
 tps = 618.764555 (including connections establishing)
 tps = 622.977698 (excluding connections establishing)
 script statistics:
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 87fb006..6eb9f28 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -3237,8 +3237,8 @@ printSimpleStats(char *prefix, SimpleStats *ss)
 	double		latency = ss->sum / ss->count;
 	double		stddev = sqrt(ss->sum2 / ss->count - latency * latency);
 
-	printf("%s average = %.3f ms\n", prefix, 0.001 * latency);
-	printf("%s stddev = %.3f ms\n", prefix, 0.001 * stddev);
+	printf("%s average: %.3f ms\n", prefix, 0.001 * latency);
+	printf("%s stddev: %.3f ms\n", prefix, 0.001 * stddev);
 }
 
 /* print out results */
@@ -3291,9 +3291,9 @@ printResults(TState *threads, StatsData *total, instr_time total_time,
 	if (throttle_delay || progress || latency_limit)
 		printSimpleStats("latency", >latency);
 	else
-		/* only an average latency computed from the duration is available */
+		/* no measure, show average latency computed from run time */
 		printf("latency average: %.3f ms\n",
-			   1000.0 * duration * nclients / total->cnt);
+			   1000.0 * time_include * nclients / total->cnt);
 
 	if (throttle_delay)
 	{

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


[HACKERS] pgbench - allow to store select results into variables

2016-07-09 Thread Fabien COELHO


Hello devs,

I mentionned my intention to add some features to pgbench back in March:
https://www.postgresql.org/message-id/alpine.DEB.2.10.1603301618570.5677@sto

The attached patch adds an \into meta command to store results of 
preceding SELECTs into pgbench variables, so that they can be reused 
afterwards.


The feature is useful to make more realistic scripts, currently pgbench 
script cannot really interact with the database as results are discarded.


The chosen syntax is easy to understand and the implementation is quite 
light, with minimal impact on the code base. I think that this is a 
reasonnable compromise.


The SELECTs must yield exactly one row, the number of variables must be 
less than the number of columns.


Also attached a set of test scripts, especially to trigger various error 
cases.


--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f3afedb..8a7ad3e 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -809,6 +809,29 @@ pgbench  options  dbname
   
 
   
+   
+
+ \into var1 [var2 ...]
+
+
+
+ 
+  Stores the first fields of the resulting row from the preceding
+  SELECT commands into these variables.
+  The queries must yield exactly one row and the number of provided
+  variables must be less than the total number of columns of the results.
+ 
+
+ 
+  Example:
+
+SELECT abalance FROM pgbench_accounts WHERE aid=5432;
+\into balance
+
+ 
+
+   
+

 
  \set varname expression
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 87fb006..d9827dc 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -307,6 +307,7 @@ typedef struct
 	int			type;			/* command type (SQL_COMMAND or META_COMMAND) */
 	int			argc;			/* number of command words */
 	char	   *argv[MAX_ARGS]; /* command word list */
+	char	   *into[MAX_ARGS]; /* NULL-terminated target variables for \into */
 	PgBenchExpr *expr;			/* parsed expression, if needed */
 	SimpleStats stats;			/* time spent in this command */
 } Command;
@@ -1148,6 +1149,96 @@ getQueryParams(CState *st, const Command *command, const char **params)
 		params[i] = getVariable(st, command->argv[i + 1]);
 }
 
+/* read all responses from backend */
+static bool
+read_response(CState *st, char * into[])
+{
+	PGresult   *res;
+	int			i = 0;
+	bool		at_least_one = false;
+
+	while ((res = PQgetResult(st->con)) != NULL)
+	{
+		at_least_one = true;
+
+		switch (PQresultStatus(res))
+		{
+		case PGRES_COMMAND_OK: /* non-SELECT commands */
+		case PGRES_EMPTY_QUERY: /* may be used for testing no-op overhead */
+			break; /* OK */
+
+		case PGRES_TUPLES_OK:
+			if (into != NULL && into[i] != NULL)
+			{
+/* store result into variables */
+int ntuples = PQntuples(res),
+	nfields = PQnfields(res),
+	f = 0;
+
+if (ntuples != 1)
+{
+	fprintf(stderr,
+			"client %d state %d expecting one row, got %d\n",
+			st->id, st->state, ntuples);
+	st->ecnt++;
+	PQclear(res);
+	discard_response(st);
+	return false;
+}
+
+while (into[i] != NULL && f < nfields)
+{
+	/* store result as a string */
+	if (!putVariable(st, "into", into[i], PQgetvalue(res, 0, f)))
+	{
+		/* internal error, should it rather abort? */
+		fprintf(stderr,
+"client %d state %d: error storing into var %s\n",
+st->id, st->state, into[i]);
+		st->ecnt++;
+		PQclear(res);
+		discard_response(st);
+		return false;
+	}
+
+	i++;
+	f++;
+}
+			}
+			break;	/* OK */
+
+		default:
+			/* everything else is unexpected, so probably an error */
+			fprintf(stderr, "client %d aborted in state %d: %s",
+	st->id, st->state, PQerrorMessage(st->con));
+			st->ecnt++;
+			PQclear(res);
+			discard_response(st);
+			return false;
+		}
+
+		PQclear(res);
+	}
+
+	if (!at_least_one)
+	{
+		fprintf(stderr, "client %d state %d: no results\n", st->id, st->state);
+		st->ecnt++;
+		return false;
+	}
+
+	if (into != NULL && into[i] != NULL)
+	{
+		fprintf(stderr,
+"client %d state %d: missing results to fill into variable %s\n",
+st->id, st->state, into[i]);
+		st->ecnt++;
+		return false;
+	}
+
+	return true;
+}
+
 /* get a value as an int, tell if there is a problem */
 static bool
 coerceToInt(PgBenchValue *pval, int64 *ival)
@@ -1764,7 +1855,6 @@ chooseScript(TState *thread)
 static bool
 doCustom(TState *thread, CState *st, StatsData *agg)
 {
-	PGresult   *res;
 	Command   **commands;
 	bool		trans_needs_throttle = false;
 	instr_time	now;
@@ -1891,22 +1981,11 @@ top:
 		{
 			/*
 			 * Read and discard the query result; note this is not included in
-			 * the statement latency numbers.
+			 * the statement latency numbers (above), thus if reading the
+			 * response fails the transaction is counted nevertheless.
 			 */
-			res = PQgetResult(st->con);
-			switch (PQresultStatus(res))
-			{
-case 

[HACKERS] pgbench - minor doc improvements

2016-07-09 Thread Fabien COELHO


Minor pgbench documentation improvements so that the description is more
precise:

 - a pgbench script may not contain SQL commands, it only needs not to be
   empty.

 - point out explicitely variable setting meta commands.

 - the formula is short enough to fit on a line.

--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f3afedb..8224417 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -744,11 +744,10 @@ pgbench  options  dbname
   
 
   
-   A script file contains one or more SQL commands terminated by
-   semicolons.  Empty lines and lines beginning with
-   -- are ignored.  Script files can also contain
-   meta commands, which are interpreted by pgbench
-   itself, as described below.
+   A script file contains one or more commands, which are either SQL commands
+   terminated by semicolons or meta commands interpreted by
+   pgbench itself, as described below.
+   Empty lines and lines beginning with -- are ignored.
   
 
   
@@ -766,13 +765,13 @@ pgbench  options  dbname
   
There is a simple variable-substitution facility for script files.
Variables can be set by the command-line -D option,
-   explained above, or by the meta commands explained below.
+   explained above, or by meta commands \set and
+   \setshell explained below.
In addition to any variables preset by -D command-line options,
there are a few variables that are preset automatically, listed in
. A value specified for these
variables using -D takes precedence over the automatic presets.
-   Once set, a variable's
-   value can be inserted into a SQL command by writing
+   Once set, a variable's value can be inserted into a SQL command by writing
:variablename.  When running more than
one client session, each session has its own set of variables.
   
@@ -1064,8 +1063,7 @@ f(x) = exp(-parameter * (x - min) / (max - min + 1)) / (1 - exp(-parameter))
   function of the standard normal distribution, with mean mu
   defined as (max + min) / 2.0, with
 
-f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) /
-   (2.0 * PHI(parameter) - 1)
+f(x) = PHI(2.0 * parameter * (x - mu) / (max - min + 1)) / (2.0 * PHI(parameter) - 1)
 
   then value i between min and
   max inclusive is drawn with probability:

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


[HACKERS] pgbench - allow empty queries

2016-07-09 Thread Fabien COELHO


I wanted to test overheads on an empty query, but pgbench does not allow 
it. I do not see why not.


The attached very minor patch allows empty queries.

--
Fabien.

pgbench-empty-query-1.sql
Description: application/sql


empty.sql
Description: application/sql

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


[HACKERS] pgbench - minor fix for meta command only scripts

2016-07-09 Thread Fabien COELHO


While testing meta-command pgbench only scripts, I noticed that there is 
an infinite loop in threadRun, which means that other tasks such as 
reporting progress do not get a chance.


The attached patch breaks this loop by always returning at the end of a 
script.


On "pgbench -T 3 -P 1 -f noop.sql", before this patch, the progress is not 
shown, after it is.


--
Fabien.

pgbench-no-sql-fix-1.sql
Description: application/sql


noop.sql
Description: application/sql

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


Re: [HACKERS] pgbench more operators & functions

2016-07-09 Thread Fabien COELHO


Here is a simple patch which adds a bunch of operators (bitwise: & | ^ ~, 
comparisons: =/== <>/!= < <= > >=, logical: and/&& or/|| xor/^^ not/!) and 
functions (exp ln if) to pgbench. I've tried to be pg's SQL compatible where 
appropriate.


Also attached is a simple test script.


Here is a sightly updated version.

--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index f3afedb..ea319f6 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -821,9 +821,17 @@ pgbench  options  dbname
   The expression may contain integer constants such as 5432,
   double constants such as 3.14159,
   references to variables :variablename,
-  unary operators (+, -) and binary operators
-  (+, -, *, /,
-  %) with their usual precedence and associativity,
+  arithmetic operators (unary: +, -; binary:
+  +, -, *, /, %),
+  bitwise operators (unary: ~; binary: ,
+  |, #/^, ,
+  )
+  comparisons (=/==, /!=,
+  =, , =, ),
+  logical operators (unary: not/!;
+  binary: and/,
+  or/||, xor/^^),
+  with their usual precedence and associativity,
   function calls, and
   parentheses.
  
@@ -955,6 +963,13 @@ pgbench  options  dbname
5432.0
   
   
+   exp(x)
+   double
+   exponential
+   exp(1.0)
+   2.718281828459045
+  
+  
greatest(a [, ... ] )
double if any a is double, else integer
largest value among arguments
@@ -962,6 +977,13 @@ pgbench  options  dbname
5
   
   
+   if(c,e1,e2)
+   same as e*
+   if c is not zero then e1 else e2
+   if(0,1.0,2.0)
+   2.0
+  
+  
int(x)
integer
cast to int
@@ -976,6 +998,13 @@ pgbench  options  dbname
2.1
   
   
+   ln(x)
+   double
+   natural logarithm
+   ln(2.718281828459045)
+   1.0
+  
+  
pi()
double
value of the constant PI
diff --git a/src/bin/pgbench/exprparse.y b/src/bin/pgbench/exprparse.y
index 0cc665b..233de9c 100644
--- a/src/bin/pgbench/exprparse.y
+++ b/src/bin/pgbench/exprparse.y
@@ -52,8 +52,22 @@ static PgBenchExpr *make_func(yyscan_t yyscanner, int fnumber, PgBenchExprList *
 %type  VARIABLE FUNCTION
 
 %token INTEGER_CONST DOUBLE_CONST VARIABLE FUNCTION
+%token AND_OP OR_OP XOR_OP NE_OP LE_OP GE_OP LS_OP RS_OP
 
 /* Precedence: lowest to highest */
+
+/* logical */
+%left	XOR_OP
+%left	OR_OP
+%left	AND_OP
+%right  UNOT
+/* comparison */
+%left	'=' NE_OP
+%left	'<' '>' LE_OP GE_OP
+/* bitwise */
+%left	'^' '|' '&' LS_OP RS_OP
+%right	UINV
+/* arithmetic */
 %left	'+' '-'
 %left	'*' '/' '%'
 %right	UMINUS
@@ -71,11 +85,29 @@ expr: '(' expr ')'			{ $$ = $2; }
 	| '+' expr %prec UMINUS	{ $$ = $2; }
 	| '-' expr %prec UMINUS	{ $$ = make_op(yyscanner, "-",
 		   make_integer_constant(0), $2); }
+	| '~' expr %prec UINV	{ $$ = make_op(yyscanner, "^",
+		   make_integer_constant(-1), $2); }
+	| '!' expr %prec UNOT	{ $$ = make_op(yyscanner, "^^",
+		   make_integer_constant(1), $2); }
 	| expr '+' expr			{ $$ = make_op(yyscanner, "+", $1, $3); }
 	| expr '-' expr			{ $$ = make_op(yyscanner, "-", $1, $3); }
 	| expr '*' expr			{ $$ = make_op(yyscanner, "*", $1, $3); }
 	| expr '/' expr			{ $$ = make_op(yyscanner, "/", $1, $3); }
 	| expr '%' expr			{ $$ = make_op(yyscanner, "%", $1, $3); }
+	| expr '<' expr			{ $$ = make_op(yyscanner, "<", $1, $3); }
+	| expr LE_OP expr		{ $$ = make_op(yyscanner, "<=", $1, $3); }
+	| expr '>' expr			{ $$ = make_op(yyscanner, "<", $3, $1); }
+	| expr GE_OP expr		{ $$ = make_op(yyscanner, "<=", $3, $1); }
+	| expr '=' expr			{ $$ = make_op(yyscanner, "=", $1, $3); }
+	| expr NE_OP expr		{ $$ = make_op(yyscanner, "<>", $1, $3); }
+	| expr '&' expr			{ $$ = make_op(yyscanner, "&", $1, $3); }
+	| expr '|' expr			{ $$ = make_op(yyscanner, "|", $1, $3); }
+	| expr '^' expr			{ $$ = make_op(yyscanner, "^", $1, $3); }
+	| expr LS_OP expr		{ $$ = make_op(yyscanner, "<<", $1, $3); }
+	| expr RS_OP expr		{ $$ = make_op(yyscanner, ">>", $1, $3); }
+	| expr AND_OP expr		{ $$ = make_op(yyscanner, "&&", $1, $3); }
+	| expr OR_OP expr		{ $$ = make_op(yyscanner, "||", $1, $3); }
+	| expr XOR_OP expr		{ $$ = make_op(yyscanner, "^^", $1, $3); }
 	| INTEGER_CONST			{ $$ = make_integer_constant($1); }
 	| DOUBLE_CONST			{ $$ = make_double_constant($1); }
 	| VARIABLE { $$ = make_variable($1); }
@@ -177,6 +209,12 @@ static const struct
 		"sqrt", 1, PGBENCH_SQRT
 	},
 	{
+		"ln", 1, PGBENCH_LN
+	},
+	{
+		"exp", 1, PGBENCH_EXP
+	},
+	{
 		"int", 1, PGBENCH_INT
 	},
 	{
@@ -191,6 +229,45 @@ static const struct
 	{
 		"random_exponential", 3, PGBENCH_RANDOM_EXPONENTIAL
 	},
+	{
+		"&&", 2, PGBENCH_AND
+	},
+	{
+		"||", 2, PGBENCH_OR
+	},
+	{
+		"^^", 2, PGBENCH_XOR
+	},
+	{
+		"&", 2, PGBENCH_BITAND
+	},
+	{
+		"|", 2, PGBENCH_BITOR
+	},
+	{
+		"^", 2, PGBENCH_BITXOR
+	},
+	{
+		"<<", 2, 

Re: [HACKERS] [BUGS] BUG #14230: Wrong timeline returned by pg_stop_backup on a standby

2016-07-09 Thread Amit Kapila
On Thu, Jul 7, 2016 at 12:08 PM, Michael Paquier
 wrote:
> On Thu, Jul 7, 2016 at 12:57 AM, Marco Nenciarini
>  wrote:
>> After further analysis, the issue is that we retrieve the starttli from
>> the ControlFile structure, but it was using ThisTimeLineID when writing
>> the backup label.
>>
>> I've attached a very simple patch that fixes it.
>
> ThisTimeLineID is always set at 0 on purpose on a standby, so we
> cannot rely on it (well it is set temporarily when recycling old
> segments). At recovery when parsing the backup_label file there is no
> actual use of the start segment name, so that's only a cosmetic
> change. But surely it would be better to get that fixed, because
> that's useful for debugging.
>
> While looking at your patch, I thought that it would have been
> tempting to use GetXLogReplayRecPtr() to get the timeline ID when in
> recovery, but what we really want to know here is the timeline of the
> last REDO pointer, which is starttli, and that's more consistent with
> the fact that we use startpoint when writing the backup_label file. In
> short, +1 for this fix.
>

+1, the fix looks right to me as well.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


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