1. 30 Aug, 2021 1 commit
  2. 10 Jun, 2021 1 commit
  3. 12 May, 2021 1 commit
    • Tom Lane's avatar
      Initial pgindent and pgperltidy run for v14. · def5b065
      Tom Lane authored
      Also "make reformat-dat-files".
      
      The only change worthy of note is that pgindent messed up the formatting
      of launcher.c's struct LogicalRepWorkerId, which led me to notice that
      that struct wasn't used at all anymore, so I just took it out.
      def5b065
  4. 23 Feb, 2021 1 commit
  5. 10 Feb, 2021 1 commit
    • Amit Kapila's avatar
      Make pg_replication_origin_drop safe against concurrent drops. · cd142e03
      Amit Kapila authored
      Currently, we get the origin id from the name and then drop the origin by
      taking ExclusiveLock on ReplicationOriginRelationId. So, two concurrent
      sessions can get the id from the name at the same time and then when they
      try to drop the origin, one of the sessions will get the either
      "tuple concurrently deleted" or "cache lookup failed for replication
      origin ..".
      
      To prevent this race condition we do the entire operation under lock. This
      obviates the need for replorigin_drop() API and we have removed it so if
      any extension authors are using it they need to instead use
      replorigin_drop_by_name. See it's usage in pg_replication_origin_drop().
      
      Author: Peter Smith
      Reviewed-by: Amit Kapila, Euler Taveira, Petr Jelinek, and Alvaro
      Herrera
      Discussion: https://www.postgresql.org/message-id/CAHut%2BPuW8DWV5fskkMWWMqzt-x7RPcNQOtJQBp6SdwyRghCk7A%40mail.gmail.com
      cd142e03
  6. 25 Jan, 2021 1 commit
    • Robert Haas's avatar
      Remove CheckpointLock. · d18e7566
      Robert Haas authored
      Up until now, we've held this lock when performing a checkpoint or
      restartpoint, but commit 076a055a back
      in 2004 and commit 7e48b77b from 2009,
      taken together, have removed all need for this. In the present code,
      there's only ever one process entitled to attempt a checkpoint: either
      the checkpointer, during normal operation, or the postmaster, during
      single-user operation. So, we don't need the lock.
      
      One possible concern in making this change is that it means that
      a substantial amount of code where HOLD_INTERRUPTS() was previously
      in effect due to the preceding LWLockAcquire() will now be
      running without that. This could mean that ProcessInterrupts()
      gets called in places from which it didn't before. However, this
      seems unlikely to do very much, because the checkpointer doesn't
      have any signal mapped to die(), so it's not clear how,
      for example, ProcDiePending = true could happen in the first
      place. Similarly with ClientConnectionLost and recovery conflicts.
      
      Also, if there are any such problems, we might want to fix them
      rather than reverting this, since running lots of code with
      interrupt handling suspended is generally bad.
      
      Patch by me, per an inquiry by Amul Sul. Review by Tom Lane
      and Michael Paquier.
      
      Discussion: http://postgr.es/m/CAAJ_b97XnBBfYeSREDJorFsyoD1sHgqnNuCi=02mNQBUMnA=FA@mail.gmail.com
      d18e7566
  7. 05 Jan, 2021 1 commit
  8. 02 Jan, 2021 1 commit
  9. 04 Dec, 2020 1 commit
  10. 14 Jun, 2020 1 commit
    • Michael Paquier's avatar
      Replace superuser check by ACLs for replication origin functions · cc072641
      Michael Paquier authored
      This patch removes the hardcoded check for superuser privileges when
      executing replication origin functions.  Instead, execution is revoked
      from public, meaning that those functions can be executed by a superuser
      and that access to them can be granted.
      
      Author: Martín Marqués
      Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Masahiko Sawada
      Discussion: https:/postgr.es/m/CAPdiE1xJMZOKQL3dgHMUrPqysZkgwzSMXETfKkHYnBAB7-0VRQ@mail.gmail.com
      cc072641
  11. 12 Jun, 2020 1 commit
  12. 07 Jun, 2020 1 commit
  13. 15 May, 2020 2 commits
    • Tom Lane's avatar
      Fix bogus initialization of replication origin shared memory state. · 80484049
      Tom Lane authored
      The previous coding zeroed out offsetof(ReplicationStateCtl, states)
      more bytes than it was entitled to, as a consequence of starting the
      zeroing from the wrong pointer (or, if you prefer, using the wrong
      calculation of how much to zero).
      
      It's unsurprising that this has not caused any reported problems,
      since it can be expected that the newly-allocated block is at the end
      of what we've used in shared memory, and we always make the shmem
      block substantially bigger than minimally necessary.  Nonetheless,
      this is wrong and it could bite us someday; plus it's a dangerous
      model for somebody to copy.
      
      This dates back to the introduction of this code (commit 5aa23504),
      so back-patch to all supported branches.
      80484049
    • Tom Lane's avatar
      Rename assorted LWLock tranches. · 36ac359d
      Tom Lane authored
      Choose names that fit into the conventions for wait event names
      (particularly, that multi-word names are in the style MultiWordName)
      and hopefully convey more information to non-hacker users than the
      previous names did.
      
      Also rename SerializablePredicateLockListLock to
      SerializablePredicateListLock; the old name was long enough to cause
      table formatting problems, plus the double occurrence of "Lock" seems
      confusing/error-prone.
      
      Also change a couple of particularly opaque LWLock field names.
      
      Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
      36ac359d
  14. 14 May, 2020 1 commit
    • Tom Lane's avatar
      Collect built-in LWLock tranche names statically, not dynamically. · 29c3e2dd
      Tom Lane authored
      There is little point in using the LWLockRegisterTranche mechanism for
      built-in tranche names.  It wastes cycles, it creates opportunities for
      bugs (since failing to register a tranche name is a very hard-to-detect
      problem), and the lack of any centralized list of names encourages
      sloppy nonconformity in name choices.  Moreover, since we have a
      centralized list of the tranches anyway in enum BuiltinTrancheIds, we're
      certainly not buying any flexibility in return for these disadvantages.
      
      Hence, nuke all the backend-internal LWLockRegisterTranche calls,
      and instead provide a const array of the builtin tranche names.
      
      (I have in mind to change a bunch of these names shortly, but this
      patch is just about getting them into one place.)
      
      Discussion: https://postgr.es/m/9056.1589419765@sss.pgh.pa.us
      29c3e2dd
  15. 01 Jan, 2020 1 commit
  16. 26 Dec, 2019 1 commit
  17. 25 Dec, 2019 1 commit
    • Michael Paquier's avatar
      Rename files and headers related to index AM · 8ce3aa9b
      Michael Paquier authored
      The following renaming is done so as source files related to index
      access methods are more consistent with table access methods (the
      original names used for index AMs ware too generic, and could be
      confused as including features related to table AMs):
      - amapi.h -> indexam.h.
      - amapi.c -> indexamapi.c.  Here we have an equivalent with
      backend/access/table/tableamapi.c.
      - amvalidate.c -> indexamvalidate.c.
      - amvalidate.h -> indexamvalidate.h.
      - genam.c -> indexgenam.c.
      - genam.h -> indexgenam.h.
      
      This has been discussed during the development of v12 when table AM was
      worked on, but the renaming never happened.
      
      Author: Michael Paquier
      Reviewed-by: Fabien Coelho, Julien Rouhaud
      Discussion: https://postgr.es/m/20191223053434.GF34339@paquier.xyz
      8ce3aa9b
  18. 12 Nov, 2019 1 commit
  19. 08 Nov, 2019 1 commit
  20. 21 Aug, 2019 1 commit
    • Alvaro Herrera's avatar
      Fix typo · 8f75e8e4
      Alvaro Herrera authored
      In early development patches, "replication origins" were called "identifiers";
      almost everything was renamed, but these references to the old terminology
      went unnoticed.
      
      Reported-by: Craig Ringer
      8f75e8e4
  21. 07 Jul, 2019 1 commit
  22. 29 Jun, 2019 2 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
      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
  23. 17 Apr, 2019 1 commit
  24. 08 Mar, 2019 1 commit
    • Michael Paquier's avatar
      Tighten use of OpenTransientFile and CloseTransientFile · 82a5649f
      Michael Paquier authored
      This fixes two sets of issues related to the use of transient files in
      the backend:
      1) OpenTransientFile() has been used in some code paths with read-write
      flags while read-only is sufficient, so switch those calls to be
      read-only where necessary.  These have been reported by Joe Conway.
      2) When opening transient files, it is up to the caller to close the
      file descriptors opened.  In error code paths, CloseTransientFile() gets
      called to clean up things before issuing an error.  However in normal
      exit paths, a lot of callers of CloseTransientFile() never actually
      reported errors, which could leave a file descriptor open without
      knowing about it.  This is an issue I complained about a couple of
      times, but never had the courage to write and submit a patch, so here we
      go.
      
      Note that one frontend code path is impacted by this commit so as an
      error is issued when fetching control file data, making backend and
      frontend to be treated consistently.
      
      Reported-by: Joe Conway, Michael Paquier
      Author: Michael Paquier
      Reviewed-by: Álvaro Herrera, Georgios Kokolatos, Joe Conway
      Discussion: https://postgr.es/m/20190301023338.GD1348@paquier.xyz
      Discussion: https://postgr.es/m/c49b69ec-e2f7-ff33-4f17-0eaa4f2cef27@joeconway.com
      82a5649f
  25. 22 Jan, 2019 1 commit
    • Andres Freund's avatar
      Move generic snapshot related code from tqual.h to snapmgr.h. · b7eda3e0
      Andres Freund authored
      The code in tqual.c is largely heap specific. Due to the upcoming
      pluggable storage work, it therefore makes sense to move it into
      access/heap/ (as the file's header notes, the tqual name isn't very
      good).
      
      But the various statically allocated snapshot and snapshot
      initialization functions are now (see previous commit) generic and do
      not depend on functions declared in tqual.h anymore. Therefore move.
      Also move XidInMVCCSnapshot as that's useful for future AMs, and
      already used outside of tqual.c.
      
      Author: Andres Freund
      Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
      b7eda3e0
  26. 21 Jan, 2019 2 commits
  27. 02 Jan, 2019 1 commit
  28. 04 Aug, 2018 1 commit
  29. 23 Jul, 2018 1 commit
    • Michael Paquier's avatar
      Add proper errcodes to new error messages for read() failures · e41d0a10
      Michael Paquier authored
      Those would use the default ERRCODE_INTERNAL_ERROR, but for foreseeable
      failures an errcode ought to be set, ERRCODE_DATA_CORRUPTED making the
      most sense here.
      
      While on the way, fix one errcode_for_file_access missing in origin.c
      since the code has been created, and remove one assignment of errno to 0
      before calling read(), as this was around to fit with what was present
      before 811b6e36 where errno would not be set when not enough bytes are
      read.  I have noticed the first one, and Tom has pinged me about the
      second one.
      
      Author: Michael Paquier
      Reported-by: Tom Lane
      Discussion: https://postgr.es/m/27265.1531925836@sss.pgh.pa.us
      e41d0a10
  30. 18 Jul, 2018 1 commit
    • Heikki Linnakangas's avatar
      Fix misc typos, mostly in comments. · 6b387179
      Heikki Linnakangas authored
      A collection of typos I happened to spot while reading code, as well as
      grepping for common mistakes.
      
      Backpatch to all supported versions, as applicable, to avoid conflicts
      when backporting other commits in the future.
      6b387179
  31. 17 Jul, 2018 1 commit
    • Michael Paquier's avatar
      Rework error messages around file handling · 811b6e36
      Michael Paquier authored
      Some error messages related to file handling are using the code path
      context to define their state.  For example, 2PC-related errors are
      referring to "two-phase status files", or "relation mapping file" is
      used for catalog-to-filenode mapping, however those prove to be
      difficult to translate, and are not more helpful than just referring to
      the path of the file being worked on.  So simplify all those error
      messages by just referring to files with their path used.  In some
      cases, like the manipulation of WAL segments, the context is actually
      helpful so those are kept.
      
      Calls to the system function read() have also been rather inconsistent
      with their error handling sometimes not reporting the number of bytes
      read, and some other code paths trying to use an errno which has not
      been set.  The in-core functions are using a more consistent pattern
      with this patch, which checks for both errno if set or if an
      inconsistent read is happening.
      
      So as to care about pluralization when reading an unexpected number of
      byte(s), "could not read: read %d of %zu" is used as error message, with
      %d field being the output result of read() and %zu the expected size.
      This simplifies the work of translators with less variations of the same
      message.
      
      Author: Michael Paquier
      Reviewed-by: Álvaro Herrera
      Discussion: https://postgr.es/m/20180520000522.GB1603@paquier.xyz
      811b6e36
  32. 25 Jun, 2018 1 commit
    • Michael Paquier's avatar
      Address set of issues with errno handling · 6cb33724
      Michael Paquier authored
      System calls mixed up in error code paths are causing two issues which
      several code paths have not correctly handled:
      1) For write() calls, sometimes the system may return less bytes than
      what has been written without errno being set.  Some paths were careful
      enough to consider that case, and assumed that errno should be set to
      ENOSPC, other calls missed that.
      2) errno generated by a system call is overwritten by other system calls
      which may succeed once an error code path is taken, causing what is
      reported to the user to be incorrect.
      
      This patch uses the brute-force approach of correcting all those code
      paths.  Some refactoring could happen in the future, but this is let as
      future work, which is not targeted for back-branches anyway.
      
      Author: Michael Paquier
      Reviewed-by: Ashutosh Sharma
      Discussion: https://postgr.es/m/20180622061535.GD5215@paquier.xyz
      6cb33724
  33. 13 Feb, 2018 1 commit
  34. 11 Jan, 2018 1 commit
  35. 09 Jan, 2018 1 commit
    • Tom Lane's avatar
      Fix race condition during replication origin drop. · 8a906204
      Tom Lane authored
      replorigin_drop() misunderstood the API for condition variables: it
      had ConditionVariablePrepareToSleep and ConditionVariableCancelSleep
      inside its test-and-sleep loop, rather than outside the loop as
      intended.  The net effect is a narrow race-condition window wherein,
      if the process using a replication slot releases it immediately after
      replorigin_drop() releases the ReplicationOriginLock, replorigin_drop()
      would get into the condition variable's wait list too late and then
      wait indefinitely for a signal that won't come.
      
      Because there's a different CV for each replication slot, we can't
      just move the ConditionVariablePrepareToSleep call to above the
      test-and-sleep loop.  What we can do, in the wake of commit 13db3b93,
      is drop the ConditionVariablePrepareToSleep call entirely.  This fix
      depends on that commit because (at least in principle) the slot matching
      the target replication origin might move around, so that once in a blue
      moon successive loop iterations might involve different CVs.  We can now
      cope with such a scenario, at the cost of an extra trip through the
      retry loop.
      
      (There are ways we could fix this bug without depending on that commit,
      but they're all a lot more complicated than this way.)
      
      While at it, upgrade the rather skimpy comments in this function.
      
      Back-patch to v10 where this code came in.
      
      Discussion: https://postgr.es/m/19947.1515455433@sss.pgh.pa.us
      8a906204
  36. 03 Jan, 2018 1 commit
  37. 05 Oct, 2017 1 commit