Switch in psql_scan() must cover all lexer states (except backslash cases).
Oversight in commit f7559c0101afa33bfb4e104036ca46adac900111, which changed
UESCAPE lexing in psql. Per bug #9068 from Manuel Gómez.
Branch
--
REL9_3_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/1c
Switch in psql_scan() must cover all lexer states (except backslash cases).
Oversight in commit f7559c0101afa33bfb4e104036ca46adac900111, which changed
UESCAPE lexing in psql. Per bug #9068 from Manuel Gómez.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/47aaebaac
Gavin Flower writes:
> Can I assume:
> 'Total runtime' is 'elapsed time'
> and
> 'Execution time' is 'processor time'.
No. It's going to be elapsed time, either way.
> In a parallel implementation, one would likely want both.
When and if we have that, we can argue about what to measure.
On 03/02/14 09:44, Peter Geoghegan wrote:
On Sun, Feb 2, 2014 at 8:13 AM, Tom Lane wrote:
Perhaps s/Total runtime/Execution time/ ?
+1
If the planning was ever made into a parallel process, then 'elapsed
time' would be less than the 'processor time'. So what does 'Execution
time' mean?
On Sun, Feb 2, 2014 at 8:13 AM, Tom Lane wrote:
> Perhaps s/Total runtime/Execution time/ ?
+1
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Add for functions pg_sleep_for and pg_sleep_until.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c087e8cf3470081546c74b43e086e2b4d0a255d3
Modified Files
--
doc/src/sgml/func.sgml |6 ++
1 file changed, 6 insertions(+)
--
Sent via pgsql-commit
Clean up some sloppy coding in repl_gram.y.
Remove unused copy-and-pasted macro definitions, and improve formatting
of recently-added productions.
I got interested in this because buildfarm member protosciurus has been
crashing in "bison repl_gram.y" since commit 858ec11. It's a long shot
that t
Peter Geoghegan writes:
> On Wed, Jan 29, 2014 at 1:10 PM, Robert Haas wrote:
>> Include planning time in EXPLAIN ANALYZE output.
> Isn't it perhaps a little confusing that "Planning time" may well
> exceed "Total runtime"?
Perhaps s/Total runtime/Execution time/ ?
rega
Add primary_slotname to recovery.conf.sample.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/0753bdb352270a03dec52bc959418fa82e9b07cc
Modified Files
--
src/backend/access/transam/recovery.conf.sample |6 ++
1 file changed, 6 insertions(+)
--
Se
On Sun, Feb 2, 2014 at 11:06 PM, Andres Freund wrote:
> On 2014-02-02 14:44:17 +0900, Fujii Masao wrote:
>> On Sat, Feb 1, 2014 at 6:37 PM, Andres Freund wrote:
>> > On 2014-02-01 18:33:08 +0900, Fujii Masao wrote:
>> >> On Sat, Feb 1, 2014 at 6:09 PM, Andres Freund
>> >> wrote:
>> >> > On 2014
On 2014-02-02 14:44:17 +0900, Fujii Masao wrote:
> On Sat, Feb 1, 2014 at 6:37 PM, Andres Freund wrote:
> > On 2014-02-01 18:33:08 +0900, Fujii Masao wrote:
> >> On Sat, Feb 1, 2014 at 6:09 PM, Andres Freund
> >> wrote:
> >> > On 2014-02-01 16:47:47 +0900, Fujii Masao wrote:
> >> >> This patch c
On Wed, Jan 29, 2014 at 1:10 PM, Robert Haas wrote:
> Include planning time in EXPLAIN ANALYZE output.
Isn't it perhaps a little confusing that "Planning time" may well
exceed "Total runtime"? I'm aware that we aren't super clear on the
accounting here generally, as with pg_stat_statements, which
12 matches
Mail list logo