1. 17 Aug, 2023 1 commit
  2. 29 Nov, 2022 1 commit
  3. 28 Nov, 2022 2 commits
  4. 07 Nov, 2022 1 commit
  5. 06 Nov, 2022 1 commit
  6. 04 Nov, 2022 1 commit
  7. 03 Nov, 2022 3 commits
    • Alvaro Herrera's avatar
      Create FKs properly when attaching table as partition · 18865f4d
      Alvaro Herrera authored
      Commit f56f8f8d added some code in CloneFkReferencing that's way too
      lax about a Constraint node it manufactures, not initializing enough
      struct members -- initially_valid in particular was forgotten.  This
      causes some FKs in partitions added by ALTER TABLE ATTACH PARTITION to
      be marked as not validated.  Set initially_valid true, which fixes the
      While at it, make the struct initialization more complete.  Very similar
      code was added in two other places by the same commit; make them all
      follow the same pattern for consistency, though no bugs are apparent
      This bug has never been reported: I only happened to notice while
      working on commit 614a406b4ff1.  The test case that was added there with
      the improper result is repaired.
      Backpatch to 12.
      Discussion: https://postgr.es/m/20221005105523.bhuhkdx4olajboof@alvherre.pgsql
    • Tom Lane's avatar
      Avoid crash after function syntax error in a replication worker. · 2489c38c
      Tom Lane authored
      If a syntax error occurred in a SQL-language or PL/pgSQL-language
      CREATE FUNCTION or DO command executed in a logical replication worker,
      we'd suffer a null pointer dereference or assertion failure.  That
      seems like a rather contrived case, but nonetheless worth fixing.
      The cause is that function_parse_error_transpose assumes it must be
      executing within the context of a Portal, but logical/worker.c
      doesn't create a Portal since it's not running the standard executor.
      We can just back off the hard Assert check and make it fail gracefully
      if there's not an ActivePortal.  (I have a feeling that the aggressive
      check here was my fault originally, probably because I wasn't sure if
      the case would always hold and wanted to find out.  Well, now we know.)
      The hazard seems to exist in all branches that have logical replication,
      so back-patch to v10.
      Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane
      Discussion: https://postgr.es/m/b570c367-ba38-95f3-f62d-5f59b9808226@inbox.ru
      Discussion: https://postgr.es/m/adf0452f-8c6b-7def-d35e-ab516c80088e@inbox.ru
    • Tom Lane's avatar
      Add casts to simplehash.h to silence C++ warnings. · eeb5461e
      Tom Lane authored
      Casting the result of palloc etc. to the intended type is more per
      project style anyway.
      (The fact that cpluspluscheck doesn't notice these problems is
      because it doesn't expand any macros, which seems like a troubling
      shortcoming.  Don't have a good idea about improving that.)
      Back-patch to v13, which is as far as the patch applies cleanly;
      doesn't seem worth working harder.
      David Geier
      Discussion: https://postgr.es/m/aa5d88a3-71f4-3455-11cf-82de0372c941@gmail.com
  8. 02 Nov, 2022 3 commits
    • Tom Lane's avatar
      Allow use of __sync_lock_test_and_set for spinlocks on any machine. · 058c7b5d
      Tom Lane authored
      If we have no special-case code in s_lock.h for the current platform,
      but the compiler has __sync_lock_test_and_set, use that instead of
      failing.  It's unlikely that anybody's __sync_lock_test_and_set
      would be so awful as to be worse than our semaphore-based fallback,
      but if it is, they can (continue to) use --disable-spinlocks.
      This allows removal of the RISC-V special case installed by commit
      c32fcac56, which generated exactly the same code but only on that
      platform.  Usefully, the RISC-V buildfarm animals should now test
      at least the int variant of this patch.
      I've manually tested both variants on ARM by dint of removing the
      ARM-specific stanza.  We don't want to drop that, because it already
      has some special knowledge and is likely to grow more over time.
      Likewise, this is not meant to preclude installing special cases
      for other arches if that proves worthwhile.
      Per discussion of a request to install the same code for loongarch64.
      Like the previous patch, we might as well back-patch to supported
      Discussion: https://postgr.es/m/761ac43d44b84d679ba803c2bd947cc0@HSMAILSVR04.hs.handsome.com.cn
    • Tom Lane's avatar
      Defend against unsupported partition relkind in logical replication worker. · a5b7821f
      Tom Lane authored
      Since partitions can be foreign tables not only plain tables, but
      logical replication only supports plain tables, we'd better check the
      relkind of a partition after we find it.  (There was some discussion
      of checking this when adding a partitioned table to a subscription;
      but that would be inadequate since the troublesome partition could be
      added later.)  Without this, the situation leads to a segfault or
      assertion failure.
      In passing, add a separate variable for the target Relation of
      a cross-partition UPDATE; reusing partrel seemed mighty confusing
      and error-prone.
      Shi Yu and Tom Lane, per report from Ilya Gladyshev.  Back-patch
      to v13 where logical replication into partitioned tables became
      a thing.
      Discussion: https://postgr.es/m/6b93e3748ba43298694f376ca8797279d7945e29.camel@gmail.com
    • Etsuro Fujita's avatar
      Fix copy-and-pasteo in comment. · 2896aa98
      Etsuro Fujita authored
  9. 01 Nov, 2022 2 commits
    • Tom Lane's avatar
      Update time zone data files to tzdata release 2022f. · 97bb80b1
      Tom Lane authored
      DST law changes in Chile, Fiji, Iran, Jordan, Mexico, Palestine,
      and Syria.  Historical corrections for Chile, Crimea, Iran, and
      Also, the Europe/Kiev zone has been renamed to Europe/Kyiv
      (retaining the old name as a link).
      The following zones have been merged into nearby, more-populous zones
      whose clocks have agreed since 1970: Antarctica/Vostok, Asia/Brunei,
      Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam,
      Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo,
      Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen,
      Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti,
      Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis.
      (This indirectly affects zones that were already links to one of
      these: Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland,
      Pacific/Ponape, Pacific/Truk, and Pacific/Yap.)  America/Nipigon,
      America/Rainy_River, America/Thunder_Bay, Europe/Uzhgorod, and
      Europe/Zaporozhye were also merged into nearby zones after discovering
      that their claimed post-1970 differences from those zones seem to have
      been errors.
      While the IANA crew have been working on merging zones that have no
      post-1970 differences for some time, this batch of changes affects
      some zones that are significantly more populous than those merged
      in the past, notably parts of Europe.  The loss of pre-1970 timezone
      history for those zones may be troublesome for applications
      expecting consistency of timestamptz display.  As an example, the
      stored value '1944-06-01 12:00 UTC' would previously display as
      '1944-06-01 13:00:00+01' if the Europe/Stockholm zone is selected,
      but now it will read out as '1944-06-01 14:00:00+02'.
      There exists a "packrat" option that will build the timezone data
      files with this old data preserved, but the problem is that it also
      resurrects a bunch of other, far less well-attested data; so much so
      that actually more zones' contents change from 2022a with that option
      than without it.  I have chosen not to do that here, for that reason
      and because it appears that no major OS distributions are using the
      "packrat" option, so that doing so would cause Postgres' behavior
      to diverge significantly depending on whether it was built with
      --with-system-tzdata.  However, for anyone for whom these changes pose
      significant problems, there is a solution: build a set of timezone
      files with the "packrat" option and use those with Postgres.
    • Tom Lane's avatar
      pg_stat_statements: fetch stmt location/length before it disappears. · 0f2f5645
      Tom Lane authored
      When executing a utility statement, we must fetch everything
      we need out of the PlannedStmt data structure before calling
      standard_ProcessUtility.  In certain cases (possibly only ROLLBACK
      in extended query protocol), that data structure will get freed
      during command execution.  The situation is probably often harmless
      in production builds, but in debug builds we intentionally overwrite
      the freed memory with garbage, leading to picking up garbage values
      of statement location and length, typically causing an assertion
      failure later in pg_stat_statements.  In non-debug builds, if
      something did go wrong it would likely lead to storing garbage
      for the query string.
      Report and fix by zhaoqigui (with cosmetic adjustments by me).
      It's an old problem, so back-patch to all supported versions.
      Discussion: https://postgr.es/m/17663-a344fd0675f92128@postgresql.org
      Discussion: https://postgr.es/m/1667307420050.56657@hundsun.com
  10. 26 Oct, 2022 1 commit
    • Michael Paquier's avatar
      Fix ordering issue with WAL operations in GIN fast insert path · 5a30d43f
      Michael Paquier authored
      Contrary to what is documented in src/backend/access/transam/README,
      ginHeapTupleFastInsert() had a few ordering issues with the way it does
      its WAL operations when inserting items in its fast path.
      First, when using a separate list, XLogBeginInsert() was being always
      called before START_CRIT_SECTION(), and in this case a second thing was
      wrong when merging lists, as an exclusive lock was taken on the tail
      page *before* calling XLogBeginInsert().  Finally, when inserting items
      into a tail page, the order of XLogBeginInsert() and
      START_CRIT_SECTION() was reversed.  This commit addresses all these
      issues by moving the calls of XLogBeginInsert() after all the pages
      logged are locked and pinned, within a critical section.
      This has been applied first only on HEAD as of 56b6625, but as per
      discussion with Tom Lane and Álvaro Herrera, a backpatch is preferred to
      keep all the branches consistent and to respect the transam's README
      where we can.
      Author:  Matthias van de Meent, Zhang Mingli
      Discussion: https://postgr.es/m/CAEze2WhL8uLMqynnnCu1LAPwxD5RKEo0nHV+eXGg_N6ELU88HQ@mail.gmail.com
      Backpatch-through: 10
  11. 21 Oct, 2022 3 commits
  12. 20 Oct, 2022 2 commits
  13. 19 Oct, 2022 1 commit
  14. 17 Oct, 2022 4 commits
  15. 16 Oct, 2022 3 commits
    • Tom Lane's avatar
      Fix EXPLAIN of SEARCH BREADTH FIRST with a constant initial value. · 8122160f
      Tom Lane authored
      If the non-recursive term of a SEARCH BREADTH FIRST recursive
      query has only constants in its target list, the planner will
      fold the starting RowExpr added by rewrite into a simple Const
      of type RECORD.  The executor doesn't have any problem with
      that --- but EXPLAIN VERBOSE will encounter the Const as the
      ultimate source of truth about what the field names of the
      SET column are, and it didn't know what to do with that.
      Fortunately, we can pull the identifying typmod out of the
      Const, in much the same way that record_out would.
      For reasons that remain a bit obscure to me, this only fails
      But I added regression test cases for both of those options
      too, just to make sure we don't break it in future.
      Per bug #17644 from Matthijs van der Vleuten.  Back-patch
      to v14 where these constructs were added.
      Discussion: https://postgr.es/m/17644-3bd1f3036d6d7a16@postgresql.org
    • Tom Lane's avatar
      Rename parser token REF to REF_P to avoid a symbol conflict. · 18e60712
      Tom Lane authored
      In the latest version of Apple's macOS SDK, <sys/socket.h>
      fails to compile if "REF" is #define'd as something.
      Apple may or may not agree that this is a bug, and even if
      they do accept the bug report I filed, they probably won't
      fix it very quickly.  In the meantime, our back branches will all
      fail to compile gram.y.  v15 and HEAD currently escape the problem
      thanks to the refactoring done in 98e93a1fc, but that's purely
      accidental.  Moreover, since that patch removed a widely-visible
      inclusion of <netdb.h>, back-patching it seems too likely to break
      third-party code.
      Instead, change the token's code name to REF_P, following our usual
      convention for naming parser tokens that are likely to have symbol
      conflicts.  The effects of that should be localized to the grammar
      and immediately surrounding files, so it seems like a safer answer.
      Per project policy that we want to keep recently-out-of-support
      branches buildable on modern systems, back-patch all the way to 9.2.
      Discussion: https://postgr.es/m/1803927.1665938411@sss.pgh.pa.us
    • Tom Lane's avatar
      Use libc's snprintf, not sprintf, for special cases in snprintf.c. · 6fa431d8
      Tom Lane authored
      snprintf.c has always fallen back on libc's *printf implementation
      when printing pointers (%p) and floats.  When this code originated,
      we were still supporting some platforms that lacked native snprintf,
      so we used sprintf for that.  That's not actually unsafe in our usage,
      but nonetheless builds on macOS are starting to complain about sprintf
      being unconditionally deprecated; and I wouldn't be surprised if other
      platforms follow suit.  There seems little reason to believe that any
      platform supporting C99 wouldn't have standards-compliant snprintf,
      so let's just use that instead to suppress such warnings.
      Back-patch to v12, which is where we started to require C99.  It's
      also where we started to use our snprintf.c everywhere, so this
      wouldn't be enough to suppress the warning in older branches anyway
      --- that is, in older branches these aren't necessarily all our
      usages of libc's sprintf.  It is enough in v12+ because any
      deprecation annotation attached to libc's sprintf won't apply to
      pg_sprintf.  (Whether all our usages of pg_sprintf are adequately
      safe is not a matter I intend to address here, but perhaps it could
      do with some review.)
      Per report from Andres Freund and local testing.
      Discussion: https://postgr.es/m/20221015211955.q4cwbsfkyk3c4ty3@awork3.anarazel.de
  16. 14 Oct, 2022 1 commit
  17. 13 Oct, 2022 1 commit
  18. 12 Oct, 2022 1 commit
  19. 11 Oct, 2022 3 commits
    • Tom Lane's avatar
      Harden pmsignal.c against clobbered shared memory. · b10546ec
      Tom Lane authored
      The postmaster is not supposed to do anything that depends
      fundamentally on shared memory contents, because that creates
      the risk that a backend crash that trashes shared memory will
      take the postmaster down with it, preventing automatic recovery.
      In commit 969d7cd4 I lost sight of this principle and coded
      AssignPostmasterChildSlot() in such a way that it could fail
      or even crash if the shared PMSignalState structure became
      corrupted.  Remarkably, we've not seen field reports of such
      crashes; but I managed to induce one while testing the recent
      changes around palloc chunk headers.
      To fix, make a semi-duplicative state array inside the postmaster
      so that we need consult only local state while choosing a "child
      slot" for a new backend.  Ensure that other postmaster-executed
      routines in pmsignal.c don't have critical dependencies on the
      shared state, either.  Corruption of PMSignalState might now
      lead ReleasePostmasterChildSlot() to conclude that backend X
      failed, when actually backend Y was the one that trashed things.
      But that doesn't matter, because we'll force a cluster-wide reset
      Back-patch to all supported branches, since this is an old bug.
      Discussion: https://postgr.es/m/3436789.1665187055@sss.pgh.pa.us
    • Tom Lane's avatar
      Yet further fixes for multi-row VALUES lists for updatable views. · 3162bd95
      Tom Lane authored
      DEFAULT markers appearing in an INSERT on an updatable view
      could be mis-processed if they were in a multi-row VALUES clause.
      This would lead to strange errors such as "cache lookup failed
      for type NNNN", or in older branches even to crashes.
      The cause is that commit 41531e42 tried to re-use rewriteValuesRTE()
      to remove any SetToDefault nodes (that hadn't previously been replaced
      by the view's own default values) appearing in "product" queries,
      that is DO ALSO queries.  That's fundamentally wrong because the
      DO ALSO queries might not even be INSERTs; and even if they are,
      their targetlists don't necessarily match the view's column list,
      so that almost all the logic in rewriteValuesRTE() is inapplicable.
      What we want is a narrow focus on replacing any such nodes with NULL
      constants.  (That is, in this context we are interpreting the defaults
      as being strictly those of the view itself; and we already replaced
      any that aren't NULL.)  We could add still more !force_nulls tests
      to further lobotomize rewriteValuesRTE(); but it seems cleaner to
      split out this case to a new function, restoring rewriteValuesRTE()
      to the charter it had before.
      Per bug #17633 from jiye_sw.  Patch by me, but thanks to
      Richard Guo and Japin Li for initial investigation.
      Back-patch to all supported branches, as the previous fix was.
      Discussion: https://postgr.es/m/17633-98cc85e1fa91e905@postgresql.org
    • Alvaro Herrera's avatar
      Ensure all perl test modules are installed · 4f6d1cfd
      Alvaro Herrera authored
      PostgreSQL::Test::Cluster and ::Utils were not being installed.  This is
      very hard to notice, as it only seems to affect external modules that
      want to run tests from 15 back in earlier versions.  Oversight in
      This applies only to branches 14 and back, because 15 had already been
      made correct in commit b3b4d8e68ae8.
      Discussion: https://postgr.es/m/20221010093415.poplkyn7pjeiv2y7@alvherre.pgsql
  20. 07 Oct, 2022 1 commit
    • Alvaro Herrera's avatar
      Fix self-referencing foreign keys with partitioned tables · 483d2693
      Alvaro Herrera authored
      There are a number of bugs in this area.  Two of them are fixed here,
      1. get_relation_idx_constraint_oid does not restrict the type of
         constraint that's returned, so with sufficient bad luck it can
         return the OID of a foreign key constraint.  This has the effect that
         a primary key in a partition can end up as a child of a foreign key,
         which makes no sense (it needs to be the child of the equivalent
         primary key.)
         Change the API contract so that only index-backed constraints are
         returned, mimicking get_constraint_index().
      2. Both CloneFkReferenced and CloneFkReferencing clone a
         self-referencing foreign key, so the partition ends up with
         a duplicate foreign key.  Change the former function to ignore such
      Add some tests to verify that things are better now.  (However, these
      new tests show some additional misbehavior that will be fixed later --
      namely that there's a constraint marked NOT VALID.)
      Backpatch to 12, where these constraints are possible at all.
      Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
      Discussion: https://postgr.es/m/20220603154232.1715b14c@karst
  21. 30 Sep, 2022 2 commits
    • Tom Lane's avatar
      Avoid improbable PANIC during heap_update, redux. · b93d7e68
      Tom Lane authored
      Commit 34f581c3 intended to ensure that RelationGetBufferForTuple
      would acquire a visibility-map page pin in case the otherBuffer's
      all-visible bit had become set since we last had lock on that page.
      But I missed a case: when we're extending the relation, VM concerns
      were dealt with only in the relatively-less-likely case that we
      fail to conditionally lock the otherBuffer.  I think I'd believed
      that we couldn't need to worry about it if the conditional lock
      succeeds, which is true for the target buffer; but the otherBuffer
      was unlocked for awhile so its bit might be set anyway.  So we need
      to do the GetVisibilityMapPins dance, and then also recheck the
      page's free space, in both cases.
      Per report from Jaime Casanova.  Back-patch to v12 as the previous
      patch was (although there's still no evidence that the bug is
      reachable pre-v14).
      Discussion: https://postgr.es/m/E1lWLjP-00006Y-Ml@gemulon.postgresql.org
    • Daniel Gustafsson's avatar
      doc: Fix PQsslAttribute docs for compression · 064e1c87
      Daniel Gustafsson authored
      The compression parameter to PQsslAttribute has never returned the
      compression method used, it has always returned "on" or "off since
      it was added in commit 91fa7b47. Backpatch through v10.
      Reviewed-by: default avatarTom Lane <tgl@sss.pgh.pa.us>
      Discussion: https://postgr.es/m/B9EC60EC-F665-47E8-A221-398C76E382C9@yesql.se
      Backpatch-through: v10
  22. 29 Sep, 2022 1 commit
  23. 28 Sep, 2022 1 commit