pgsql: Support for OUT parameters in procedures
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 Discussion: https://www.postgresql.org/message-id/flat/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2453ea142233ae57af452019c3b9a443dad1cdd0 Modified Files -- doc/src/sgml/catalogs.sgml | 5 +- doc/src/sgml/plpgsql.sgml | 38 ++ doc/src/sgml/ref/alter_extension.sgml | 11 +-- doc/src/sgml/ref/alter_procedure.sgml | 5 +- doc/src/sgml/ref/comment.sgml | 11 +-- doc/src/sgml/ref/create_procedure.sgml | 6 +- doc/src/sgml/ref/drop_procedure.sgml | 5 +- doc/src/sgml/ref/security_label.sgml | 11 +-- doc/src/sgml/xfunc.sgml| 59 src/backend/catalog/pg_proc.c | 9 ++- src/backend/commands/functioncmds.c| 57 --- src/backend/executor/functions.c | 3 +- src/backend/parser/gram.y | 96 +- src/backend/utils/fmgr/funcapi.c | 4 +- src/include/catalog/pg_proc.h | 2 +- src/include/funcapi.h | 3 +- src/pl/plperl/expected/plperl_call.out | 18 + src/pl/plperl/sql/plperl_call.sql | 20 ++ src/pl/plpgsql/src/expected/plpgsql_call.out | 19 + src/pl/plpgsql/src/pl_comp.c | 1 + src/pl/plpgsql/src/sql/plpgsql_call.sql| 21 ++ src/pl/plpython/expected/plpython_call.out | 17 + src/pl/plpython/plpy_procedure.c | 4 +- src/pl/plpython/sql/plpython_call.sql | 19 + src/pl/tcl/expected/pltcl_call.out | 17 + src/pl/tcl/sql/pltcl_call.sql | 19 + src/test/regress/expected/create_procedure.out | 16 - src/test/regress/sql/create_procedure.sql | 13 +++- 28 files changed, 416 insertions(+), 93 deletions(-)
pgsql: Doc: fix parameter names in the docs of a couple of functions.
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, since there's at least a case to be made for changing pg_proc not the docs.) make_interval issue noted by Thomas Kellerer. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/019eb962fb869b55ac8db173c4424a5de6cfee61 Modified Files -- doc/src/sgml/func.sgml | 16 1 file changed, 8 insertions(+), 8 deletions(-)
pgsql: Doc: fix parameter names in the docs of a couple of functions.
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, since there's at least a case to be made for changing pg_proc not the docs.) make_interval issue noted by Thomas Kellerer. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9cc3d614a9eb6ce17c0f6f6bf77c5d431617267e Modified Files -- doc/src/sgml/func.sgml | 16 1 file changed, 8 insertions(+), 8 deletions(-)
pgsql: Fix two latent(?) bugs in equivclass.c.
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: these bitmapsets will be built in the caller's context, leading to dangling pointers if that is shorter-lived than root->planner_cxt. This would be a live bug if get_eclass_for_sort_expr() could be called with create_it = true during GEQO join planning. So far as I can find, the core code never does that, but it's hard to be sure that no extensions do, especially since the comments make it clear that that's supposed to be a supported case. Fix by not computing these values until we've switched into planner_cxt to build the new EquivalenceClass. generate_join_implied_equalities() uses inner_rel->relids to look up relevant eclasses, but it ought to be using nominal_inner_relids. This is presently harmless because a child RelOptInfo will always have exactly the same eclass_indexes as its topmost parent; but that might not be true forever, and anyway it makes the code confusing. The first of these is old (introduced by me in f3b3b8d5b), so back-patch to all supported branches. The second only dates to v13, but we might as well back-patch it to keep the code looking similar across branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e3bd026fbb91c64e99c2a66eceb2dba3cc3ec6f0 Modified Files -- src/backend/optimizer/path/equivclass.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: Fix two latent(?) bugs in equivclass.c.
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: these bitmapsets will be built in the caller's context, leading to dangling pointers if that is shorter-lived than root->planner_cxt. This would be a live bug if get_eclass_for_sort_expr() could be called with create_it = true during GEQO join planning. So far as I can find, the core code never does that, but it's hard to be sure that no extensions do, especially since the comments make it clear that that's supposed to be a supported case. Fix by not computing these values until we've switched into planner_cxt to build the new EquivalenceClass. generate_join_implied_equalities() uses inner_rel->relids to look up relevant eclasses, but it ought to be using nominal_inner_relids. This is presently harmless because a child RelOptInfo will always have exactly the same eclass_indexes as its topmost parent; but that might not be true forever, and anyway it makes the code confusing. The first of these is old (introduced by me in f3b3b8d5b), so back-patch to all supported branches. The second only dates to v13, but we might as well back-patch it to keep the code looking similar across branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1f94d76856bc7e473e300134e092eb231cba83fe Modified Files -- src/backend/optimizer/path/equivclass.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: Fix two latent(?) bugs in equivclass.c.
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: these bitmapsets will be built in the caller's context, leading to dangling pointers if that is shorter-lived than root->planner_cxt. This would be a live bug if get_eclass_for_sort_expr() could be called with create_it = true during GEQO join planning. So far as I can find, the core code never does that, but it's hard to be sure that no extensions do, especially since the comments make it clear that that's supposed to be a supported case. Fix by not computing these values until we've switched into planner_cxt to build the new EquivalenceClass. generate_join_implied_equalities() uses inner_rel->relids to look up relevant eclasses, but it ought to be using nominal_inner_relids. This is presently harmless because a child RelOptInfo will always have exactly the same eclass_indexes as its topmost parent; but that might not be true forever, and anyway it makes the code confusing. The first of these is old (introduced by me in f3b3b8d5b), so back-patch to all supported branches. The second only dates to v13, but we might as well back-patch it to keep the code looking similar across branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f6a23344f8c8ec155399375d048a890afaa575ab Modified Files -- src/backend/optimizer/path/equivclass.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: Fix two latent(?) bugs in equivclass.c.
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: these bitmapsets will be built in the caller's context, leading to dangling pointers if that is shorter-lived than root->planner_cxt. This would be a live bug if get_eclass_for_sort_expr() could be called with create_it = true during GEQO join planning. So far as I can find, the core code never does that, but it's hard to be sure that no extensions do, especially since the comments make it clear that that's supposed to be a supported case. Fix by not computing these values until we've switched into planner_cxt to build the new EquivalenceClass. generate_join_implied_equalities() uses inner_rel->relids to look up relevant eclasses, but it ought to be using nominal_inner_relids. This is presently harmless because a child RelOptInfo will always have exactly the same eclass_indexes as its topmost parent; but that might not be true forever, and anyway it makes the code confusing. The first of these is old (introduced by me in f3b3b8d5b), so back-patch to all supported branches. The second only dates to v13, but we might as well back-patch it to keep the code looking similar across branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/74dae41e5ac39c41c902119c2101c80d400c0718 Modified Files -- src/backend/optimizer/path/equivclass.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: Fix two latent(?) bugs in equivclass.c.
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: these bitmapsets will be built in the caller's context, leading to dangling pointers if that is shorter-lived than root->planner_cxt. This would be a live bug if get_eclass_for_sort_expr() could be called with create_it = true during GEQO join planning. So far as I can find, the core code never does that, but it's hard to be sure that no extensions do, especially since the comments make it clear that that's supposed to be a supported case. Fix by not computing these values until we've switched into planner_cxt to build the new EquivalenceClass. generate_join_implied_equalities() uses inner_rel->relids to look up relevant eclasses, but it ought to be using nominal_inner_relids. This is presently harmless because a child RelOptInfo will always have exactly the same eclass_indexes as its topmost parent; but that might not be true forever, and anyway it makes the code confusing. The first of these is old (introduced by me in f3b3b8d5b), so back-patch to all supported branches. The second only dates to v13, but we might as well back-patch it to keep the code looking similar across branches. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/53c6daff4364219256119fcd79b2d71b57c13e37 Modified Files -- src/backend/optimizer/path/equivclass.c | 16 1 file changed, 8 insertions(+), 8 deletions(-)
pgsql: Fix two latent(?) bugs in equivclass.c.
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: these bitmapsets will be built in the caller's context, leading to dangling pointers if that is shorter-lived than root->planner_cxt. This would be a live bug if get_eclass_for_sort_expr() could be called with create_it = true during GEQO join planning. So far as I can find, the core code never does that, but it's hard to be sure that no extensions do, especially since the comments make it clear that that's supposed to be a supported case. Fix by not computing these values until we've switched into planner_cxt to build the new EquivalenceClass. generate_join_implied_equalities() uses inner_rel->relids to look up relevant eclasses, but it ought to be using nominal_inner_relids. This is presently harmless because a child RelOptInfo will always have exactly the same eclass_indexes as its topmost parent; but that might not be true forever, and anyway it makes the code confusing. The first of these is old (introduced by me in f3b3b8d5b), so back-patch to all supported branches. The second only dates to v13, but we might as well back-patch it to keep the code looking similar across branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d1c23d726d50e10179235b6cee6b34543a879b19 Modified Files -- src/backend/optimizer/path/equivclass.c | 16 1 file changed, 8 insertions(+), 8 deletions(-)
pgsql: Fix two latent(?) bugs in equivclass.c.
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: these bitmapsets will be built in the caller's context, leading to dangling pointers if that is shorter-lived than root->planner_cxt. This would be a live bug if get_eclass_for_sort_expr() could be called with create_it = true during GEQO join planning. So far as I can find, the core code never does that, but it's hard to be sure that no extensions do, especially since the comments make it clear that that's supposed to be a supported case. Fix by not computing these values until we've switched into planner_cxt to build the new EquivalenceClass. generate_join_implied_equalities() uses inner_rel->relids to look up relevant eclasses, but it ought to be using nominal_inner_relids. This is presently harmless because a child RelOptInfo will always have exactly the same eclass_indexes as its topmost parent; but that might not be true forever, and anyway it makes the code confusing. The first of these is old (introduced by me in f3b3b8d5b), so back-patch to all supported branches. The second only dates to v13, but we might as well back-patch it to keep the code looking similar across branches. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d5109a163f46df0dbda6125cea27b4b2951a6401 Modified Files -- src/backend/optimizer/path/equivclass.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-)
pgsql: Include the process PID in assertion-failure messages.
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 Details --- https://git.postgresql.org/pg/commitdiff/18c170a08ee23d03a06d235ea628fecb057d974f Modified Files -- src/backend/utils/error/assert.c | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-)
pgsql: Overhaul pg_hba.conf clientcert's API
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, throw an error if 'verify-ca' is used and 'cert' authentication is used, since cert authentication requires verify-full. Also improve the docs. THIS IS A BACKWARD INCOMPATIBLE API CHANGE. Reported-by: Kyotaro Horiguchi Discussion: https://postgr.es/m/[email protected] Author: Kyotaro Horiguchi Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/253f1025da8c8d6e52f96f764658b76eb59290ad Modified Files -- doc/src/sgml/client-auth.sgml | 11 --- doc/src/sgml/runtime.sgml | 5 ++--- src/backend/libpq/hba.c | 18 +++--- 3 files changed, 13 insertions(+), 21 deletions(-)
pgsql: docs: clarify the interaction of clientcert and cert auth.
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 Modified Files -- doc/src/sgml/client-auth.sgml | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-)
pgsql: docs: clarify the interaction of clientcert and cert auth.
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 Modified Files -- doc/src/sgml/client-auth.sgml | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-)
pgsql: doc: show functions returning record types and use of ROWS FROM
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: [email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e9703ce6e7ac263e0e5a6fca9266e09284195dc7 Modified Files -- doc/src/sgml/queries.sgml | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-)
pgsql: doc: show functions returning record types and use of ROWS FROM
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: [email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/54ec775e39cda4bf4047a03699e191e5a9f1fd27 Modified Files -- doc/src/sgml/queries.sgml | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-)
pgsql: doc: show functions returning record types and use of ROWS FROM
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: [email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9e2c53d4c8dfa9cd9f72282509ff1c7c466273b0 Modified Files -- doc/src/sgml/queries.sgml | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-)
pgsql: doc: show functions returning record types and use of ROWS FROM
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: [email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/997188b6e0a11c60ddab369969ea2e57202941b8 Modified Files -- doc/src/sgml/queries.sgml | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-)
pgsql: doc: show functions returning record types and use of ROWS FROM
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: [email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dd0a64ed435d4a266ed16adb8204e7222af6c164 Modified Files -- doc/src/sgml/queries.sgml | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-)
pgsql: doc: show functions returning record types and use of ROWS FROM
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: [email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d7e3aa470eb4094d132ebdab95fc9467b5478de5 Modified Files -- doc/src/sgml/queries.sgml | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-)
pgsql: doc: show functions returning record types and use of ROWS FROM
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: [email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 9.5 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b8e6857b8170f09861baa1bfd074fa0c8af9cfd Modified Files -- doc/src/sgml/queries.sgml | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-)
pgsql: postgres_fdw: reestablish new connection if cached one is detect
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 restart of remote server. In these cases, previously an error was reported and the query accessing to remote server failed if new remote transaction failed to start because the cached connection was broken. This commit improves postgres_fdw so that new connection is remade if broken connection is detected when starting new remote transaction. This is useful to avoid unnecessary failure of queries when connection is broken but can be reestablished. Author: Bharath Rupireddy, tweaked a bit by Fujii Masao Reviewed-by: Ashutosh Bapat, Tatsuhito Kasahara, Fujii Masao Discussion: https://postgr.es/m/CALj2ACUAi23vf1WiHNar_LksM9EDOWXcbHCo-fD4Mbr1d=7...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/32a9c0bdf493cf5fc029ab44a22384d547290eff Modified Files -- contrib/postgres_fdw/connection.c | 54 -- contrib/postgres_fdw/expected/postgres_fdw.out | 48 +++ contrib/postgres_fdw/sql/postgres_fdw.sql | 41 +++ 3 files changed, 131 insertions(+), 12 deletions(-)
pgsql: Try to unbreak 021_row_visibility.pl on mingw.
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 unbreak the BF. Proposed-By: Andrew Dunstan Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1df2b50dbebb72a75708c3cfbc21bcaa71993147 Modified Files -- src/test/recovery/t/021_row_visibility.pl | 4 1 file changed, 4 insertions(+)
Re: pgsql: Add block information in error context of WAL REDO apply loop
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 output generated by pg_waldump to get some > information about the blocks a WAL record works on. > > The block information is printed in the same format as pg_waldump. This > already existed in xlog.c for debugging purposes with -DWAL_DEBUG, so > adding the block information in the callback has required just a small > refactoring. > > Author: Bertrand Drouvot > Reviewed-by: Michael Paquier, Masahiko Sawada > Discussion: > https://postgr.es/m/[email protected] My compiler quite justifiably complains about: +#endif /* WAL_DEBUG */ + +/* + * Returns a string giving information about all the blocks in an + * XLogRecord. + */ +static void +xlog_block_info(StringInfo buf, XLogReaderState *record) +{ +int block_id; + /* decode block references */ for (block_id = 0; block_id <= record->max_block_id; block_id++) { @@ -10284,7 +10298,6 @@ xlog_outrec(StringInfo buf, XLogReaderState *record) appendStringInfoString(buf, " FPW"); } } -#endif /* WAL_DEBUG */ because as far as I can see there's no remaining use of block_id in xlog_outrec() after this change. Greetings, Andres Freund
pgsql: Fix compilation warning in xlog.c
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 Files -- src/backend/access/transam/xlog.c | 2 -- 1 file changed, 2 deletions(-)
Re: pgsql: Add block information in error context of WAL REDO apply loop
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
