Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 10 May, 2021 4 commits
    • Michael Paquier's avatar
      Fix generation of ./INSTALL for the distribution tarball · 45aa88fe
      Michael Paquier authored 
      "make dist", in charge of creating a distribution tarball, failed when
attempting to generate ./INSTALL as a new reference added to
guc-default-toast-compression on the documentation for the installation
details was not getting translated properly to plain text.  Like all the
other link references on this page, this adds a new entry to
standalone-profile.xsl to allow the generation of ./INSTALL to finish
properly.

Oversight in 02a93e7e, per buildfarm member guaibasaurus.
      45aa88fe
    • Thomas Munro's avatar
      Revert recovery prefetching feature. · c2dc1934
      Thomas Munro authored 
      This set of commits has some bugs with known fixes, but at this late
stage in the release cycle it seems best to revert and resubmit next
time, along with some new automated test coverage for this whole area.

Commits reverted:

dc88460c: Doc: Review for "Optionally prefetch referenced data in recovery."
1d257577: Optionally prefetch referenced data in recovery.
f003d9f8: Add circular WAL decoding buffer.
323cbe7c: Remove read_page callback from XLogReader.

Remove the new GUC group WAL_RECOVERY recently added by a55a9847, as the
corresponding section of config.sgml is now reverted.

Discussion: https://postgr.es/m/CAOuzzgrn7iKnFRsB4MHp3UisEQAGgZMbk_ViTN4HV4-Ksq8zCg%40mail.gmail.com
      c2dc1934
    • Michael Paquier's avatar
      Add more TAP tests for pg_dump with attribute compression · 63db0ac3
      Michael Paquier authored 
      Some relations with LZ4 used as the toast compression methods have been
left around in the main regression test suite to stress pg_upgrade, but
pg_dump, that includes tests much more picky in terms of output
generated, had no actual coverage with this feature.

Similarly to collations, tests only working with LZ4 are tracked with an
additional flag, and this uses TestLib::check_pg_config() to check if
the build supports LZ4 or not.  This stresses more scenarios with
tables, materialized views and pg_dump --no-toast-compression.

Author: Dilip Kumar
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CAFiTN-twgPmohG7qj1HXhySq16h123y5OowsQR+5h1YeZE9fmQ@mail.gmail.com
      63db0ac3
    • Michael Paquier's avatar
      doc: Fix some gaps with the documentation related to LZ4 · 02a93e7e
      Michael Paquier authored 
      The upstream project is officially named "LZ4", and the documentation
was confused with the option value that can be used with DDLs supporting
this option, and the project name.

Documentation related to the configure option --with-lz4 was missing, so
add something for that.

Author: Dilip Kumar, Michael Paquier
Reviewed-by: Justin Pryzby
Discussion: https://postgr.es/m/YJaOZQDXBVySq+Cc@paquier.xyz
      02a93e7e
  3. 09 May, 2021 1 commit
  5. 08 May, 2021 4 commits
    • David Rowley's avatar
      Move memory accounting Asserts for Result Cache code · 92c4c269
      David Rowley authored 
      In 9eacee2e, I included some code to verify the cache's memory tracking
is correct by counting up the number of entries and the memory they use
each time we evict something from the cache.  Those values are then
compared to the expected values using Assert.  The problem is that this
requires looping over the entire cache hash table each time we evict an
entry from the cache.  That can be pretty expensive, as noted by Pavel
Stehule.

Here we move this memory accounting checking code so that we only verify
it on cassert builds once when shutting down the Result Cache node.

Aside from the performance increase, this has two distinct advantages:

1) We do the memory checks at the last possible moment before destroying
   the cache.  This means we'll now catch accounting problems that might
   sneak in after a cache eviction.

2) We now do the memory Assert checks when there were no cache evictions.
   This increases the coverage.

One small disadvantage is that we'll now miss any memory tracking issues
that somehow managed to resolve themselves by the end of execution.
However, it seems to me that such a memory tracking problem would be quite
unlikely, and likely somewhat less harmful if one were to exist.

In passing, adjust the loop over the hash table to use the standard
simplehash.h method of iteration.

Reported-by: Pavel Stehule
Discussion: https://postgr.es/m/CAFj8pRAzgoSkdEiqrKbT=7yG9FA5fjUAP3jmJywuDqYq6Ki5ug@mail.gmail.com
      92c4c269
    • Tom Lane's avatar
      Sync guc.c and postgresql.conf.sample with the SGML docs. · a55a9847
      Tom Lane authored 
      It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree.  Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml.  Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.

(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)

Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577 didn't.  As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups.  No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.

In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.

While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.

Bharath Rupireddy, Justin Pryzby, Tom Lane

Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
      a55a9847
    • Tom Lane's avatar
      Doc: copy-editing for debug_invalidate_system_caches_always description. · f9b809e7
      Tom Lane authored 
      I came to fix "useful only useful", but the more I looked at the text
the more things I thought could be improved.
      f9b809e7
    • Michael Paquier's avatar
      Fix incorrect error code for CREATE/ALTER TABLE COMPRESSION · 9681f216
      Michael Paquier authored 
      Specifying an incorrect value for the compression method of an attribute
caused ERRCODE_FEATURE_NOT_SUPPORTED to be raised as error.  Use instead
ERRCODE_INVALID_PARAMETER_VALUE to be more consistent.

Author: Dilip Kumar
Discussion: https://postgr.es/m/CAFiTN-vH84fE-8C4zGZw4v0Wyh4Y2v=5JWg2fGE5+LPaDvz1GQ@mail.gmail.com
      9681f216
  7. 07 May, 2021 11 commits
  9. 06 May, 2021 12 commits
  11. 05 May, 2021 4 commits
    • Alvaro Herrera's avatar
      Remove unused argument of ATAddForeignConstraint · c250062d
      Alvaro Herrera authored 
      Commit 0325d7a5 made this unused but forgot to remove it. Do so now.

Author: Amit Langote <amitlangote09@gmail.com>
Discussion: https://postgr.es/m/209c99fe-b9a2-94f4-cd68-a8304186a09e@lab.ntt.co.jp
      c250062d
    • Alvaro Herrera's avatar
      Have ALTER CONSTRAINT recurse on partitioned tables · 6f70d7ca
      Alvaro Herrera authored 
      When ALTER TABLE .. ALTER CONSTRAINT changes deferrability properties
changed in a partitioned table, we failed to propagate those changes
correctly to partitions and to triggers.  Repair by adding a recursion
mechanism to affect all derived constraints and all derived triggers.
(In particular, recurse to partitions even if their respective parents
are already in the desired state: it is possible for the partitions to
have been altered individually.)  Because foreign keys involve tables in
two sides, we cannot use the standard ALTER TABLE recursion mechanism,
so we invent our own by following pg_constraint.conparentid down.

When ALTER TABLE .. ALTER CONSTRAINT is invoked on the derived
pg_constraint object that's automaticaly created in a partition as a
result of a constraint added to its parent, raise an error instead of
pretending to work and then failing to modify all the affected triggers.
Before this commit such a command would be allowed but failed to affect
all triggers, so it would silently misbehave.  (Restoring dumps of
existing databases is not affected, because pg_dump does not produce
anything for such a derived constraint anyway.)

Add some tests for the case.

Backpatch to 11, where foreign key support was added to partitioned
tables by commit 3de241db.  (A related change is commit f56f8f8d
in pg12 which added support for FKs *referencing* partitioned tables;
this is what forces us to use an ad-hoc recursion mechanism for this.)

Diagnosed by Tom Lane from bug report from Ron L Johnson.  As of this
writing, no reviews were offered.

Discussion: https://postgr.es/m/75fe0761-a291-86a9-c8d8-4906da077469@gmail.com
Discussion: https://postgr.es/m/3144850.1607369633@sss.pgh.pa.us
      6f70d7ca
    • Tom Lane's avatar
      Doc: improve and centralize the documentation for OID alias types. · f33a178a
      Tom Lane authored 
      Previously, a lot of information about type regclass existed only
in the discussion of the sequence functions.  Maybe that made sense
in the beginning, because I think originally those were the only
functions taking regclass.  But it doesn't make sense anymore.
Move that material to the "Object Identifier Types" section in
datatype.sgml, generalize it to talk about the other reg* types
as well, and add more examples.

Per bug #16991 from Federico Caselli.

Discussion: https://postgr.es/m/16991-bcaeaafa17e0a723@postgresql.org
      f33a178a
    • Peter Eisentraut's avatar
      GUC description improvements for clarity · 38f36aad
      Peter Eisentraut authored
      38f36aad
  13. 04 May, 2021 4 commits