aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Use wildcard to match parens after CREATE STATISTICSTomas Vondra2018-11-28
| | | | | | | | | | | CREATE STATISTICS completion was checking manually for the start and end of the parenthesised list of types. That works, but we now have a better way to do that as commit 121213d9d taught word_matches() to allow '*' in the middle of an alternative. But it only applied that to tab completion for EXPLAIN, ANALYZE and VACUUM. Use it for CREATE STATISTICS too. Author: Dagfinn Ilmari Mannsåker Discussion: https://www.postgresql.org/message-id/flat/d8jwooziy1s.fsf%40dalvik.ping.uio.no
* Don't count zero-filled buffers as 'read' in EXPLAIN.Thomas Munro2018-11-28
| | | | | | | | | | | | | If you extend a relation, it should count as a block written, not read (we write a zero-filled block). If you ask for a zero-filled buffer, it shouldn't be counted as read or written. Later we might consider counting zero-filled buffers with a separate counter, if they become more common due to future work. Author: Thomas Munro Reviewed-by: Haribabu Kommi, Kyotaro Horiguchi, David Rowley Discussion: https://postgr.es/m/CAEepm%3D3JytB3KPpvSwXzkY%2Bdwc5zC8P8Lk7Nedkoci81_0E9rA%40mail.gmail.com
* Ensure consistent sort order of large objects in pg_dump.Andres Freund2018-11-27
| | | | | | | | | | | | | | | | | | | | | | | | | The primary purpose of this commit is to ensure pg_upgrade tests yield comparable dumps pre/post upgrade, which got broken by 12a53c732 / 578b229718, as the order in pg_largeobject_metadata is likely to differ pre/post upgrade. It also seems like a generally good idea to make sure such dumps are comparable, outside of pg_upgrade tests. LO metadata already was already dumped in an ordered manner as the metadata is dumped in a well defined order via sortDumpableObjectsByTypeName() and sortDumpableObjects(). But large object data is currently not tracked via that mechanism. As Tom points out it seems possible that at some point dumpBlobs() was assumed to dump out objects in a well defined order, due to the use of DISTINCT, which at that time only was done using sorting. Per complaint from Andrew Dunstan and discussion with him and Tom Lane. Author: Andres Freund Discussion: https://postgr.es/m/2735.1543333649@sss.pgh.pa.us
* Fix jit compilation bug on wide tables.Andres Freund2018-11-27
| | | | | | | | | | | | | | | | | | | | The function generated to perform JIT compiled tuple deforming failed when HeapTupleHeader's t_hoff was bigger than a signed int8. I'd failed to realize that LLVM's getelementptr would treat an int8 index argument as signed, rather than unsigned. That means that a hoff larger than 127 would result in a negative offset being applied. Fix that by widening the index to 32bit. Add a testcase with a wide table. Don't drop it, as it seems useful to verify other tools deal properly with wide tables. Thanks to Justin Pryzby for both reporting a bug and then reducing it to a reproducible testcase! Reported-By: Justin Pryzby Author: Andres Freund Discussion: https://postgr.es/m/20181115223959.GB10913@telsasoft.com Backpatch: 11, just as jit compilation was
* Update ssl test certificates and keysPeter Eisentraut2018-11-27
| | | | | | | | | | | | | | | Debian testing and newer now require that RSA and DHE keys are at least 2048 bit long and no longer allow SHA-1 for signatures in certificates. This is currently causing the ssl tests to fail there because the test certificates and keys have been created in violation of those conditions. Update the parameters to create the test files and create a new set of test files. Author: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> Reported-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/20180917131340.GE31460%40paquier.xyz
* Fix ac218aa4f6 to work on versions before 9.5.Andres Freund2018-11-26
| | | | | | | | | | | | Unfortunately ac218aa4f6 missed the fact that a reference to 'pg_catalog.regnamespace'::regclass wouldn't work before that type is known. Fix that, by replacing the regtype usage with a join to pg_type. Reported-By: Tom Lane Author: Andres Freund Discussion: https://postgr.es/m/8863.1543297423@sss.pgh.pa.us Backpatch: 9.5-, like ac218aa4f6
* Update pg_upgrade test for reg* to include regrole and regnamespace.Andres Freund2018-11-26
| | | | | | | | | | | | | | | | | When the regrole (0c90f6769) and regnamespace (cb9fa802b) types were added in 9.5, pg_upgrade's check for reg* types wasn't updated. While regrole currently is safe, regnamespace is not. It seems unlikely that anybody uses regnamespace inside catalog tables across a pg_upgrade, but the tests should be correct nevertheless. While at it, reorder the types checked in the query to be alphabetical. Otherwise it's annoying to compare existing and tested for types. Author: Andres Freund Discussion: https://postgr.es/m/037e152a-cb25-3bcb-4f35-bdc9988f8204@2ndQuadrant.com Backpatch: 9.5-, as regrole/regnamespace
* doc: fix wording for plpgsql, add "and"Bruce Momjian2018-11-26
| | | | | | | | Reported-by: Anthony Greene Discussion: https://postgr.es/m/CAPRNmnsSZ4QL75FUjcS8ND_oV+WjgyPbZ4ch2RUwmW6PWzF38w@mail.gmail.com Backpatch-through: 9.4
* Fix typo introduced in 578b229718.Andres Freund2018-11-26
| | | | | Author: Andreas Karlsson Discussion: https://postgr.es/m/0917c86f-e906-27c0-740e-abc581480823@proxel.se
* Fix pg_upgrade for oid removal.Andres Freund2018-11-26
| | | | | | | | | | | | | | | | | | | | | | | pg_upgrade previously copied pg_largeobject_metadata over from the old cluster. That doesn't work, because the table has oids before 578b229718. I missed that. As most pieces of metadata for large objects already were dumped as DDL (except for comments overwritten by pg_upgrade, due to the copy of pg_largeobject_metadata) it seems reasonable to just also dump grants for large objects. If we ever consider this a relevant performance problem, we'd need to fix the rest of the already emitted DDL too. There's still an open discussion about whether we'll want to force a specific ordering for the dumped objects, as currently pg_largeobjects_metadata potentially has a different ordering before/after pg_upgrade, which can make automated testing a bit harder. Reported-By: Andrew Dunstan Author: Andres Freund Discussion: https://postgr.es/m/91a8a980-41bc-412b-fba2-2ba71a141c2b@2ndQuadrant.com
* Fix translation of special characters in psql's LaTeX output modes.Tom Lane2018-11-26
| | | | | | | | | | | | | | | latex_escaped_print() mistranslated \ and failed to provide any translation for # ^ and ~, all of which would typically lead to LaTeX document syntax errors. In addition it didn't translate < > and |, which would typically render as unexpected characters. To some extent this represents shortcomings in ancient versions of LaTeX, which if memory serves had no easy way to render these control characters as ASCII text. But that's been fixed for, um, decades. In any case there is no value in emitting guaranteed-to-fail output for these characters. Noted while fooling with test cases added by commit 9a98984f4. Back-patch the code change to all supported versions.
* Avoid locale-dependent output in numericlocale check.Tom Lane2018-11-26
| | | | | | | | | I'd forgotten that in the buildfarm, parts of the regression tests may run with psql exposed to a non-default LC_NUMERIC setting. Hence we can't assume that C locale prevails, nor is there any accessible way to force the setting for this single test step. Lobotomize the test case added by commit 9a98984f4 so that it covers as much as we can of print.c without having any locale-varying output.
* Fix sample output for hash_metapage_info queryAlvaro Herrera2018-11-26
| | | | | | | One output column was duplicated. Couldn't resist fixing the version number while at it. Reported-by: Gianni Ciolli
* Add CSV table output mode in psql.Tom Lane2018-11-26
| | | | | | | | | | | | | | | | | | "\pset format csv", or --csv, selects comma-separated values table format. This is compliant with RFC 4180, except that we aren't too picky about whether the record separator is LF or CRLF; also, the user may choose a field separator other than comma. This output format is directly compatible with the server's COPY CSV format, and will also be useful as input to other programs. It's considerably safer for that purpose than the old recommendation to use "unaligned" format, since the latter couldn't handle data containing the field separator character. Daniel Vérité, reviewed by Fabien Coelho and David Fetter, some tweaking by me Discussion: https://postgr.es/m/a8de371e-006f-4f92-ab72-2bbe3ee78f03@manitou-mail.org
* Improve regression test coverage for psql output formats.Tom Lane2018-11-26
| | | | | | | | | | | | As penance for the "\pset format latex" silliness, add some regression test coverage for the off-the-beaten-path output formats, which formerly had exactly no coverage, except for some poorly-thought-out (unreadable, repetitive, and incomplete) tests for asciidoc format. I make no claims for the behavior exposed here actually being correct; these test cases are just designed to ensure full code coverage in fe_utils/print.c. This brings the line coverage for that file up from ~60% to ~93%.
* Fix breakage of "\pset format latex".Tom Lane2018-11-26
| | | | | | | | | | | | | | | Commit eaf746a5b unintentionally made psql's "latex" output format inaccessible, since not only "latex" but all abbreviations of it were considered ambiguous against "latex-longtable". Let's go back to the longstanding behavior that all shortened versions mean "latex", and you have to write at least "latex-" to get "latex-longtable". This leaves the only difference from pre-v12 behavior being that "\pset format a" is considered ambiguous. The fact that the regression tests didn't expose this is pretty bad, but fixing it is material for a separate commit. Discussion: https://postgr.es/m/cb7e1caf-3ea6-450d-af28-f524903a030c@manitou-mail.org
* Clarify that cross-row constraints are unsupportedAlvaro Herrera2018-11-26
| | | | | | | | | Maybe we'll implement them later, or maybe not, but let's make the statu quo clear for now. Author: Lætitia Avrot, Patrick Francelle Reviewers: too many to list Discussion: https://postgr.es/m/CAB_COdhUuzNFOJfc7SNNso5rOuVA3ui93KMVunEM8Yih+K5A6A@mail.gmail.com
* Revert "Fix typo in documentation of toast storage"Michael Paquier2018-11-26
| | | | | This reverts commit 058ef3a, per complains from Magnus Hagander and Vik Fearing.
* Fix typo in documentation of toast storageMichael Paquier2018-11-26
| | | | | Author: Nawaz Ahmed Discussion: https://postgr.es/m/154319327168.1315.1846953598601966513@wrigleys.postgresql.org
* Revert all new recent changes to add PGXS options for TAP and isolationMichael Paquier2018-11-26
| | | | | | | | | | | | A set of failures in buildfarm machines are proving that this is not quite ready yet because of another set of issues: - MSVC scripts assume that REGRESS_OPTS can only use top_builddir. Some test suites actually finish by using top_srcdir, like pg_stat_statements which cause the regression tests to never run. - Trying to enforce top_builddir does not work either when using VPATH as this is not recognized properly. - TAP tests of bloom are unstable on various platforms, causing various failures.
* Fix regression test handling of test_decoding with MSVCMichael Paquier2018-11-26
| | | | | | | | | | | The set of scripts in charge of running the regression tests for MSVC run currently under the assumption that only $(top_builddir) can used in option values defined in REGRESS_OPTS, and those options need to have a specific format as well to be correctly parsed, so fix the Makefile values so as those are correctly set. Per complains from buildfarm member dory and whelk, with some extra testing done on my side with MSVC to check this patch.
* Disable temporarily TAP tests for contrib/bloom/Michael Paquier2018-11-26
| | | | | | | | | The recent commit 03faa4a8 has enabled those tests, however several buildfarm members are complaining about their stability on Windows and macOS. This will keep the buildfarm green, while investigating the root problem. Discussion: https://postgr.es/m/20181126003351.GE1776@paquier.xyz
* Add PGXS options to control TAP and isolation testsMichael Paquier2018-11-26
| | | | | | | | | | | | | | | | | | | | | The following options are added for extensions: - TAP_TESTS, to allow an extention to run TAP tests which are the ones present in t/*.pl. A subset of tests can always be run with the existing PROVE_TESTS for developers. - ISOLATION, to define a list of isolation tests. - ISOLATION_OPTS, to pass custom options to isolation_tester. A couple of custom Makefile targets have been accumulated across the tree to cover the lack of facility in PGXS for a couple of releases when using those test suites, which are all now replaced with the new flags, without reducing the test coverage. This also fixes an issue with contrib/bloom/, which had a custom target to trigger its TAP tests of its own not part of the main check runs. Author: Michael Paquier Reviewed-by: Adam Berlin, Álvaro Herrera, Tom Lane, Nikolay Shaplov, Arthur Zakirov Discussion: https://postgr.es/m/20180906014849.GG2726@paquier.xyz
* Integrate recovery.conf into postgresql.confPeter Eisentraut2018-11-25
| | | | | | | | | | | | | | | | | | | | | | | | | recovery.conf settings are now set in postgresql.conf (or other GUC sources). Currently, all the affected settings are PGC_POSTMASTER; this could be refined in the future case by case. Recovery is now initiated by a file recovery.signal. Standby mode is initiated by a file standby.signal. The standby_mode setting is gone. If a recovery.conf file is found, an error is issued. The trigger_file setting has been renamed to promote_trigger_file as part of the move. The documentation chapter "Recovery Configuration" has been integrated into "Server Configuration". pg_basebackup -R now appends settings to postgresql.auto.conf and creates a standby.signal file. Author: Fujii Masao <masao.fujii@gmail.com> Author: Simon Riggs <simon@2ndquadrant.com> Author: Abhijit Menon-Sen <ams@2ndquadrant.com> Author: Sergei Kornilov <sk@zsrv.org> Discussion: https://www.postgresql.org/message-id/flat/607741529606767@web3g.yandex.ru/
* Fix assertion failure for SSL connections.Thomas Munro2018-11-25
| | | | | | | | | | Commit cfdf4dc4 added an assertion that every WaitLatch() or similar handles postmaster death. One place did not, but was missed in review and testing due to the need for an SSL connection. Fix, by asking for WL_EXIT_ON_PM_DEATH. Reported-by: Christoph Berg Discussion: https://postgr.es/m/20181124143845.GA15039%40msg.df7cb.de
* Fix hstore hash function for empty hstores upgraded from 8.4.Andrew Gierth2018-11-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hstore data generated on pg 8.4 and pg_upgraded to current versions remains in its original on-disk format unless modified. The same goes for values generated by the addon hstore-new module on pre-9.0 versions. (The hstoreUpgrade function converts old values on the fly when read in, but the on-disk value is not modified by this.) Since old-format empty hstores (and hstore-new hstores) have representations compatible with the new format, hstoreUpgrade thought it could get away without modifying such values; but this breaks hstore_hash (and the new hstore_hash_extended) which assumes bit-perfect matching between semantically identical hstore values. Only one bit actually differs (the "new version" flag in the count field) but that of course is enough to break the hash. Fix by making hstoreUpgrade unconditionally convert all old values to new format. Backpatch all the way, even though this changes a hash value in some cases, because in those cases the hash value is already failing - for example, a hash join between old- and new-format empty hstores will be failing to match, or a hash index on an hstore column containing an old-format empty value will be failing to find the value since it will be searching for a hash derived from a new-format datum. (There are no known field reports of this happening, probably because hashing of hstores has only been useful in limited circumstances and there probably isn't much upgraded data being used this way.) Per concerns arising from discussion of commit eb6f29141be. Original bug is my fault. Discussion: https://postgr.es/m/60b1fd3b-7332-40f0-7e7f-f2f04f777747%402ndquadrant.com
* Avoid crashes in contrib/intarray gist__int_ops (bug #15518)Andrew Gierth2018-11-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Integer overflow in internal_size could result in memory corruption in decompression since a zero-length array would be allocated and then written to. This leads to crashes or corruption when traversing an index which has been populated with sufficiently sparse values. Fix by using int64 for computations and checking for overflow. 2. Integer overflow in g_int_compress could cause pessimal merge choices, resulting in unnecessarily large ranges (which would in turn trigger issue 1 above). Fix by using int64 again. 3. Even without overflow, array sizes could become large enough to cause unexplained memory allocation errors. Fix by capping the sizes to a safe limit and report actual errors pointing at gist__intbig_ops as needed. 4. Large inputs to the compression function always consist of large runs of consecutive integers, and the compression loop was processing these one at a time in an O(N^2) manner with a lot of overhead. The expected runtime of this function could easily exceed 6 months for a single call as a result. Fix by performing a linear-time first pass, which reduces the worst case to something on the order of seconds. Backpatch all the way, since this has been wrong forever. Per bug #15518 from report from irc user "dymk", analysis and patch by me. Discussion: https://postgr.es/m/15518-799e426c3b4f8358@postgresql.org
* Adjust new test case for more portability.Tom Lane2018-11-23
| | | | | | | | | | | | | | | | | Early returns from the buildfarm say that most critters are good with commit cbdb8b4c0, but gaur gives unexpected results with the test case involving a float8 that's one-ULP-less-than-2^63. It appears that that platform's version of rint() rounds that value up to 2^63 instead of leaving it be. This is possibly a bug, and it's also possible that no other platform anybody is using anywhere behaves likewise. Still, the point of the test is not to insist that everybody's rint() behaves exactly the same. Let's use two-ULPs-less-than-2^63 instead, which I've tested to act the same on gaur as on more modern hardware. (This is, more or less, exactly the portability issue I'd feared might arise...) Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
* Fix float-to-integer coercions to handle edge cases correctly.Tom Lane2018-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | ftoi4 and its sibling coercion functions did their overflow checks in a way that looked superficially plausible, but actually depended on an assumption that the MIN and MAX comparison constants can be represented exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8, and dtoi8, resulting in a possibility that values near the MAX limit will be wrongly converted (to negative values) when they need to be rejected. Also, because we compared before rounding off the fractional part, the other three functions threw errors for values that really ought to get rounded to the min or max integer value. Fix by doing rint() first (requiring an assumption that it handles NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already), and by comparing to values that should coerce to float exactly, namely INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies between these six functions. Per bug #15519 from Victor Petrovykh. This should get back-patched, but first let's see what the buildfarm thinks of it --- I'm not too sure about portability of some of the regression test cases. Patch by me; thanks to Andrew Gierth for analysis and discussion. Discussion: https://postgr.es/m/15519-4fc785b483201ff1@postgresql.org
* Add a 64-bit hash function for type hstore.Tom Lane2018-11-23
| | | | | | | | | There's some question about the correctness of the hash function, but if it's wrong, the 32-bit version is also wrong. Amul Sul, reviewed by Hironobu Suzuki Discussion: https://postgr.es/m/CAAJ_b947JjnNr9Cp45iNjSqKf6PA5mCTmKsRwPjows93YwQrmw@mail.gmail.com
* Add a 64-bit hash function for type citext.Tom Lane2018-11-23
| | | | | | Amul Sul, reviewed by Hironobu Suzuki Discussion: https://postgr.es/m/CAAJ_b947JjnNr9Cp45iNjSqKf6PA5mCTmKsRwPjows93YwQrmw@mail.gmail.com
* Clamp semijoin selectivity to be not more than inner-join selectivity.Tom Lane2018-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should never estimate the output of a semijoin to be more rows than we estimate for an inner join with the same input rels and join condition; it's obviously impossible for that to happen. However, given the relatively poor quality of our semijoin selectivity estimates --- particularly, but not only, in cases where we punt and return a default estimate --- we did often deliver such estimates. To improve matters, calculate both estimates inside eqjoinsel() and take the smaller one. The bulk of this patch is just mechanical refactoring to avoid repetitive information lookup when we call both eqjoinsel_semi and eqjoinsel_inner. The actual new behavior is just selec = Min(selec, inner_rel->rows * selec_inner); which looks a bit odd but is correct because of our different definitions for inner and semi join selectivity. There is one ensuing plan change in the regression tests, but it looks reasonable enough (and checking the actual row counts shows that the estimate moved closer to reality, not further away). Per bug #15160 from Alexey Ermakov. Although this is arguably a bug fix, I won't risk destabilizing plan choices in stable branches by back-patching. Tom Lane, reviewed by Melanie Plageman Discussion: https://postgr.es/m/152395805004.19366.3107109716821067806@wrigleys.postgresql.org
* Silence compiler warningsAlvaro Herrera2018-11-23
| | | | | | | Commit cfdf4dc4fc96 left a few unnecessary assignments, one of which caused compiler warnings, as reported by Erik Rijkers. Remove them all. Discussion: https://postgr.es/m/df0dcca2025b3d90d946ecc508ca9678@xs4all.nl
* Remove bogus file.Tom Lane2018-11-23
|
* Don't allow partitioned indexes in pg_global tablespaceAlvaro Herrera2018-11-23
| | | | | | | Missing in dfa608141982. Author: David Rowley Discussion: https://postgr.es/m/CAKJS1f-M3NMTCpv=vDfkoqHbMPFf=3-Z1ud=+1DHH00tC+zLaQ@mail.gmail.com
* doc: Fix typoPeter Eisentraut2018-11-23
|
* Add WL_EXIT_ON_PM_DEATH pseudo-event.Thomas Munro2018-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users of the WaitEventSet and WaitLatch() APIs can now choose between asking for WL_POSTMASTER_DEATH and then handling it explicitly, or asking for WL_EXIT_ON_PM_DEATH to trigger immediate exit on postmaster death. This reduces code duplication, since almost all callers want the latter. Repair all code that was previously ignoring postmaster death completely, or requesting the event but ignoring it, or requesting the event but then doing an unconditional PostmasterIsAlive() call every time through its event loop (which is an expensive syscall on platforms for which we don't have USE_POSTMASTER_DEATH_SIGNAL support). Assert that callers of WaitLatchXXX() under the postmaster remember to ask for either WL_POSTMASTER_DEATH or WL_EXIT_ON_PM_DEATH, to prevent future bugs. The only process that doesn't handle postmaster death is syslogger. It waits until all backends holding the write end of the syslog pipe (including the postmaster) have closed it by exiting, to be sure to capture any parting messages. By using the WaitEventSet API directly it avoids the new assertion, and as a by-product it may be slightly more efficient on platforms that have epoll(). Author: Thomas Munro Reviewed-by: Kyotaro Horiguchi, Heikki Linnakangas, Tom Lane Discussion: https://postgr.es/m/CAEepm%3D1TCviRykkUb69ppWLr_V697rzd1j3eZsRMmbXvETfqbQ%40mail.gmail.com, https://postgr.es/m/CAEepm=2LqHzizbe7muD7-2yHUbTOoF7Q+qkSD5Q41kuhttRTwA@mail.gmail.com
* Clarify documentation about PASSWORD in CREATE/ALTER ROLEMichael Paquier2018-11-23
| | | | | | | | | | | | | | | The documentation of CREATE/ALTER ROLE has been missing two things related to PASSWORD: - The password value provided needs to be quoted, some places of the documentation marked the field with quotes, but not others, which led to confusion. - PASSWORD NULL was not provided consistently, with ENCRYPTED being not compatible with it. Reported-by: Steven Winfield Author: Michael Paquier Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/154282901979.1316.7418475422120496802@wrigleys.postgresql.org
* Fix another crash in json{b}_populate_recordset and json{b}_to_recordset.Tom Lane2018-11-22
| | | | | | | | | | | | | | | populate_recordset_worker() failed to consider the possibility that the supplied JSON data contains no rows, so that update_cached_tupdesc never got called. This led to a null-pointer dereference since commit 9a5e8ed28; before that it led to a bogus "set-valued function called in context that cannot accept a set" error. Fix by forcing the update to happen. Per bug #15514. Back-patch to v11 as 9a5e8ed28 was. (If we were excited about the bogus error, we could perhaps go back further, but it'd take more work to figure out how to fix it in older branches. Given the lack of field complaints about that aspect, I'm not excited.) Discussion: https://postgr.es/m/15514-59d5b4c4065b178b@postgresql.org
* Doc: rework introductory documentation about covering indexes.Tom Lane2018-11-22
| | | | | | | | | | | | | | | | Documenting INCLUDE in the section about unique indexes is confusing, as complained of by Emilio Platzer. Furthermore, it entirely failed to explain why you might want to use the feature. The section about index-only scans is really the right place; it already talked about making such things the hard way. Rewrite that text to describe INCLUDE as the normal way to make a covering index. Also, move that section up a couple of places, as it now seems more important than some of the stuff we had before it. It still has to be after expression and partial indexes, since otherwise some of it would involve forward references. Discussion: https://postgr.es/m/154031939560.30897.14677735588262722042@wrigleys.postgresql.org
* Fix typo in description of ExecFindPartitionMichael Paquier2018-11-22
| | | | | Author: Amit Langote Discussion: https://postgr.es/m/CA+HiwqHg0=UL+Dhh3gpiwYNA=ufk9Lb7GQ2c=5rs=ZmVTP7xAw@mail.gmail.com
* doc: adjust time zone names text, v2Bruce Momjian2018-11-21
| | | | | | | | | Removed one too many words. Fix for 7906de847f229f391b9e6b5892b4b4a89f29edb4. Reported-by: Thomas Munro Backpatch-through: 9.4
* doc: adjust time zone names textBruce Momjian2018-11-21
| | | | | | | | Reported-by: Kevin <kcolagio@gmail.com> Discussion: https://postgr.es/m/154082462281.30897.14043119084654378035@wrigleys.postgresql.org Backpatch-through: 9.4
* Rework the pgbench state machine code for clarityAlvaro Herrera2018-11-21
| | | | | | | | | | | | | | | | | | | | This commit continues the code improvements started by commit 12788ae49e19. With this commit, state machine transitions are better contained in the routine that was called doCustom() and is now called advanceConnectionState -- the resulting code is easier to reason about, since there are no state changes occuring in the outer layer. This change is prompted by future patches to add more features to pgbench, which will need to effect some more surgery to this code. Fabien's original had all the machine state changes inside one routine, but I (Álvaro) thought that a subroutine to handle command execution is more straightforward to review, so this commit does not match Fabien's submission closely. If something is broken, it's probably my fault. Author: Fabien Coelho, Álvaro Herrera Reviewed-by: Kirk Jamison Discussion: https://postgr.es/m/alpine.DEB.2.21.1808111104320.1705@lancre
* Fix typo in commit 6f7d02aa60b7Alvaro Herrera2018-11-21
| | | | Per pink buildfarm.
* Fix PartitionDispatchData vertical whitespaceAlvaro Herrera2018-11-21
| | | | | Per David Rowley Discussion: https://postgr.es/m/CAKJS1f-MstvBWdkOzACsOHyBgj2oXcBM8kfv+NhVe-Ux-wq9Sg@mail.gmail.com
* instr_time.h: add INSTR_TIME_SET_CURRENT_LAZYAlvaro Herrera2018-11-21
| | | | | | | | Sets the timestamp to current if not already set. Will acquire more callers momentarily. Author: Fabien Coelho Discussion: https://postgr.es/m/alpine.DEB.2.21.1808111104320.1705@lancre
* Blind attempt at fixing sepgsql output for 578b22.Andres Freund2018-11-20
|
* Fix sepgsql compile error caused by oid removal.Andres Freund2018-11-20
| | | | | | | | | | | Per buildfarm animal rhinoceros. I (Andres) missed replacing a few uses of ObjectIdAttributeNumber in sepgsql. It's quite probable that the sepgsql test output will need more adapting than done in 578b22... Author: Thomas Munro Discussion: https://postgr.es/m/CAEepm=2Sk+66HJV8FLDfm_sKTn22j7cWTY_Y1Rok3RxeWL_Y0w@mail.gmail.com
* Remove WITH OIDS support, change oid catalog column visibility.Andres Freund2018-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously tables declared WITH OIDS, including a significant fraction of the catalog tables, stored the oid column not as a normal column, but as part of the tuple header. This special column was not shown by default, which was somewhat odd, as it's often (consider e.g. pg_class.oid) one of the more important parts of a row. Neither pg_dump nor COPY included the contents of the oid column by default. The fact that the oid column was not an ordinary column necessitated a significant amount of special case code to support oid columns. That already was painful for the existing, but upcoming work aiming to make table storage pluggable, would have required expanding and duplicating that "specialness" significantly. WITH OIDS has been deprecated since 2005 (commit ff02d0a05280e0). Remove it. Removing includes: - CREATE TABLE and ALTER TABLE syntax for declaring the table to be WITH OIDS has been removed (WITH (oids[ = true]) will error out) - pg_dump does not support dumping tables declared WITH OIDS and will issue a warning when dumping one (and ignore the oid column). - restoring an pg_dump archive with pg_restore will warn when restoring a table with oid contents (and ignore the oid column) - COPY will refuse to load binary dump that includes oids. - pg_upgrade will error out when encountering tables declared WITH OIDS, they have to be altered to remove the oid column first. - Functionality to access the oid of the last inserted row (like plpgsql's RESULT_OID, spi's SPI_lastoid, ...) has been removed. The syntax for declaring a table WITHOUT OIDS (or WITH (oids = false) for CREATE TABLE) is still supported. While that requires a bit of support code, it seems unnecessary to break applications / dumps that do not use oids, and are explicit about not using them. The biggest user of WITH OID columns was postgres' catalog. This commit changes all 'magic' oid columns to be columns that are normally declared and stored. To reduce unnecessary query breakage all the newly added columns are still named 'oid', even if a table's column naming scheme would indicate 'reloid' or such. This obviously requires adapting a lot code, mostly replacing oid access via HeapTupleGetOid() with access to the underlying Form_pg_*->oid column. The bootstrap process now assigns oids for all oid columns in genbki.pl that do not have an explicit value (starting at the largest oid previously used), only oids assigned later by oids will be above FirstBootstrapObjectId. As the oid column now is a normal column the special bootstrap syntax for oids has been removed. Oids are not automatically assigned during insertion anymore, all backend code explicitly assigns oids with GetNewOidWithIndex(). For the rare case that insertions into the catalog via SQL are called for the new pg_nextoid() function can be used (which only works on catalog tables). The fact that oid columns on system tables are now normal columns means that they will be included in the set of columns expanded by * (i.e. SELECT * FROM pg_class will now include the table's oid, previously it did not). It'd not technically be hard to hide oid column by default, but that'd mean confusing behavior would either have to be carried forward forever, or it'd cause breakage down the line. While it's not unlikely that further adjustments are needed, the scope/invasiveness of the patch makes it worthwhile to get merge this now. It's painful to maintain externally, too complicated to commit after the code code freeze, and a dependency of a number of other patches. Catversion bump, for obvious reasons. Author: Andres Freund, with contributions by John Naylor Discussion: https://postgr.es/m/20180930034810.ywp2c7awz7opzcfr@alap3.anarazel.de
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-02 23:42:47 +0000