Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 30 Jun, 2019 3 commits
  3. 29 Jun, 2019 4 commits
    • Tom Lane's avatar
      Add an enforcement mechanism for global object names in regression tests. · 54100f5c
      Tom Lane authored 
      In commit 18555b13 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have
on an existing installation.

This commit adds a simple enforcement mechanism for that rule: if the code
is compiled with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS defined, it
will emit a warning (not an error) whenever a database, role, tablespace,
subscription, or replication origin name is created that doesn't obey the
rule.  Running one or more buildfarm members with that symbol defined
should be enough to catch new violations, at least in the regular
regression tests.  Most TAP tests wouldn't notice such warnings, but
that's actually fine because TAP tests don't execute against an existing
server anyway.

Since it's already the case that running src/test/modules/ tests in
installcheck mode is deprecated, we can use that as a home for tests
that seem unsafe to run against an existing server, such as tests that
might have side-effects on existing roles.  Document that (though this
commit doesn't in itself make it any less safe than before).

Update regress.sgml to define these restrictions more clearly, and
to clean up assorted lack-of-up-to-date-ness in its descriptions of
the available regression tests.

Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
      54100f5c
    • Tom Lane's avatar
      Fix regression tests to use only global names beginning with "regress_". · ca129e58
      Tom Lane authored 
      In commit 18555b13 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation.  However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.

In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types.  So it's past time to do something about this.

This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit.  There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure.  Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.

The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-().  What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.

Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
      ca129e58
    • Tom Lane's avatar
      Disallow user-created replication origins named "pg_xxx". · a1e61bad
      Tom Lane authored 
      Since we generate such names internally, it seems like a good idea
to have a policy of disallowing them for user use, as we do for many
other object types.  Otherwise attempts to use them will randomly
fail due to collisions with internally-generated names.

Discussion: https://postgr.es/m/3606.1561747369@sss.pgh.pa.us
      a1e61bad
    • Michael Paquier's avatar
      Remove unnecessary header from be-secure-gssapi.c · c0faa727
      Michael Paquier authored 
      libpq/libpq-be.h is included by libpq/libpq.h so there is no need to
explicitly include it separately.

Author: Daniel Gustafsson
Reviewed-by: Julien Rouhaud
Discussion: https://postgr.es/m/A4852E46-9ED1-4861-A23B-22A83E34A084@yesql.se
      c0faa727
  5. 28 Jun, 2019 2 commits
  7. 27 Jun, 2019 3 commits
  9. 26 Jun, 2019 5 commits
  11. 25 Jun, 2019 1 commit
  13. 24 Jun, 2019 10 commits
  15. 23 Jun, 2019 4 commits
    • Noah Misch's avatar
      Don't call PG_RETURN_BOOL() in a function not returning Datum. · 9a81c9fa
      Noah Misch authored 
      This code is new in v12, and the defect probably was not user-visible.
      9a81c9fa
    • Dean Rasheed's avatar
      Add security checks to the multivariate MCV estimation code. · d7f8d26d
      Dean Rasheed authored 
      The multivariate MCV estimation code may run user-defined operators on
the values in the MCV list, which means that those operators may
potentially leak the values from the MCV list. Guard against leaking
data to unprivileged users by checking that the user has SELECT
privileges on the table or all of the columns referred to by the
statistics.

Additionally, if there are any securityQuals on the RTE (either due to
RLS policies on the table, or accessing the table via a security
barrier view), not all rows may be visible to the current user, even
if they have table or column privileges. Thus we further insist that
the operator be leakproof in this case.

Dean Rasheed, reviewed by Tomas Vondra.

Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui=Vdx4N==VV5XOK5dsXfnGgVOz_JhAicB=ZA@mail.gmail.com
      d7f8d26d
    • Thomas Munro's avatar
      Remove unnecessary comment. · 89ff7c08
      Thomas Munro authored 
      Author: Vik Fearing
Discussion: https://postgr.es/m/150d3e9f-c7ec-3fb3-4fdb-def47c4144af%402ndquadrant.com
      89ff7c08
    • Tom Lane's avatar
      Fix spinlock assembly code for MIPS so it works on MIPS r6. · 1323bfce
      Tom Lane authored 
      Original MIPS-I processors didn't have the LL/SC instructions (nor any
other userland synchronization primitive).  If the build toolchain
targets that ISA variant by default, as an astonishingly large fraction
of MIPS platforms still do, the assembler won't take LL/SC without
coercion in the form of a ".set mips2" instruction.  But we issued that
unconditionally, making it an ISA downgrade for chips later than MIPS2.
That breaks things for the latest MIPS r6 ISA, which encodes these
instructions differently.  Adjust the code so we don't change ISA level
if it's >= 2.

Note that this patch doesn't change what happens on an actual MIPS-I
processor: either the kernel will emulate these instructions
transparently, or you'll get a SIGILL failure.  That tradeoff seemed
fine in 2002 when this code was added (cf 3cbe6b24), and it's even
more so today when MIPS-I is basically extinct.  But let's add a
comment about that.

YunQiang Su (with cosmetic adjustments by me).  Back-patch to all
supported branches.

Discussion: https://postgr.es/m/15844-8f62fe7e163939b3@postgresql.org
      1323bfce
  17. 22 Jun, 2019 1 commit
  19. 20 Jun, 2019 3 commits
  21. 19 Jun, 2019 4 commits