On Tue, Mar 22, 2016 at 10:20 AM, Andrew Dunstan wrote:
>
>
> On 03/21/2016 09:25 AM, Tom Lane wrote:
>>
>> Andres Freund writes:
>>>
>>> On 2016-03-21 22:38:50 +1300, David Rowley wrote:
Perl is not my native tongue, but after a little study and some
testing on a windows machine,
On 03/21/2016 09:25 AM, Tom Lane wrote:
Andres Freund writes:
On 2016-03-21 22:38:50 +1300, David Rowley wrote:
Perl is not my native tongue, but after a little study and some
testing on a windows machine, the attached seems to fix the problem.
I've pushed this, as I would like the buildfar
Improve header output from psql's \watch command.
Include the \pset title string if there is one, and shorten the prefab
part of the header to be "timestamp (every Ns)". Per suggestion by
David Johnston.
Michael Paquier and Tom Lane
Branch
--
master
Details
---
http://git.postgresql.or
Allow the delay in psql's \watch command to be a fractional second.
Instead of just "2" seconds, allow eg. "2.5" seconds. Per request
from Alvaro Herrera. No docs change since the docs didn't say you
couldn't do this already.
Branch
--
master
Details
---
http://git.postgresql.org/pg/co
Andres Freund writes:
> Introduce WaitEventSet API.
Buildfarm member gaur has a quibble with this patch:
latch.c:1095: warning: `WaitEventSetWaitBlock' declared inline after being
called
Please rearrange the file so that the inline function definitions appear
first. Also, why is it that only
Clean up some Coverity complaints about commit 0bf3ae88af330496.
The two get_tle_by_resno() calls introduced by this commit lacked any
check for a NULL return, unlike any other calls of that function anywhere
in our tree. Coverity quite properly complained about it. Also fix a
misindented line i
On 22 March 2016 at 02:33, Andres Freund wrote:
> On 2016-03-21 09:25:18 -0400, Tom Lane wrote:
>> Shouldn't we revert 6f1f34c92b11593e? AFAICS this patch isn't depending
>> on that, but maybe I miss something.
>
> Hm. I'd guess that at least part of it is still required. AddSimpleFrontend()
> af
Make max_parallel_degree PGC_USERSET.
It was intended to be this way all along, just like other planner
GUCs such as work_mem. But I goofed.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/ae507d9222989f2fd8455cf32d4dcb337ccf32bb
Modified Files
--
src/b
On 2016-03-21 09:25:18 -0400, Tom Lane wrote:
> Shouldn't we revert 6f1f34c92b11593e? AFAICS this patch isn't depending
> on that, but maybe I miss something.
Hm. I'd guess that at least part of it is still required. AddSimpleFrontend()
afaics processes these variables, and I don't think the msvc
Support parallel aggregation.
Parallel workers can now partially aggregate the data and pass the
transition values back to the leader, which can combine the partial
results to produce the final answer.
David Rowley, based on earlier work by Haribabu Kommi. Reviewed by
Álvaro Herrera, Tomas Vondr
Andres Freund writes:
> On 2016-03-21 22:38:50 +1300, David Rowley wrote:
>> Perl is not my native tongue, but after a little study and some
>> testing on a windows machine, the attached seems to fix the problem.
> I've pushed this, as I would like the buildfarm to be green before
> pushing the l
Properly declare FeBeWaitSet.
Surprising that this worked on a number of systems. Reported by
buildfarm member longfin.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7fa0064092e135415a558dc3c4d7393d14ab6d8e
Modified Files
--
src/backend/libpq/pqcomm.c
Introduce WaitEventSet API.
Commit ac1d794 ("Make idle backends exit if the postmaster dies.")
introduced a regression on, at least, large linux systems. Constantly
adding the same postmaster_alive_fds to the OSs internal datastructures
for implementing poll/select can cause significant contention
Combine win32 and unix latch implementations.
Previously latches for windows and unix had been implemented in
different files. A later patch introduce an expanded wait
infrastructure, keeping the implementation separate would introduce too
much duplication.
This basically just moves the functions
On 2016-03-21 22:38:50 +1300, David Rowley wrote:
> On 21 March 2016 at 10:52, Tom Lane wrote:
> > Best-guess attempt at fixing MSVC build for 68ab8e8ba4a471d9.
> >
> > pgbench now needs to use src/bin/psql/psqlscan.l, but it's not very clear
> > how to fit that into the MSVC build system. If thi
Second attempt at fixing MSVC build for 68ab8e8ba4a471d9.
After the previous fix in 6f1f34c9 msvc ended up looking for psqlscan.c
in the wrong directory.
David's fix just forces the path to be adjusted. That's not a
particularly pretty fix, but it hopefully will make the buildfarm green
again.
A
On 21 March 2016 at 10:52, Tom Lane wrote:
> Best-guess attempt at fixing MSVC build for 68ab8e8ba4a471d9.
>
> pgbench now needs to use src/bin/psql/psqlscan.l, but it's not very clear
> how to fit that into the MSVC build system. If this doesn't work I'm going
> to need some help from somebody w
17 matches
Mail list logo
