On Mon, Oct 05, 2020 at 07:38:02PM -0700, Andres Freund wrote:
> My compiler quite justifiably complains about:
Thanks, fixed.
--
Michael
signature.asc
Description: PGP signature
Fix compilation warning in xlog.c
Oversight in 9d0bd95.
Reported-by: Andres Freund
Discussion:
https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0a3c864c32751fd29d021929cf70af421fd27370
Modified
Hi,
On 2020-10-02 00:41:12 +, Michael Paquier wrote:
> Add block information in error context of WAL REDO apply loop
>
> Providing this information can be useful for example when diagnosing
> problems related to recovery conflicts or for recovery issues without
> having to go through the outp
Try to unbreak 021_row_visibility.pl on mingw.
Thanks to Andrew for proposing and testing this fix.
It's possible that we should address this on a more fundamental basis,
e.g. by configuring PerlIO to to CR/LF conversion for us, but this
approach already exists in other places. And it's nice to u
postgres_fdw: reestablish new connection if cached one is detected as broken.
In postgres_fdw, once remote connections are established, they are cached
and re-used for subsequent queries and transactions. There can be some
cases where those cached connections are unavaiable, for example,
by the re
doc: show functions returning record types and use of ROWS FROM
Previously it was unclear exactly how ROWS FROM behaved and how to cast
the data types of columns returned by FROM functions. Also document
that only non-OUT record functions can have their columns cast to data
types.
Reported-by:
doc: show functions returning record types and use of ROWS FROM
Previously it was unclear exactly how ROWS FROM behaved and how to cast
the data types of columns returned by FROM functions. Also document
that only non-OUT record functions can have their columns cast to data
types.
Reported-by:
doc: show functions returning record types and use of ROWS FROM
Previously it was unclear exactly how ROWS FROM behaved and how to cast
the data types of columns returned by FROM functions. Also document
that only non-OUT record functions can have their columns cast to data
types.
Reported-by:
doc: show functions returning record types and use of ROWS FROM
Previously it was unclear exactly how ROWS FROM behaved and how to cast
the data types of columns returned by FROM functions. Also document
that only non-OUT record functions can have their columns cast to data
types.
Reported-by:
doc: show functions returning record types and use of ROWS FROM
Previously it was unclear exactly how ROWS FROM behaved and how to cast
the data types of columns returned by FROM functions. Also document
that only non-OUT record functions can have their columns cast to data
types.
Reported-by:
doc: show functions returning record types and use of ROWS FROM
Previously it was unclear exactly how ROWS FROM behaved and how to cast
the data types of columns returned by FROM functions. Also document
that only non-OUT record functions can have their columns cast to data
types.
Reported-by:
doc: show functions returning record types and use of ROWS FROM
Previously it was unclear exactly how ROWS FROM behaved and how to cast
the data types of columns returned by FROM functions. Also document
that only non-OUT record functions can have their columns cast to data
types.
Reported-by:
docs: clarify the interaction of clientcert and cert auth.
This is the first paragraph change of master-only commit 253f1025da.
Backpatch-through: PG 12-13 only
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/ef40ab77d5143385d15dcfd08c5a7d66719ef7a3
Modifi
docs: clarify the interaction of clientcert and cert auth.
This is the first paragraph change of master-only commit 253f1025da.
Backpatch-through: PG 12-13 only
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/f05ca47132ddf58de463fd8396a44d7ccd06e123
Modifi
Overhaul pg_hba.conf clientcert's API
Since PG 12, clientcert no longer supported only on/off, so remove 1/0
as possible values, and instead support only the text strings
'verify-ca' and 'verify-full'.
Remove support for 'no-verify' since that is possible by just not
specifying clientcert.
Also,
Include the process PID in assertion-failure messages.
This should help to identify what happened when studying the postmaster
log after-the-fact.
While here, clean up some old comments in the same function.
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Fix two latent(?) bugs in equivclass.c.
get_eclass_for_sort_expr() computes expr_relids and nullable_relids
early on, even though they won't be needed unless we make a new
EquivalenceClass, which we often don't. Aside from the probably-minor
inefficiency, there's a memory management problem: thes
Fix two latent(?) bugs in equivclass.c.
get_eclass_for_sort_expr() computes expr_relids and nullable_relids
early on, even though they won't be needed unless we make a new
EquivalenceClass, which we often don't. Aside from the probably-minor
inefficiency, there's a memory management problem: thes
Fix two latent(?) bugs in equivclass.c.
get_eclass_for_sort_expr() computes expr_relids and nullable_relids
early on, even though they won't be needed unless we make a new
EquivalenceClass, which we often don't. Aside from the probably-minor
inefficiency, there's a memory management problem: thes
Fix two latent(?) bugs in equivclass.c.
get_eclass_for_sort_expr() computes expr_relids and nullable_relids
early on, even though they won't be needed unless we make a new
EquivalenceClass, which we often don't. Aside from the probably-minor
inefficiency, there's a memory management problem: thes
Fix two latent(?) bugs in equivclass.c.
get_eclass_for_sort_expr() computes expr_relids and nullable_relids
early on, even though they won't be needed unless we make a new
EquivalenceClass, which we often don't. Aside from the probably-minor
inefficiency, there's a memory management problem: thes
Fix two latent(?) bugs in equivclass.c.
get_eclass_for_sort_expr() computes expr_relids and nullable_relids
early on, even though they won't be needed unless we make a new
EquivalenceClass, which we often don't. Aside from the probably-minor
inefficiency, there's a memory management problem: thes
Fix two latent(?) bugs in equivclass.c.
get_eclass_for_sort_expr() computes expr_relids and nullable_relids
early on, even though they won't be needed unless we make a new
EquivalenceClass, which we often don't. Aside from the probably-minor
inefficiency, there's a memory management problem: thes
Doc: fix parameter names in the docs of a couple of functions.
The descriptions of make_interval() and pg_options_to_table()
were randomly different from the reality embedded in pg_proc.
(These are not all the discrepancies I found in a quick search,
but the others perhaps require more discussion
Doc: fix parameter names in the docs of a couple of functions.
The descriptions of make_interval() and pg_options_to_table()
were randomly different from the reality embedded in pg_proc.
(These are not all the discrepancies I found in a quick search,
but the others perhaps require more discussion
Support for OUT parameters in procedures
Unlike for functions, OUT parameters for procedures are part of the
signature. Therefore, they have to be listed in pg_proc.proargtypes
as well as mentioned in ALTER PROCEDURE and DROP PROCEDURE.
Reviewed-by: Andrew Dunstan
Reviewed-by: Pavel Stehule
Di
26 matches
Mail list logo
