aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Fix typos and inconsistencies in code commentsMichael Paquier2019-06-14
| | | | | Author: Alexander Lakhin Discussion: https://postgr.es/m/dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com
* Use OpenSSL-specific ifdefs in sha2.hMichael Paquier2019-06-14
| | | | | | | | | | In order to separate OpenSSL's SHA symbols, this header has been using USE_SSL, which is equivalent to USE_OPENSSL. There is now only one SSL implementation included in the tree, so this works fine, but when adding a new SSL implementation this would run into failures. Author: Daniel Gustafsson Discussion: https://postgr.es/m/0DF29010-CE26-4F51-85A6-9C8ABF5536F9@yesql.se
* Avoid combinatorial explosion in add_child_rel_equivalences().Tom Lane2019-06-13
| | | | | | | | | | | | | | | | | | | | | | | | If an EquivalenceClass member expression includes variables from multiple appendrels, then instead of producing one substituted expression per child relation as intended, we'd create additional child expressions for combinations of children of different appendrels. This happened because the child expressions generated while considering the first appendrel were taken as sources during substitution of the second appendrel, and so on. The extra expressions are useless, and are harmless unless there are too many of them --- but if you have several appendrels with a thousand or so members each, it gets bad fast. To fix, consider only original (non-em_is_child) EC members as candidates to be expanded. This requires the ability to substitute directly from a top parent relation's Vars to those of an indirect descendant relation, but we already have that in adjust_appendrel_attrs_multilevel(). Per bug #15847 from Feike Steenbergen. This is a longstanding misbehavior, but it's only worth worrying about when there are more appendrel children than we've historically considered wise to use. So I'm not going to take the risk of back-patching this. Discussion: https://postgr.es/m/15847-ea3734094bf8ae61@postgresql.org
* Avoid spurious deadlocks when upgrading a tuple lockAlvaro Herrera2019-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When two (or more) transactions are waiting for transaction T1 to release a tuple-level lock, and transaction T1 upgrades its lock to a higher level, a spurious deadlock can be reported among the waiting transactions when T1 finishes. The simplest example case seems to be: T1: select id from job where name = 'a' for key share; Y: select id from job where name = 'a' for update; -- starts waiting for X Z: select id from job where name = 'a' for key share; T1: update job set name = 'b' where id = 1; Z: update job set name = 'c' where id = 1; -- starts waiting for X T1: rollback; At this point, transaction Y is rolled back on account of a deadlock: Y holds the heavyweight tuple lock and is waiting for the Xmax to be released, while Z holds part of the multixact and tries to acquire the heavyweight lock (per protocol) and goes to sleep; once X releases its part of the multixact, Z is awakened only to be put back to sleep on the heavyweight lock that Y is holding while sleeping. Kaboom. This can be avoided by having Z skip the heavyweight lock acquisition. As far as I can see, the biggest downside is that if there are multiple Z transactions, the order in which they resume after X finishes is not guaranteed. Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't work there (because isolationtester is not smart enough), so I'm not going to risk it. Author: Oleksii Kliukin Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com
* Mark ReplicationSlotCtl as PGDLLIMPORT.Tom Lane2019-06-13
| | | | | | | | | | | | | Also MyReplicationSlot, in branches where it wasn't already. This was discussed in the thread that resulted in c572599c6, but for some reason nobody pulled the trigger. Now that we have another request for the same thing, we should just do it. Craig Ringer Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com Discussion: https://postgr.es/m/345138875.20190611151943@cybertec.at
* Fix double-word typosAlvaro Herrera2019-06-13
| | | | | Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql Reviewed-by: Michaël Paquier
* doc: PG 12 relnotes: update wording on truncate/vacuum itemBruce Momjian2019-06-13
| | | | | | | | | This item prevents unauthorized locking of relations, and the previous wording was unclear. Reported-by: Michael Paquier Discussion: https://postgr.es/m/20190522072651.GC1278@paquier.xyz
* postgres_fdw: Account for triggers in non-direct remote UPDATE planning.Etsuro Fujita2019-06-13
| | | | | | | | | | | | | | | | | | Previously, in postgresPlanForeignModify, we planned an UPDATE operation on a foreign table so that we transmit only columns that were explicitly targets of the UPDATE, so as to avoid unnecessary data transmission, but if there were BEFORE ROW UPDATE triggers on the foreign table, those triggers might change values for non-target columns, in which case we would miss sending changed values for those columns. Prevent optimizing away transmitting all columns if there are BEFORE ROW UPDATE triggers on the foreign table. This is an oversight in commit 7cbe57c34 which added triggers on foreign tables, so apply the patch all the way back to 9.4 where that came in. Author: Shohei Mochizuki Reviewed-by: Amit Langote Discussion: https://postgr.es/m/201905270152.x4R1q3qi014550@toshiba.co.jp
* Doc: fix bogus example.Tom Lane2019-06-12
| | | | | | | | | This wasn't incorrect SQL, but it was doing cm-to-inch conversion backward, so it might confuse readers. Per bug #15849 from TAKATSUKA Haruka. Discussion: https://postgr.es/m/15849-37ad0c561a836107@postgresql.org
* Doc: improve description of allowed spellings for Boolean input.Tom Lane2019-06-12
| | | | | | | | | | | | | | | | datatype.sgml failed to explain that boolin() accepts any unique prefix of the basic input strings. Indeed it was actively misleading because it called out a few minimal prefixes without mentioning that there were more valid inputs. I also felt that it wasn't doing anybody any favors by conflating SQL key words, valid Boolean input, and string literals containing valid Boolean input. Rewrite in hopes of reducing the confusion. Per bug #15836 from Yuming Wang, as diagnosed by David Johnston. Back-patch to supported branches. Discussion: https://postgr.es/m/15836-656fab055735f511@postgresql.org
* docs: PG 12 relnotes, update btree itemsBruce Momjian2019-06-12
| | | | | | Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wzn-aH4ToZEWR05ELSSp7bO_JMn=sMPfUhNruwVmCXKh-w@mail.gmail.com
* Fix incorrect printing of queries with duplicated join names.Tom Lane2019-06-12
| | | | | | | | | | | | | | | | | Given a query in which multiple JOIN nodes used the same alias (which'd necessarily be in different sub-SELECTs), ruleutils.c would assign the JOIN nodes distinct aliases for clarity ... but then it forgot to print the modified aliases when dumping the JOIN nodes themselves. This results in a dump/reload hazard for views, because the emitted query is flat-out incorrect: Vars will be printed with table names that have no referent. This has been wrong for a long time, so back-patch to all supported branches. Philip Dubé Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com
* doc: Fix grammatical error in partitioning docsDavid Rowley2019-06-13
| | | | | | Reported-by: Amit Langote Discussion: https://postgr.es/m/CA+HiwqGZFkKi0TkBGYpr2_5qrRAbHZoP47AP1BRLUOUkfQdy_A@mail.gmail.com Backpatch-through: 10
* doc: PG 12 relnotes, list added snowball/FTS languagesBruce Momjian2019-06-12
| | | | | | Reported-by: Adrien Nayrat Discussion: https://postgr.es/m/9d6a7515-bcd8-05be-d2a5-e81dc11023cd@anayrat.info
* doc: PG 12 relnotes, merge new SQL partition function itemsBruce Momjian2019-06-12
| | | | | | Reported-by: Andres Freund Discussion: https://postgr.es/m/20190528155823.3e4cezblxjxotq2q@alap3.anarazel.de
* Fix ALTER COLUMN TYPE failure with a partial exclusion constraint.Tom Lane2019-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ATExecAlterColumnType failed to consider the possibility that an index that needs to be rebuilt might be a child of a constraint that needs to be rebuilt. We missed this so far because usually a constraint index doesn't have a direct dependency on its table, just on the constraint object. But if there's a WHERE clause, then dependency analysis of the WHERE clause results in direct dependencies on the column(s) mentioned in WHERE. This led to trying to drop and rebuild both the constraint and its underlying index. In v11/HEAD, we successfully drop both the index and the constraint, and then try to rebuild both, and of course the second rebuild hits a duplicate-index-name problem. Before v11, it fails with obscure messages about a missing relation OID, due to trying to drop the index twice. This is essentially the same kind of problem noted in commit 20bef2c31: the possible dependency linkages are broader than what ATExecAlterColumnType was designed for. It was probably OK when written, but it's certainly been broken since the introduction of partial exclusion constraints. Fix by adding an explicit check for whether any of the indexes-to-be-rebuilt belong to any of the constraints-to-be-rebuilt, and ignoring any that do. In passing, fix a latent bug introduced by commit 8b08f7d48: in get_constraint_index() we must "continue" not "break" when rejecting a relation of a wrong relkind. This is harmless today because we don't expect that code path to be taken anyway; but if there ever were any relations to be ignored, the existing coding would have an extremely undesirable dependency on the order of pg_depend entries. Also adjust a couple of obsolete comments. Per bug #15835 from Yaroslav Schekin. Back-patch to all supported branches. Discussion: https://postgr.es/m/15835-32d9b7a76c06a7a9@postgresql.org
* Fix handling of COMMENT for domain constraintsMichael Paquier2019-06-12
| | | | | | | | | | | | | | | | | | | | For a non-superuser, changing a comment on a domain constraint was leading to a cache lookup failure as the code tried to perform the ownership lookup on the constraint OID itself, thinking that it was a type, but this check needs to happen on the type the domain constraint relies on. As the type a domain constraint relies on can be guessed directly based on the constraint OID, first fetch its type OID and perform the ownership on it. This is broken since 7eca575, which has split the handling of comments for table constraints and domain constraints, so back-patch down to 9.5. Reported-by: Clemens Ladisch Author: Daniel Gustafsson, Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/15833-808e11904835d26f@postgresql.org Backpatch-through: 9.5
* doc: Add best practises section to partitioning docsDavid Rowley2019-06-12
| | | | | | | | | | | | | | | A few questionable partitioning designs have been cropping up lately around the mailing lists. Generally, these cases have been partitioning using too many partitions which have caused performance or OOM problems for the users. Since we have very little else to guide users into good design, here we add a new section to the partitioning documentation with some best practise guidelines for good design. Reviewed-by: Justin Pryzby, Amit Langote, Alvaro Herrera Discussion: https://postgr.es/m/CAKJS1f-2rx+E9mG3xrCVHupefMjAp1+tpczQa9SEOZWyU7fjEA@mail.gmail.com Backpatch-through: 10
* Fix conversion of JSON strings to JSON output columns in json_to_record().Tom Lane2019-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | json_to_record(), when an output column is declared as type json or jsonb, should emit the corresponding field of the input JSON object. But it got this slightly wrong when the field is just a string literal: it failed to escape the contents of the string. That typically resulted in syntax errors if the string contained any double quotes or backslashes. jsonb_to_record() handles such cases correctly, but I added corresponding test cases for it too, to prevent future backsliding. Improve the documentation, as it provided only a very hand-wavy description of the conversion rules used by these functions. Per bug report from Robert Vollmert. Back-patch to v10 where the error was introduced (by commit cf35346e8). Note that PG 9.4 - 9.6 also get this case wrong, but differently so: they feed the de-escaped contents of the string literal to json[b]_in. That behavior is less obviously wrong, so possibly it's being depended on in the field, so I won't risk trying to make the older branches behave like the newer ones. Discussion: https://postgr.es/m/D6921B37-BD8E-4664-8D5F-DB3525765DCD@vllmrt.net
* Fix order of steps in DISCARD ALL documentationAlvaro Herrera2019-06-11
| | | | | | | | | The docs have always been slightly inaccurate, but got particularly so in a874fe7b4c89, which made DISCARD ALL occur before everything else; reorder. Author: Jan Chochol Discussion: https://postgr.es/m/CAEASf_3TzBbnXm64HpnD5zCZEh8An9jN8ubMR=De-vOXHMHGeA@mail.gmail.com
* Don't access catalogs to validate GUCs when not connected to a DB.Andres Freund2019-06-10
| | | | | | | | | | | | | | | | | | | | | Vignesh found this bug in the check function for default_table_access_method's check hook, but that was just copied from older GUCs. Investigation by Michael and me then found the bug in further places. When not connected to a database (e.g. in a walsender connection), we cannot perform (most) GUC checks that need database access. Even when only shared tables are needed, unless they're nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed without pg_class etc. being present. Fix by extending the existing IsTransactionState() checks to also check for MyDatabaseOid. Reported-By: Vignesh C, Michael Paquier, Andres Freund Author: Vignesh C, Andres Freund Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com Backpatch: 9.4-
* postgres_fdw: Reorder C includes.Etsuro Fujita2019-06-11
| | | | | | | | | Reorder header files in postgres_fdw.c and connection.c in alphabetical order. Author: Etsuro Fujita Reviewed-by: Alvaro Herrera Discussion: https://postgr.es/m/CAPmGK17ZmNb-EELqu8LmMh2t2uFdbfWNVDEfDO5-bpejHPONMQ@mail.gmail.com
* Fix documentation of ALTER TABLE for stored valuesMichael Paquier2019-06-11
| | | | | Author: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoAA_gvZ002U6kovOHu0FsM7ieoCzdSqWBd7_KaQL0UMKg@mail.gmail.com
* tableam: Fix index_build_range_scan parameter name.Robert Haas2019-06-10
| | | | | | | | | | All of the other code thinks that the 8th parameter is the number of blocks, but this declaration thinks that it's the ending block number. Repair this inconsistency. Patch by me, reviewed by Andres Freund. Discussion: http://postgr.es/m/CA+TgmoY49ManQWnJtiwkuytXBkmyTuDFqb74Pr4Zn2Nq9TuNBQ@mail.gmail.com
* Make pg_dump emit ATTACH PARTITION instead of PARTITION OF (reprise)Alvaro Herrera2019-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using PARTITION OF can result in column ordering being changed from the database being dumped, if the partition uses a column layout different from the parent's. It's not pg_dump's job to editorialize on table definitions, so this is not acceptable; back-patch all the way back to pg10, where partitioned tables where introduced. This change also ensures that partitions end up in the correct tablespace, if different from the parent's; this is an oversight in ca4103025dfe (in pg12 only). Partitioned indexes (in pg11) don't have this problem, because they're already created as independent indexes and attached to their parents afterwards. This change also has the advantage that the partition is restorable from the dump (as a standalone table) even if its parent table isn't restored. The original commits (3b23552ad8bb in branch master) failed to cover subsidiary column elements correctly, such as NOT NULL constraint and CHECK constraints, as reported by Rushabh Lathia (initially as a failure to restore serial columns). They were reverted. This recapitulation commit fixes those problems. Add some pg_dump tests to verify these things more exhaustively, including constraints with legacy-inheritance tables, which were not tested originally. In branches 10 and 11, add a local constraint to the pg_dump test partition that was added by commit 2d7eeb1b1492 to master. Author: Álvaro Herrera, David Rowley Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com
* Fix operator naming in pg_trgm GUC option descriptionsAlexander Korotkov2019-06-10
| | | | | | | | | | | Descriptions of pg_trgm GUC options have % replaced with %% like it was a printf-like format. But that's not needed since they are just plain strings. This commit fixed that. Backpatch to last supported version since this error present from the beginning. Reported-by: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoAgPKODUsu9gqUFiNqEOAqedStxJ-a0sapsJXWWAVp%3Dxg%40mail.gmail.com Backpatch-through: 9.4
* Add docs of missing GUC to pgtrgm.sgmlAlexander Korotkov2019-06-10
| | | | | | | | | | be8a7a68 introduced pg_trgm.strict_word_similarity_threshold GUC, but missed docs for that. This commit fixes that. Discussion: https://postgr.es/m/fc907f70-448e-fda3-3aa4-209a59597af0%402ndquadrant.com Author: Ian Barwick Reviewed-by: Masahiko Sawada, Michael Paquier Backpatch-through: 9.6
* Fix docs indentation in pgtrgm.sgmlAlexander Korotkov2019-06-10
| | | | | | | | | | 5871b884 introduced pg_trgm.word_similarity_threshold GUC, but its documentation contains wrong indentation. This commit fixes that. Backpatch for easier backpatching of other documentation fixes. Discussion: https://postgr.es/m/4c735d30-ab59-fc0e-45d8-f90eb5ed3855%402ndquadrant.com Author: Ian Barwick Backpatch-through: 9.6
* MSVC: Reconcile clean.bat with PostgreSQL 12 work.Noah Misch2019-06-09
|
* Reconcile nodes/*funcs.c with PostgreSQL 12 work.Noah Misch2019-06-09
| | | | | | One would have needed out-of-tree code to observe the defects. Remove unreferenced fields instead of completing their support functions. Since in-tree code can't reach _readIntoClause(), no catversion bump.
* Switch position of some declarations in libpq.hMichael Paquier2019-06-09
| | | | | | | | This makes the header more consistent with the surroundings, with declarations associated to a given file grouped together. Author: Daniel Gustafsson Discussion: https://postgr.es/m/20190608012439.GB7228@paquier.xyz
* Fix some typosMichael Paquier2019-06-09
| | | | | Author: Guillaume Lelarge Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com
* Update documentation about SIGKILL of postmaster.Noah Misch2019-06-08
| | | | | | | | | Removing shared memory and semaphores in response to server start failure often masks the real problem, a live process associated with the data directory; see commit 5a907404b52753c4d6c6a7c21765aeaa42fd6a3b. Since 9.6, it's rarely necessary to kill subprocesses manually. (When it is necessary, that commit's HINT will say as much, in all supported versions.)
* Stop using spelling "nonexistant".Noah Misch2019-06-08
| | | | | The documentation used "nonexistent" exclusively, and the source tree used it three times as often as "nonexistant".
* Update stale comments, and fix comment typos.Noah Misch2019-06-08
|
* Fix assorted inconsistencies.Amit Kapila2019-06-08
| | | | | | | | | | There were a number of issues in the recent commits which include typos, code and comments mismatch, leftover function declarations. Fix them. Reported-by: Alexander Lakhin Author: Alexander Lakhin, Amit Kapila and Amit Langote Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/ef0c0232-0c1d-3a35-63d4-0ebd06e31387@gmail.com
* Move be-gssapi-common.h into src/include/libpq/Michael Paquier2019-06-08
| | | | | | | | | | | The file has been introduced in src/backend/libpq/ as of b0b39f72, but all backend-side headers of libpq are located in src/include/libpq/. Note that the identification path on top of the file referred to src/include/libpq/ from the start. Author: Michael Paquier Reviewed-by: Stephen Frost Discussion: https://postgr.es/m/20190607043415.GE1736@paquier.xyz
* Improve some comments in pg_checksums about the needed clean shutdownMichael Paquier2019-06-07
| | | | | | | | It was not clear from the code why it is necessary. And we need a clean shutdown to avoid random checksum failures caused by torn pages. Author: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoDum5MbAb7F=pa9dOD1W2tukuDMPzWT7NjZceNoWB_6Qw@mail.gmail.com
* Fix copy-pasto in freeing memory on error in vacuumlo.Heikki Linnakangas2019-06-07
| | | | | | | | | | | | It's harmless to call PQfreemem() with a NULL argument, so the only consequence was that if allocating 'schema' failed, but allocating 'table' or 'field' succeeded, we would leak a bit of memory. That's highly unlikely to happen, so this is just academical, but let's get it right. Per bug #15838 from Timur Birsh. Backpatch back to 9.5, where the PQfreemem() calls were introduced. Discussion: https://www.postgresql.org/message-id/15838-3221652c72c5e69d@postgresql.org
* Fix default_tablespace usage for partitioned tablesAlvaro Herrera2019-06-07
| | | | | | | | | | | In commit 87259588d0ab I (Álvaro) tried to rationalize the determination of tablespace to use for partitioned tables, but failed to handle the default_tablespace case. Repair and add proper tests. Author: Amit Langote, Rushabh Lathia Reported-by: Rushabh Lathia Reviewed-by: Amit Langote, Álvaro Herrera Discussion: https://postgr.es/m/CAGPqQf0cYjm1=rjxk_6gU0SjUS70=yFUAdCJLwWzh9bhNJnyVg@mail.gmail.com
* Fix inconsistency in comments atop ExecParallelEstimate.Amit Kapila2019-06-07
| | | | | | | | | | | | | When this code was initially introduced in commit d1b7c1ff, the structure used was SharedPlanStateInstrumentation, but later when it got changed to Instrumentation structure in commit b287df70, we forgot to update the comment. Reported-by: Wu Fei Author: Wu Fei Reviewed-by: Amit Kapila Backpatch-through: 9.6 Discussion: https://postgr.es/m/52E6E0843B9D774C8C73D6CF64402F0562215EB2@G08CNEXMBPEKD02.g08.fujitsu.local
* Fix message styleAlvaro Herrera2019-06-06
| | | | | | | Mark one message not for translation, and prefer "cannot" over "may not", per commentary from Robert Haas. Discussion: https://postgr.es/m/20190430145813.GA29872@alvherre.pgsql
* Add forgotten translatable string in pg_checksums.cMichael Paquier2019-06-06
| | | | | | | Oversight in commit 280e5f1. Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20190606.200612.110313249.horikyota.ntt@gmail.com
* pg_waldump: Fix invalid option handlingPeter Eisentraut2019-06-06
| | | | | | | | | | | Previously, running pg_waldump with an invalid option (pg_waldump --foo) would print the help output and exit successfully. This was because it tried to process the option letter '?' as a normal option, but that letter is used by getopt() to report an invalid option. To fix, process help and version options separately, like we do everywhere else. Also add a basic test suite for pg_waldump and run the basic option handling tests, which would have caught this.
* Fix confusion on different kinds of slots in IndexOnlyScans.Heikki Linnakangas2019-06-06
| | | | | | | | | | We used the same slot to store a tuple from the index, and to store a tuple from the table. That's not OK. It worked with the heap, because heapam_getnextslot() stores a HeapTuple to the slot, and doesn't care how large the tts_values/nulls arrays are. But when I played with a toy table AM implementation that used a virtual tuple, it caused memory overruns. In the passing, tidy up comments on the ioss_PscanLen fields.
* Docs: concurrent builds of partitioned indexes are not supportedDavid Rowley2019-06-06
| | | | | | | | Document that CREATE INDEX CONCURRENTLY is not currently supported for indexes on partitioned tables. Discussion: https://postgr.es/m/CAKJS1f_CErd2z9L21Q8OGLD4TgH7yw1z9MAtHTSO13sXVG-yow@mail.gmail.com Backpatch-through: 11
* doc: Add links to tablesPeter Eisentraut2019-06-05
| | | | | Formal tables should generally have an xref in the text that points to them. Add them here.
* Fix confusing NOTICE text in REINDEX CONCURRENTLYDavid Rowley2019-06-05
| | | | | | | | | | | | | | | When performing REINDEX TABLE CONCURRENTLY, if all of the table's indexes could not be reindexed, a NOTICE message claimed that the table had no indexes. This was confusing, so let's change the NOTICE text to something less confusing. In passing, also mention in the comment before ReindexRelationConcurrently that materialized views are supported too and also explain what the return value of the function means. Author: Ashwin Agrawal Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CALfoeithHvi13p_VyR8kt9o6Pa7Z=Smi6Nfc2anHnQx5Lj8bTQ@mail.gmail.com
* Fix incorrect index behavior in COPY FROM with partitioned tablesDavid Rowley2019-06-05
| | | | | | | | | | | | | | | | 86b85044e rewrote how COPY FROM works to allow multiple tuple buffers to exist to once thus allowing multi-inserts to be used in more cases with partitioned tables. That commit neglected to update the estate's es_result_relation_info when flushing the insert buffer to the partition making it possible for the index tuples to be added into an index on the wrong partition. Fix this and also add an Assert in ExecInsertIndexTuples to help ensure that we never make this mistake again. Reported-by: Haruka Takatsuka Author: Ashutosh Sharma Discussion: https://postgr.es/m/15832-b1bf336a4ee246b5@postgresql.org
* Rework code using list_delete_cell() in MergeAttributesMichael Paquier2019-06-05
| | | | | | | | | | | | | | | When merging two attributes, we are sure that at least one remains. However, when deleting one element in the attribute list we may finish with an empty list returned as NIL by list_delete_cell(), but the code failed to track that, which is not project-like. Adjust the call so as we check for an empty list, and make use of it in an assertion. This has been introduced by e7b3349, when adding support for CREATE TABLE OF. Author: Mark Dilger Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/CAE-h2TpPDqSWgOvfvSziOaMngMPwW+QZcmPpY8hQ_KOJ2+3hXQ@mail.gmail.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-08 09:40:01 +0000