On Fri, Mar 11, 2016 at 2:08 AM, Amit Langote
wrote:
> On 2016/03/11 8:19, Peter Geoghegan wrote:
>> On Thu, Mar 10, 2016 at 1:22 PM, Andres Freund wrote:
>>> Yeha!
>>
>> Fantastic effort, particularly from Masahiko. Well done.
>
> +1!
Yuhu.
--
Michael
--
Sent via pgsql-committers mailing li
On Fri, Mar 11, 2016 at 2:29 AM, Andres Freund wrote:
> Checkpoint sorting and balancing.
+1.
--
Michael
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Simplify GetLockNameFromTagType.
The old code is wrong, because it returns a pointer to an automatic
variable. And it's also more clever than we really need to be
considering that the case it's worrying about should never happen.
Branch
--
master
Details
---
http://git.postgresql.org/pg
On 3/10/16 8:52 PM, Andres Freund wrote:
> Hrmpf. I tried to fix the issue; could you quickly verify?
looks good
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 3/10/16 7:32 PM, Andres Freund wrote:
> On 2016-03-10 18:55:47 +, Robert Haas wrote:
>> Provide much better wait information in pg_stat_activity.
>>
>> When a process is waiting for a heavyweight lock, we will now indicate
>> the type of heavyweight lock for which it is waiting. Also, you c
On 2016-03-10 20:47:10 -0500, Peter Eisentraut wrote:
> On 3/10/16 8:29 PM, Andres Freund wrote:
> > Checkpoint sorting and balancing.
>
> This patch appears to have introduced a change that makes the build
> with dtrace fail:
>
> In file included from ../../../../src/include/pg_trace.h:15:0,
>
Blindly try to fix dtrace enabled builds, broken in 9cd00c45.
Reported-By: Peter Eisentraut
Discussion: 56e2239e.1050...@gmx.net
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c94f0c29cecc7944a14aa645c8a97a7250bf146b
Modified Files
--
src/backend/storag
On 3/10/16 8:29 PM, Andres Freund wrote:
> Checkpoint sorting and balancing.
This patch appears to have introduced a change that makes the build
with dtrace fail:
In file included from ../../../../src/include/pg_trace.h:15:0,
from bufmgr.c:42:
bufmgr.c: In function 'BufferSync':
Checkpoint sorting and balancing.
Up to now checkpoints were written in the order they're in the
BufferDescriptors. That's nearly random in a lot of cases, which
performs badly on rotating media, but even on SSDs it causes slowdowns.
To avoid that, sort checkpoints before writing them out. We cur
Allow to trigger kernel writeback after a configurable number of writes.
Currently writes to the main data files of postgres all go through the
OS page cache. This means that some operating systems can end up
collecting a large number of dirty buffers in their respective page
caches. When these d
On 2016/03/11 8:19, Peter Geoghegan wrote:
> On Thu, Mar 10, 2016 at 1:22 PM, Andres Freund wrote:
>> Yeha!
>
> Fantastic effort, particularly from Masahiko. Well done.
+1!
- Amit
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscripti
On 2016-03-10 18:55:47 +, Robert Haas wrote:
> Provide much better wait information in pg_stat_activity.
>
> When a process is waiting for a heavyweight lock, we will now indicate
> the type of heavyweight lock for which it is waiting. Also, you can
> now see when a process is waiting for a l
On Thu, Mar 10, 2016 at 1:22 PM, Andres Freund wrote:
> Yeha!
Fantastic effort, particularly from Masahiko. Well done.
--
Peter Geoghegan
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
Give pull_var_clause() reject/recurse/return behavior for WindowFuncs too.
All along, this function should have treated WindowFuncs in a manner
similar to Aggrefs, ie with an option whether or not to recurse into them.
By not considering the case, it was always recursing, which is OK for most
call
On 2016-03-10 21:16:37 +, Robert Haas wrote:
> Don't vacuum all-frozen pages.
Yeha!
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Don't vacuum all-frozen pages.
Commit a892234f830e832110f63fc0a2afce2fb21d1584 gave us enough
infrastructure to avoid vacuuming pages where every tuple on the
page is already frozen. So, replace the notion of a scan_all or
whole-table vacuum with the less onerous notion of an "aggressive"
vacuum,
Refactor pull_var_clause's API to make it less tedious to extend.
In commit 1d97c19a0f748e94 and later c1d9579dd8bf3c92, we extended
pull_var_clause's API by adding enum-type arguments. That's sort of a pain
to maintain, though, because it means every time we add a new behavior we
must touch ever
Hi
2016-03-10 19:55 GMT+01:00 Robert Haas :
> Provide much better wait information in pg_stat_activity.
>
> When a process is waiting for a heavyweight lock, we will now indicate
> the type of heavyweight lock for which it is waiting. Also, you can
> now see when a process is waiting for a light
Rework wait for AccessExclusiveLocks on Hot Standby
Earlier version committed in 9.0 caused spurious waits in some cases.
New infrastructure for lock waits in 9.3 used to correct and improve this.
Jeff Janes based upon a proposal by Simon Riggs, who also reviewed
Additional review comments from A
Provide much better wait information in pg_stat_activity.
When a process is waiting for a heavyweight lock, we will now indicate
the type of heavyweight lock for which it is waiting. Also, you can
now see when a process is waiting for a lightweight lock - in which
case we will indicate the indivi
Andres Freund writes:
> On 2016-03-10 10:57:59 -0500, Tom Lane wrote:
>> sysname | snapshot | count
>> --+-+---
>> okapi | 2012-05-10 06:15:02 | 138
>> okapi | 2012-05-20 00:15:02 | 174
>> dromedary | 2014-03-28 00:13:52 | 4
>> dromedar
On 2016-03-10 10:57:59 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> This is marked as the originating commit for a failure on dromedary:
> >> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02
> >> the origin of the failure is:
> >> FATAL: no
Document BRIN a bit more thoroughly
The chapter "Interfacing Extensions To Indexes" and CREATE OPERATOR
CLASS reference page were missed when BRIN was added. We document
all our other index access methods there, so make sure BRIN complies.
Author: Álvaro Herrera
Reported-By: Julien Rouhaud, Tom
Document BRIN a bit more thoroughly
The chapter "Interfacing Extensions To Indexes" and CREATE OPERATOR
CLASS reference page were missed when BRIN was added. We document
all our other index access methods there, so make sure BRIN complies.
Author: Álvaro Herrera
Reported-By: Julien Rouhaud, Tom
I wrote:
> Andres Freund writes:
>> This is marked as the originating commit for a failure on dromedary:
>> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02
>> the origin of the failure is:
>> FATAL: no PostgreSQL user name specified in startup packet
>> while
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit
build that is later used on a CPU that supports AVX2 instructions using a
version of Windows before 7SP1/2008R2SP1.
Detect this combination, and in those cas
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit
build that is later used on a CPU that supports AVX2 instructions using a
version of Windows before 7SP1/2008R2SP1.
Detect this combination, and in those cas
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit
build that is later used on a CPU that supports AVX2 instructions using a
version of Windows before 7SP1/2008R2SP1.
Detect this combination, and in those cas
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit
build that is later used on a CPU that supports AVX2 instructions using a
version of Windows before 7SP1/2008R2SP1.
Detect this combination, and in those cas
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit
build that is later used on a CPU that supports AVX2 instructions using a
version of Windows before 7SP1/2008R2SP1.
Detect this combination, and in those cas
Avoid crash on old Windows with AVX2-capable CPU for VS2013 builds
The Visual Studio 2013 CRT generates invalid code when it makes a 64-bit
build that is later used on a CPU that supports AVX2 instructions using a
version of Windows before 7SP1/2008R2SP1.
Detect this combination, and in those cas
Reduce size of two phase file header
Previously 2PC header was fixed at 200 bytes, which in most cases wasted
WAL space for a workload using 2PC heavily.
Pavan Deolasee, reviewed by Petr Jelinek
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/e0694cf9c74455fb87beb0f
Reduce lock level for altering fillfactor
Fabrízio de Royes Mello and Simon Riggs
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/fcb4bfddb6ff46e4495b923987ed6a89bd256174
Modified Files
--
doc/src/sgml/ref/alter_table.sgml | 2 +-
src/backend/acc
Code review for b6fb6471f6afaf649e52f38269fd8c5c60647669.
Reports by Tomas Vondra, Vinayak Pokale, and Aleksander Alekseev.
Patch by Amit Langote.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/090b287fc59e7a44da8c3e0823eecdc8ea4522f2
Modified Files
--
34 matches
Mail list logo
