| Age | Commit message (Collapse) | Author |
|---|
|
Currently, we simply combine the column lists when publishing tables on
multiple publications and that can sometimes lead to unexpected behavior.
Say, if a column is published in any row-filtered publication, then the
values for that column are sent to the subscriber even for rows that don't
match the row filter, as long as the row matches the row filter for any
other publication, even if that other publication doesn't include the
column.
The main purpose of introducing a column list is to have statically
different shapes on publisher and subscriber or hide sensitive column
data. In both cases, it doesn't seem to make sense to combine column
lists.
So, we disallow the cases where the column list is different for the same
table when combining publications. It can be later extended to combine the
column lists for selective cases where required.
Reported-by: Alvaro Herrera
Author: Hou Zhijie
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/202204251548.mudq7jbqnh7r@alvherre.pgsql
|
|
The example given for anyelement <@ anymultirange didn't return
true as claimed; adjust it so it does.
In passing, change a couple of sample results where the modern
numeric-based logic produces a different number of trailing zeroes
than before.
Erik Rijkers
Discussion: https://postgr.es/m/cc35735d-1ec1-5bb3-9e27-cddbab7afa23@xs4all.nl
|
|
The PostgreSQL limitations section of the documents mentioned the limit
on the number of columns that can exist in a table. Users might be
surprised to find that there's also a limit on the number of columns that
can exist in a targetlist. Users may experience restrictions which
surprise them if they happened to select a large number of columns from
several tables with many columns. Here we document that there is a
limitation on this and mention what that limit actually is.
Wording proposal by Alvaro Herrera
Reported-by: Vladimir Sitnikov
Author: Dave Crammer
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAB=Je-E18aTYpNqje4mT0iEADpeGLSzwUvo3H9kRRuDdsNo4aQ@mail.gmail.com
Backpatch-through: 12, where the limitations section was added
|
|
PostgreSQL 14 changed the default to be scram-sha-256, so we should stop
recommending the user to use md5 or even worse password.
Suggested-By: Daniel Westermann
Author: Jonathan S. Katz
Backpatch-through: 14
Discussion: https://postgr.es/m/GV0P278MB0419A8BAC0B0B84AFA5263D9D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM
|
|
This reverts commit d9d076222f5b "VACUUM: ignore indexing operations
with CONCURRENTLY".
These changes caused indexes created with the CONCURRENTLY option to
miss heap tuples that were HOT-updated and HOT-pruned during the index
creation. Before these changes, HOT pruning would have been prevented
by the Xmin of the transaction creating the index, but because this
change was precisely to allow the Xmin to move forward ignoring that
backend, now other backends scanning the table can prune them. This is
not a problem for VACUUM (which requires a lock that conflicts with a
CREATE INDEX CONCURRENTLY operation), but HOT-prune can definitely
occur. In other words, Xmin advancement was sped up, but at the cost of
corrupting the resulting index.
Regrettably, this means that the new feature in PG14 that RIC/CIC on
very large tables no longer force VACUUM to retain very old tuples goes
away. We might try to implement it again in a later release, but for
now the risk of indexes missing tuples is too high and there's no easy
fix.
Backpatch to 14, where this change appeared.
Reported-by: Peter Slavov <pet.slavov@gmail.com>
Diagnosys-by: Andrey Borodin <x4mmm@yandex-team.ru>
Diagnosys-by: Michael Paquier <michael@paquier.xyz>
Diagnosys-by: Andres Freund <andres@anarazel.de>
Discussion: https://postgr.es/m/17485-396609c6925b982d%40postgresql.org
|
|
Commit cf0cab868 removed describe.c's support for pre-9.2 server
versions, but neglected to update this documentation reference.
Discussion: https://postgr.es/m/GV0P278MB041917EB3E2FE8704B5AE2C6D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM
|
|
runtime.sgml contains a passing reference to the minimum server
version that pg_dump[all] can dump from. That was 7.0 for many
years, but when 64f3524e2 raised it to 8.0, we missed updating this
bit. Then when 30e7c175b raised it to 9.2, we missed it again.
Given that track record, I'm not too hopeful that we'll remember
to fix this in future changes ... but for now, make the docs match
reality in each branch.
Noted by Daniel Westermann.
Discussion: https://postgr.es/m/GV0P278MB041917EB3E2FE8704B5AE2C6D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM
|
|
The information generated when track_activities is accessible to
superusers, roles with the privileges of pg_read_all_stats, as well as
roles one has the privileges of. The original text did not outline the
last point, while the change done in ac1ae47 was unclear about the
second point.
Per discussion with Nathan Bossart.
Discussion: https://postgr.es/m/20220521185743.GA886636@nathanxps13
Backpatch-through: 10
|
|
The form taking anymultirange had not been documented. This was
fixed in HEAD in b21c4cf95, but that should have been back-patched
to v14 since the function was added there. Do so now.
Also, the form taking anyrange was incorrectly documented as
returning anymultirange, when it returns anyrange.
Remove b21c4cf95 from the v15 release notes, since it no longer
qualifies as new-in-v15.
Noted by Shay Rojansky.
Discussion: https://postgr.es/m/CADT4RqAktzP7t6SFf0Xqm9YhahzvsmxFbzXe-gFOd=+_CHm0JA@mail.gmail.com
|
|
This column was missing from the table that describes the new view.
Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
Discussion: https://postgr.es/m/DM4PR84MB173401C19A0EB9B1CAAB197CEED29@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
|
|
Foreign tables can be partitioned, but previous documentation commits
left the syntax synopsis both incomplete and incorrect.
Justin Pryzby and Amit Langote
Discussion: http://postgr.es/m/20220521130922.GX19626@telsasoft.com
|
|
Reported-by: Amit Langote
Discussion: https://postgr.es/m/CA+HiwqFMmOK9cjrqxJeY1HKKbgMup0HcZ+Co7JuzJG_8ZypceA@mail.gmail.com
|
|
Reported-by: John Naylor
Discussion: https://postgr.es/m/CAFBsxsFhbhMbK_ZaLpH6J8BfJL_uowtGg+Qs9XA=F4uPU3aucA@mail.gmail.com
|
|
Upper-case MATCH so that it is clearer that it is a keyword in this
context.
Discussion: https://www.postgresql.org/message-id/flat/20220517.174342.1884842412165214815.horikyota.ntt%40gmail.com
|
|
This was apparently missed in the original commit.
Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
Discussion: https://www.postgresql.org/message-id/flat/DM4PR84MB1734BA51BC8B08CF3FA239BBEED49%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
|
|
The description of track_activities mentioned that it is visible to
superusers and that the information related to the current session can
be seen, without telling about pg_read_all_stats. Roles that are
granted the privileges of pg_read_all_stats can also see this
information, so mention it in the docs.
Author: Ian Barwick
Reviewed-by: Nathan Bossart
Discussion: https://postgr.es/m/CAB8KJ=jhPyYFu-A5r-ZGP+Ax715mUKsMxAGcEQ9Cx_mBAmrPow@mail.gmail.com
Backpatch-through: 10
|
|
The four fields tracking the time spent by queries for JIT operations
added in 57d6aea were listed as having bigint as data type, but these
are of type double precision.
Author: Noriyoshi Shinoda
Reviewed-by: Nathan Bossart
Discussion: https://postgr.es/m/DM4PR84MB1734375E63148AADC6A1E6B4EED39@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM
|
|
It wasn't previously mentioned that the index is created as invalid,
which is confusing to new users.
Backpatch to 14 (only because of a conflict in 13).
Author: Laurenz Albe <laurenz.albe@cybertec.at>
Reported-by: Lauren Fliksteen <dancernerd32@gmail.com>
Reviewed-by: Rajakavitha Kodhandapani <krajakavitha@gmail.com>
Discussion: https://postgr.es/m/165290238488.670.7500177735573254738@wrigleys.postgresql.org
|
|
The documentation didn't specify the name of the per-user service file
on Windows, and extrapolating from the pattern used for other config
files gave the wrong answer. The fact that it isn't consistent with the
others sure seems like a bug, but it's far too late to change that now;
we'd just penalize people who worked it out in the past. So, simply
document the true state of affairs.
In passing, fix some gratuitous differences between the discussions
of the service file and the password file.
Julien Rouhaud, per question from Dominique Devienne.
Backpatch to all supported branches. I (tgl) also chose to back-patch
the part of commit ba356a397 that touched libpq.sgml's description of
the service file --- in hindsight, I'm not sure why I didn't do so at
the time, as it includes some fairly essential information.
Discussion: https://postgr.es/m/CAFCRh-_mdLrh8eYVzhRzu4c8bAFEBn=rwoHOmFJcQOTsCy5nig@mail.gmail.com
|
|
This makes the documentation conform more closely the style of other
function sections.
Includes suggestions from Erik Rijkers, Alvaro Herrera, and Justin
Pryzby.
Discussion: https://postgr.es/m/CAKFQuwaq5Ny6d3nWbJo=QO4RmhSk9JD8zrkURLR-wWmB2Pkz7Q@mail.gmail.com
|
|
|
|
Commit 923def9a53 and 52e4f0cd47 allowed to specify column lists and row
filters for publication tables. This commit extends the
pg_publication_tables view and pg_get_publication_tables function to
display that information.
This information will be useful to users and we also need this for the
later commit that prohibits combining multiple publications with different
column lists for the same table.
Author: Hou Zhijie
Reviewed By: Amit Kapila, Alvaro Herrera, Shi Yu, Takamichi Osumi
Discussion: https://postgr.es/m/202204251548.mudq7jbqnh7r@alvherre.pgsql
|
|
There is no need for a <literal> inside a <synopsis>, since the latter
is already all "literal" implicitly. Also, create_help.pl misparses
it. So just remove it.
Reported-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/20220517.174342.1884842412165214815.horikyota.ntt%40gmail.com
|
|
|
|
Reported-by: John Naylor
Discussion: https://postgr.es/m/CAFBsxsE-US0sgVxVHjt99GCGky4TCD57gwMHWPF9XWo7R5rXPg@mail.gmail.com
|
|
Reaction to a suggestion from jhebert@micron.com, though this doesn't
directly address the complaint.
Discussion: https://postgr.es/m/165117307860.683.10308862820133754390@wrigleys.postgresql.org
|
|
Suggested by David G. Johnston <david.g.johnston@gmail.com>
Discussion: https://postgr.es/m/CAKFQuwYK4OqwoHscZi3yws-urv3NvVfoKHessyso5D=5qqChYQ@mail.gmail.com
|
|
Also move system view item to logical replication, mention "infinite
_error_ loops".
Reported-by: Euler Taveira, Takamichi Osumi, Amit Langote
Discussion: https://postgr.es/m/21e8ef3b-6ffb-49d8-867f-4622a4dffcf3@www.fastmail.com
|
|
protocol.sgml had some unusual indentation that kept getting added on
to with new additions in that file. This reindents it to be more in
line with the style elsewhere.
Discussion: https://www.postgresql.org/message-id/flat/15113594-649b-ce82-24c8-7522f1373da4%40enterprisedb.com
|
|
Currently, preloaded libraries are expected to request additional
shared memory and LWLocks in _PG_init(). However, it is not unusal
for such requests to depend on MaxBackends, which won't be
initialized at that time. Such requests could also depend on GUCs
that other modules might change. This introduces a new hook where
modules can safely use MaxBackends and GUCs to request additional
shared memory and LWLocks.
Furthermore, this change restricts requests for shared memory and
LWLocks to this hook. Previously, libraries could make requests
until the size of the main shared memory segment was calculated.
Unlike before, we no longer silently ignore requests received at
invalid times. Instead, we FATAL if someone tries to request
additional shared memory or LWLocks outside of the hook.
Nathan Bossart and Julien Rouhaud
Discussion: https://postgr.es/m/20220412210112.GA2065815%40nathanxps13
Discussion: https://postgr.es/m/Yn2jE/lmDhKtkUdr@paquier.xyz
|
|
It wasn't very clear that if this option was enabled, postgres_fdw would
commit remote transactions in parallel at main-transaction end, and
commit remote subtransactions in parallel at subtransaction end, due to
the references to (sub)transaction and other too specific documentation.
Clarify that. Also reword to simplify.
Follow-up for commit 04e706d42.
Jonathan S. Katz, reviewed by Justin Pryzby, with some modifications by
me.
Discussion: https://postgr.es/m/1435bfd1-172b-de38-f590-4404a5a62eb0%40postgresql.org
|
|
Reported-by: Amit Langote, Amit Kapila, Takamichi Osumi
Discussion: https://postgr.es/m/CAA4eK1KdAho_fNkYRe=o=XpxWs_TG4O0V8CJBAvTG8HamWt6OQ@mail.gmail.com
|
|
Reported-by: Ian Lawrence Barwick
Discussion: https://postgr.es/m/CAB8KJ=j9VhsFXuN+xv5qzxQV7gj-6TKqqwVLSgz5zU7F8nHCYw@mail.gmail.com
|
|
Reported-by: Thomas Munro
Discussion: https://postgr.es/m/CA+hUKGKha50-H2ye-9x3PJWU5wBq_MPc2rmVKM1xJ0tL+ntROw@mail.gmail.com
|
|
Reported-by: Ian Lawrence Barwick
Discussion: https://postgr.es/m/CAB8KJ=jmLBMAmxjcew12-yntb7m3FH-8A2+Qb7+RybZp1w9GOg@mail.gmail.com
|
|
Reported-by: David Rowley
Discussion: https://postgr.es/m/CAApHDvrToHFvL-W03vSi6T50uScyhrdUGzTtcuLAjdjtRF8FLA@mail.gmail.com
|
|
The code for unloading a library has been commented-out for over 12
years, ever since commit 602a9ef5a7c60151e10293ae3c4bb3fbb0132d03, and we're
no closer to supporting it now than we were back then.
Nathan Bossart, reviewed by Michael Paquier and by me.
Discussion: http://postgr.es/m/Ynsc9bRL1caUSBSE@paquier.xyz
|
|
Reported-by: Álvaro Herrera
Discussion: https://postgr.es/m/202205111412.n7xgu3eppins@alvherre.pgsql
|
|
Reported-by: David Rowley, Amit Langote
Discussion: https://postgr.es/m/CA+HiwqFcEdbNinfK94aTgBJKmtkYGdtkPnjt3b0fVzKi+WZ+KA@mail.gmail.com
|
|
Presently, the server may emit a variety of log messages when inspecting
a runtime-computed GUC, mostly in the shape of one LOG message with the
default configuration, related to the startup sequence launched as such
GUCs require a load of the control file and of external shared
libraries.
For example, the server will always emit a "database system is shut
down" LOG (unless the user has set log_min_messages higher than LOG),
which is an annoying behavior as "postgres -C" is expected to only emit
in its output the parameter value we are looking for. The parameter
value is sent to stdout, while the logs are sent to stderr so we could
recommend to use a redirection, but there was not much love for this
workaround either.
To avoid such extra log messages, per discussion, this change sets
log_min_messages to FATAL internally when -C is used on a
runtime-computed GUC (even if set to PANIC in postgresql.conf). At
FATAL, the user will still receive messages explaining why a GUC value
cannot be inspected, and will know if the command is attempted on a
server already running, something not supported yet for a
runtime-computed GUC.
Reported-by: Magnus Hagander, Bruce Momjian
Author: Nathan Bossart, Michael Paquier
Discussion: https://postgr.es/m/Yni6ZHkGotUU+RSf@paquier.xyz
|
|
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20220511013117.GG19626@telsasoft.com
|
|
Reported-by: Mark Dilger
Discussion: https://postgr.es/m/F3D44160-F41A-4F2E-AED5-5C15B6903AC4@enterprisedb.com
|
|
Remove SSL item backpatched (Jonathan S. Katz), adjust logical
replication item (Mark Dilger), adjust --compress wording (Justin
Pryzby).
Discussion: https://postgr.es/m/20220511012854.GF19626@telsasoft.com
|
|
Also improve postgres_fdw.application_name
Reported-by: Justin Pryzby, Tatsuo Ishii
Diagnosed-by: 20220510210235.GD19626@telsasoft.com
|
|
Reported-by: Jonathan Katz
Discussion: per private email
|
|
Reported-by: Nathan Bossart, Jonathan Katz
Discussion: https://postgr.es/m/20220510194456.GA3716556@nathanxps13
|
|
Reported-by: Erik Rijkers, Justin Pryzby
Discussion: https://postgr.es/m/20220510180935.GB19626@telsasoft.com
|
|
Several keywords were missing or misclassified in the original
SQL:2016 standard. This has been corrected in later technical
corrigenda. This change updates the PostgreSQL documentation
accordingly.
This also fixes a mistake in 606948b058d: The keywords JSON_SCALAR and
JSON_SERIALIZE added there are not from SQL:2016 but from future
SQL:202x, so they don't belong in that list yet.
(606948b058d also added JSON to the reserved list, which is what the
corrigendum also does, but failed to remove it from the nonreserved
list.)
|
|
Reported-by: Geoff Winkless
Discussion: https://postgr.es/m/CAEzk6fdF_J4jqicLz=FZ6R1u2EjpEtmzD55tFjVbxw-O-kR1=w@mail.gmail.com
|
|
|
