Add UtilityReturnsTuples() support for CALL
This ensures that prepared statements for CALL can return tuples.
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/59a85323d9d5927a852939fa93f09d142c72c91a
Modified Files
--
src/backend/commands/function
Add UtilityReturnsTuples() support for CALL
This ensures that prepared statements for CALL can return tuples.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/ec67b89816012ad753ebbd3489c7e7d0fe80d4ca
Modified Files
--
src/backend/commands/functioncmds.c
Michael Paquier writes:
> On Sun, Jul 08, 2018 at 10:23:37PM +0200, Julien Rouhaud wrote:
>> I just noticed that the number of rows for the IO wait event type
>> documentation hasn't been updated, see
>> https://www.postgresql.org/docs/devel/static/monitoring-stats.html#WAIT-EVENT-TABLE.
>> Trivia
rel notes: mention enabling of parallelism in PG 10
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20180525010025.gt30...@telsasoft.com
Backpatch-through: 10
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b4f0d738c3c33752f82398f5e6d0db09e7c862
rel notes: mention enabling of parallelism in PG 10
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20180525010025.gt30...@telsasoft.com
Backpatch-through: 10
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/b0da7ecad332244364152ff6f00fd0ceb87337
rel notes: mention enabling of parallelism in PG 10
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20180525010025.gt30...@telsasoft.com
Backpatch-through: 10
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/6abad00585b7d3b9bc36e10d5937c27fb6878774
Mod
On 2018-Jul-09, Tom Lane wrote:
> Michael Paquier writes:
> > On Sun, Jul 08, 2018 at 10:23:37PM +0200, Julien Rouhaud wrote:
> >> I just noticed that the number of rows for the IO wait event type
> >> documentation hasn't been updated, see
> >> https://www.postgresql.org/docs/devel/static/monito
Fix yet more problems with incorrectly-constructed zero-length arrays.
Commit 716ea626a attempted to fix the problem of building 1-D zero-size
arrays once and for all. But it turns out that contrib/intarray has some
code that doesn't use construct_array() but just builds arrays by hand,
so it did
Fix yet more problems with incorrectly-constructed zero-length arrays.
Commit 716ea626a attempted to fix the problem of building 1-D zero-size
arrays once and for all. But it turns out that contrib/intarray has some
code that doesn't use construct_array() but just builds arrays by hand,
so it did
Flip argument order in XLogSegNoOffsetToRecPtr
Commit fc49e24fa69a added an input argument after the existing output
argument. Flip those.
Author: Álvaro Herrera
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/20180708182345.imdgovmkffgtihhk@alvherre.pgsql
Branch
--
REL_11_STAB
Flip argument order in XLogSegNoOffsetToRecPtr
Commit fc49e24fa69a added an input argument after the existing output
argument. Flip those.
Author: Álvaro Herrera
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/20180708182345.imdgovmkffgtihhk@alvherre.pgsql
Branch
--
master
Det
On Mon, Jul 9, 2018 at 11:24 AM, Alvaro Herrera
wrote:
> Maybe we should add an XML comment
>
> at the end of the table :-)
+1. I made the same mistake at one point.
--
Peter Geoghegan
Prevent accidental linking of system-supplied copies of libpq.so etc.
Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile
variables into two parts, one for within-build-tree library references and
one for external libraries, to ensure that the order of -L flags has all
of the for
Prevent accidental linking of system-supplied copies of libpq.so etc.
Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile
variables into two parts, one for within-build-tree library references and
one for external libraries, to ensure that the order of -L flags has all
of the for
Prevent accidental linking of system-supplied copies of libpq.so etc.
Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile
variables into two parts, one for within-build-tree library references and
one for external libraries, to ensure that the order of -L flags has all
of the for
Prevent accidental linking of system-supplied copies of libpq.so etc.
Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile
variables into two parts, one for within-build-tree library references and
one for external libraries, to ensure that the order of -L flags has all
of the for
Prevent accidental linking of system-supplied copies of libpq.so etc.
Back-patch commit dddfc4cb2, which broke LDFLAGS and related Makefile
variables into two parts, one for within-build-tree library references and
one for external libraries, to ensure that the order of -L flags has all
of the for
On Mon, Jul 09, 2018 at 12:12:42PM -0700, Peter Geoghegan wrote:
> On Mon, Jul 9, 2018 at 11:24 AM, Alvaro Herrera
> wrote:
> > Maybe we should add an XML comment
> >
> > at the end of the table :-)
>
> +1. I made the same mistake at one point.
Another idea that I have here, is to rework the pa
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have va
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have va
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have va
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have va
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have va
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have va
Avoid emitting a bogus WAL record when recycling an all-zero btree page.
Commit fafa374f2 caused _bt_getbuf() to possibly emit a WAL record for
a page that it was about to recycle. However, it failed to distinguish
all-zero pages from dead pages, which is important because only the
latter have va
Add pg_rewind --no-sync
This is an option consistent with what pg_dump and pg_basebackup provide
which is useful for leveraging the I/O effort when testing things, not
to be used in a production environment.
Author: Michael Paquier
Reviewed-by: Heikki Linnakangas
Discussion: https://postgr.es/m/2
Simplify logic to sync target directory at the end of pg_rewind
The previous sync logic relied on looking for and then launching
externally initdb -S, which is a simple wrapper on top of fsync_pgdata.
There is nothing preventing pg_rewind to directly call this routine, so
remove the dependency to
27 matches
Mail list logo
