Fix broken wait-for-previous-process-to-exit loop in regression test.
Must do pg_stat_clear_snapshot() inside test's loop, or our snapshot of
pg_stat_activity will never change :-(. Thinko in b3427dade -- evidently
my workstation never really iterated the loop in testing. Per buildfarm.
Branch
Fix thinko in b3427dade14cc31eb48740bc9ea98b5954470b24.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/767a9039d79e35c78afa39cf5ffa3b485a2e3a5b
Modified Files
--
src/include/utils/dsa.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
Sent via
Delete deleteWhatDependsOn() in favor of more performDeletion() flag bits.
deleteWhatDependsOn() had grown an uncomfortably large number of
assumptions about what it's used for. There are actually only two minor
differences between what it does and what a regular performDeletion() call
can do, so
Introduce dynamic shared memory areas.
Programmers discovered decades ago that it was useful to have a simple
interface for allocating and freeing memory, which is why malloc() and
free() were invented. Unfortunately, those handy tools don't work
with dynamic shared memory segments because those
Management of free memory pages.
This is intended as infrastructure for a full-fledged allocator for
dynamic shared memory. The interface looks a bit like a real
allocator, but only supports allocating and freeing memory in
multiples of the 4kB page size. Further, to free memory, you must
know t
Add a crude facility for dealing with relative pointers.
C doesn't have any sort of built-in understanding of a pointer
relative to some arbitrary base address, but dynamic shared memory
segments can be mapped at different addresses in different processes,
so any sort of shared data structure stor
Clarify that pg_stat_activity.query has a length limit.
There was always documentation of the GUC that controlled what the
limit actually was, but previously the documentation of the field
itself made no mention of that limit.
Ian Barwick
Branch
--
master
Details
---
http://git.postgres
Fix outdated comments
Commit 597a87ccc9a6f neglected to update some comments; fix.
Report and patch by Thomas Munro.
Reviewed by Petr Jelínek.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/5e5986b6cbebcb57e6c95463031eef01e099e7e1
Modified Files
--
src
Add max_parallel_workers GUC.
Increase the default value of the existing max_worker_processes GUC
from 8 to 16, and add a new max_parallel_workers GUC with a maximum
of 8. This way, even if the maximum amount of parallel query is
happening, there is still room for background workers that do other
Petr Jelinek wrote:
> Yes, that seems to be the case.
>
> Something as simple as attached should do.
Pushed.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-committers mailing list (pgsql-c
Fix Windows build for 78c8c814390f
Author: Petr Jelínek
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/5714931b075b2dc8994b6e464ea3845c33ecf416
Modified Files
--
src/include/replication/walreceiver.h | 36 +--
1 file chang
On 02/12/16 05:17, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>>> Refactor libpqwalreceiver
>>
>> Buildfarm results indicate this broke the Windows build.
>
> src/backend/replication/walreceiver.c(296): error C2039: 'pgwin32_connect' :
> is not a member of 'WalReceiverFu
12 matches
Mail list logo
