pgsql: Remove a few unused global variables and declarations.
Remove a few unused global variables and declarations. - Commit 3eb77eba5a, which moved the pending ops queue from md.c to sync.c, introduced a duplicate, unused 'pendingOpsCxt' variable. (I'm surprised none of the compilers or static analysis tools have complained about that.) - Commit c2fe139c20 moved the 'synchronize_seqscans' variable and introduced an extern declaration in tableam.h, making the one in guc_tables.c unnecessary. - Commit 6f0cf87872 removed the 'pgstat_temp_directory' GUC, but forgot to remove the corresponding global variable. - Commit 1b4e729eaa removed the 'pg_krb_realm' GUC, and its global variable, but forgot the declaration in auth.h. Spotted all these by reading the code. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/548d7260309008b146bd9eaa66f3c5be0a8d725a Modified Files -- src/backend/storage/sync/sync.c | 2 -- src/backend/utils/misc/guc_tables.c | 3 --- src/include/libpq/auth.h| 1 - 3 files changed, 6 deletions(-)
pgsql: Fix "wrong varnullingrels" for subquery nestloop parameters.
Fix "wrong varnullingrels" for subquery nestloop parameters. If we apply outer join identity 3 when relation C is a subquery having lateral references to relation B, then the lateral references within C continue to bear the original syntactically-correct varnullingrels marks, but that won't match what is available from the outer side of the nestloop. Compensate for that in process_subquery_nestloop_params(). This is a slightly hacky fix, but we certainly don't want to re-plan C in toto for each possible outer join order, so there's not a lot of better alternatives. Richard Guo and Tom Lane, per report from Markus Winand Discussion: https://postgr.es/m/dfbb2d25-de97-49ca-a60e-07c881ea5...@winand.at Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bfd332b3fda5c73e28c05b7ba0aac6cf053cdf00 Modified Files -- src/backend/optimizer/plan/setrefs.c | 8 --- src/backend/optimizer/util/paramassign.c | 36 +--- src/test/regress/expected/join.out | 18 src/test/regress/sql/join.sql| 7 +++ 4 files changed, 59 insertions(+), 10 deletions(-)
pgsql: src/tools/msvc/clean.bat: Reconcile with PostgreSQL 16 work.
src/tools/msvc/clean.bat: Reconcile with PostgreSQL 16 work. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0c524370203b85b49ca3b52c7a705b867d7c7167 Modified Files -- src/tools/msvc/clean.bat | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-)
pgsql: src/tools/msvc: Move all.sym temporary file back to Debug/postgr
src/tools/msvc: Move all.sym temporary file back to Debug/postgres. Commit 70df2df1cc89e69e31b31b6aa0d65fd72935af38 moved it to the top_srcdir, where it caused "git status" noise. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6e723f6d7b3642ef9457b8eddd27ebb616d7a7e9 Modified Files -- src/tools/msvc/MSBuildProject.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Add win32ver data to meson-built postgres.exe.
Add win32ver data to meson-built postgres.exe. As in the older build systems, the resources object is not an input to postgres.def. Reviewed by Andres Freund. Discussion: https://postgr.es/m/20230607231407.gc1334...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8c7ad6f1562ba7e8a65b21c40782091a4dd3301d Modified Files -- src/backend/meson.build | 8 1 file changed, 8 insertions(+)
pgsql: Give postgres.exe the icon of other executables.
Give postgres.exe the icon of other executables. We had left it icon-free since users won't achieve much by opening it from Windows Explorer. Subsequent to that decision, Task Manager started to show the icon. That shifts the balance in favor of attaching the icon, so do so. No back-patch, but make this late addition to v16. Reviewed by Andres Freund and Magnus Hagander. Discussion: https://postgr.es/m/20230608014507.gd1334...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/04411cbfdb76194c483c77bdbc636e83099ae5c3 Modified Files -- src/backend/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Accept fractional seconds in jsonpath's datetime() method.
Accept fractional seconds in jsonpath's datetime() method. Commit 927d9abb6 purported to make datetime() accept any string that could be output for a datetime value by to_jsonb(). But it overlooked the possibility of fractional seconds being present, so that cases as simple as to_jsonb(now()) would defeat it. Fix by adding formats that include ".US" to the list in executeDateTimeMethod(). (Note that while this is nominally microseconds, it'll do the right thing for fractions with fewer than six digits.) In passing, re-order the list to restore the datatype ordering specified in its comment. The violation accidentally did not break anything; but the next edit might be less lucky, so add more comments. Per report from Tim Field. Back-patch to v13 where datetime() was added, like the previous patch. Discussion: https://postgr.es/m/014a028b-5ce6-4fdf-ac24-426ca6fc9...@mohiohio.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bd590d1fea1ba9245c791d589eea94d2dbad5a2b Modified Files -- src/backend/utils/adt/jsonpath_exec.c| 17 + src/test/regress/expected/jsonb_jsonpath.out | 15 +++ src/test/regress/sql/jsonb_jsonpath.sql | 3 +++ 3 files changed, 31 insertions(+), 4 deletions(-)
pgsql: Accept fractional seconds in jsonpath's datetime() method.
Accept fractional seconds in jsonpath's datetime() method. Commit 927d9abb6 purported to make datetime() accept any string that could be output for a datetime value by to_jsonb(). But it overlooked the possibility of fractional seconds being present, so that cases as simple as to_jsonb(now()) would defeat it. Fix by adding formats that include ".US" to the list in executeDateTimeMethod(). (Note that while this is nominally microseconds, it'll do the right thing for fractions with fewer than six digits.) In passing, re-order the list to restore the datatype ordering specified in its comment. The violation accidentally did not break anything; but the next edit might be less lucky, so add more comments. Per report from Tim Field. Back-patch to v13 where datetime() was added, like the previous patch. Discussion: https://postgr.es/m/014a028b-5ce6-4fdf-ac24-426ca6fc9...@mohiohio.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6f23b5f74f5fd86d7bbadc89359b8f2175665400 Modified Files -- src/backend/utils/adt/jsonpath_exec.c| 17 + src/test/regress/expected/jsonb_jsonpath.out | 15 +++ src/test/regress/sql/jsonb_jsonpath.sql | 3 +++ 3 files changed, 31 insertions(+), 4 deletions(-)
pgsql: Accept fractional seconds in jsonpath's datetime() method.
Accept fractional seconds in jsonpath's datetime() method. Commit 927d9abb6 purported to make datetime() accept any string that could be output for a datetime value by to_jsonb(). But it overlooked the possibility of fractional seconds being present, so that cases as simple as to_jsonb(now()) would defeat it. Fix by adding formats that include ".US" to the list in executeDateTimeMethod(). (Note that while this is nominally microseconds, it'll do the right thing for fractions with fewer than six digits.) In passing, re-order the list to restore the datatype ordering specified in its comment. The violation accidentally did not break anything; but the next edit might be less lucky, so add more comments. Per report from Tim Field. Back-patch to v13 where datetime() was added, like the previous patch. Discussion: https://postgr.es/m/014a028b-5ce6-4fdf-ac24-426ca6fc9...@mohiohio.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5eaa05f637179b6847f9efc98ca07a9aa1479e47 Modified Files -- src/backend/utils/adt/jsonpath_exec.c| 17 + src/test/regress/expected/jsonb_jsonpath.out | 15 +++ src/test/regress/sql/jsonb_jsonpath.sql | 3 +++ 3 files changed, 31 insertions(+), 4 deletions(-)
pgsql: Accept fractional seconds in jsonpath's datetime() method.
Accept fractional seconds in jsonpath's datetime() method. Commit 927d9abb6 purported to make datetime() accept any string that could be output for a datetime value by to_jsonb(). But it overlooked the possibility of fractional seconds being present, so that cases as simple as to_jsonb(now()) would defeat it. Fix by adding formats that include ".US" to the list in executeDateTimeMethod(). (Note that while this is nominally microseconds, it'll do the right thing for fractions with fewer than six digits.) In passing, re-order the list to restore the datatype ordering specified in its comment. The violation accidentally did not break anything; but the next edit might be less lucky, so add more comments. Per report from Tim Field. Back-patch to v13 where datetime() was added, like the previous patch. Discussion: https://postgr.es/m/014a028b-5ce6-4fdf-ac24-426ca6fc9...@mohiohio.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7398e27224f173306e5b62977672b29f5553ee76 Modified Files -- src/backend/utils/adt/jsonpath_exec.c| 17 + src/test/regress/expected/jsonb_jsonpath.out | 15 +++ src/test/regress/sql/jsonb_jsonpath.sql | 3 +++ 3 files changed, 31 insertions(+), 4 deletions(-)
Re: pgsql: Fix search_path to a safe value during maintenance operations.
On Sat, Jun 10, 2023 at 01:33:31AM -0400, Tom Lane wrote: > Jeff Davis writes: > > Attached a patch to mark those functions as PARALLEL UNSAFE, which > > fixes the problem. > > > Alternatively, I could just take out that line, as those SQL functions > > are not controlled by the MAINTAIN privilege. But for consistency I > > think it's a good idea to leave it in so that index functions are > > called with the right search path for amcheck. > > I concur with the upthread objection that it is way too late in > the release cycle to be introducing a breaking change like this. > I request that you revert it. The timing was not great, but this is fixing a purported defect in an older v16 feature. If the MAINTAIN privilege is actually fine, we're all set for v16. If MAINTAIN does have a material problem that $SUBJECT had fixed, we should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem a different way.
Re: pgsql: Fix search_path to a safe value during maintenance operations.
On Mon, Jun 12, 2023 at 1:05 PM Noah Misch wrote: > > I concur with the upthread objection that it is way too late in > > the release cycle to be introducing a breaking change like this. > > I request that you revert it. > > The timing was not great, but this is fixing a purported defect in an older > v16 feature. If the MAINTAIN privilege is actually fine, we're all set for > v16. If MAINTAIN does have a material problem that $SUBJECT had fixed, we > should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem a > different way. I wonder why this commit used pg_catalog, pg_temp rather than just the empty string, as AutoVacWorkerMain does. -- Robert Haas EDB: http://www.enterprisedb.com
Re: pgsql: Fix search_path to a safe value during maintenance operations.
On Mon, 2023-06-12 at 13:33 -0400, Robert Haas wrote: > I wonder why this commit used pg_catalog, pg_temp rather than just > the > empty string, as AutoVacWorkerMain does. I followed the rules here for "Writing SECURITY DEFINER Functions Safely": https://www.postgresql.org/docs/16/sql-createfunction.html which suggests adding pg_temp at the end (otherwise it is searched first by default). It's not exactly like a SECURITY DEFINER function, but running a maintenance command does switch to the table owner, so the risks are similar. I don't see a problem with the pg_temp schema in non-interactive processes, because we trust the non-interactive processes. Regards, Jeff Davis
Re: pgsql: Fix search_path to a safe value during maintenance operations.
On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote: > The timing was not great, but this is fixing a purported defect in an > older > v16 feature. If the MAINTAIN privilege is actually fine, we're all > set for > v16. If MAINTAIN does have a material problem that $SUBJECT had > fixed, we > should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem > a > different way. Someone with the MAINTAIN privilege on a table can use search_path tricks against the table owner, if the code is susceptible, because maintenance code runs with the privileges of the table owner. I was concerned enough to bring it up on the -security list, and then to -hackers followed by a commit (too late). But perhaps that was paranoia: the practical risk is probably quite low, because a user with the MAINTAIN privilege is likely to be highly trusted. I'd like to hear from others on the topic about the relative risks of shipping with/without the search_path changes. I don't think a full revert of the MAINTAIN privilege is the right thing -- the predefined role is very valuable and many other predefined roles are much more dangerous than pg_maintain is. Regards, Jeff Davis
Re: pgsql: Fix search_path to a safe value during maintenance operations.
On Mon, Jun 12, 2023 at 5:40 PM Jeff Davis wrote: > On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote: > > The timing was not great, but this is fixing a purported defect in an > > older > > v16 feature. If the MAINTAIN privilege is actually fine, we're all > > set for > > v16. If MAINTAIN does have a material problem that $SUBJECT had > > fixed, we > > should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem > > a > > different way. > > Someone with the MAINTAIN privilege on a table can use search_path > tricks against the table owner, if the code is susceptible, because > maintenance code runs with the privileges of the table owner. > > Only change the search_path if someone other than the table owner or superuser is running the command (which should only be possible via the new MAINTAIN privilege)? David J.
Re: pgsql: Fix search_path to a safe value during maintenance operations.
On Monday, June 12, 2023, David G. Johnston wrote: > On Mon, Jun 12, 2023 at 5:40 PM Jeff Davis wrote: > >> On Mon, 2023-06-12 at 13:05 -0400, Noah Misch wrote: >> > The timing was not great, but this is fixing a purported defect in an >> > older >> > v16 feature. If the MAINTAIN privilege is actually fine, we're all >> > set for >> > v16. If MAINTAIN does have a material problem that $SUBJECT had >> > fixed, we >> > should either revert MAINTAIN, un-revert $SUBJECT, or fix the problem >> > a >> > different way. >> >> Someone with the MAINTAIN privilege on a table can use search_path >> tricks against the table owner, if the code is susceptible, because >> maintenance code runs with the privileges of the table owner. >> >> > Only change the search_path if someone other than the table owner or > superuser is running the command (which should only be possible via the new > MAINTAIN privilege)? > On a related note, are we OK with someone using this privilege setting their own default_statistics_target? https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGET My prior attempt to open up analyze had brought this up as a reason to avoid having someone besides the table owner allowed to analyze the table. David J.
pgsql: Report stats when replaying XLOG_RUNNING_XACTS
Report stats when replaying XLOG_RUNNING_XACTS Previously stats in the startup process would only get reported during shutdown of the startup process. It has been that way for a long time, but became a lot more noticeable with the new pg_stat_io view, which separates out IO done by different backend types... While replaying after every XLOG_RUNNING_XACTS isn't the prettiest approach, it has the advantage of being quite easy. Given that we're well past feature freeze... It's not a problem that we don't report stats more frequently with wal_level=minimal, in that case stats can't be read before the stats process has shut down. Besides the above, this commit also changes pgstat_report_stat() to acquire the timestamp with GetCurrentTimestamp() instead of GetCurrentTransactionStopTimestamp(). Thanks to Melih Mutlu, Kyotaro Horiguchi for prototypes of other approaches to solving this issue. Reported-by: Fujii Masao Discussion: https://postgr.es/m/5315aedc-fbca-1556-c5de-dc2e00b23...@oss.nttdata.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e3cb1a586cef746326eeabf36d103ea1136607f9 Modified Files -- src/backend/storage/ipc/standby.c | 9 + src/backend/utils/activity/pgstat.c | 17 ++--- 2 files changed, 23 insertions(+), 3 deletions(-)
