- 24 Feb, 2019 2 commits
-
-
Thomas Munro authored
Previously, we tolerated EBADF as a way for the operating system to indicate that it doesn't support fsync() on a directory. Tolerate EINVAL too, for older versions of Linux CIFS. Bug #15636. Back-patch all the way. Reported-by: John Klann Discussion: https://postgr.es/m/15636-d380890dafd78fc6@postgresql.org
-
Thomas Munro authored
One unintended consequence of commit 9ccdd7f6 was that Windows WSL users started getting a panic whenever we tried to initiate data flushing with sync_file_range(), because WSL does not implement that system call. Previously, they got a stream of periodic warnings, which was also undesirable but at least ignorable. Prevent the panic by handling ENOSYS specially and skipping the panic promotion with data_sync_elevel(). Also suppress future attempts after the first such failure so that the pre-existing problem of noisy warnings is improved. Back-patch to 9.6 (older branches were not affected in this way by 9ccdd7f6). Author: Thomas Munro and James Sewell Tested-by: James Sewell Reported-by: Bruce Klein Discussion: https://postgr.es/m/CA+mCpegfOUph2U4ZADtQT16dfbkjjYNJL1bSTWErsazaFjQW9A@mail.gmail.com
-
- 23 Feb, 2019 1 commit
-
-
Peter Eisentraut authored
This reverts commit 1995552d. Several developers didn't like the new behavior.
-
- 22 Feb, 2019 6 commits
-
-
Michael Paquier authored
The header block of TwoPhaseGetDummyBackendId mentioned incorrectly TwoPhaseGetDummyProc. Reported-by: Oleksii Kliukin Discussion: https://postgr.es/m/D8336E40-BBE1-4954-98BB-7830D3F5CB36@hintbits.com
-
Michael Paquier authored
The current set of TAP tests for two-phase transactions include some coverage for post-commit callbacks of multixact, but it lacked tests for testing the recovery of those callbacks. This commit adds some tests with soft and hard restarts in this case, using transactions which include DDLs. Author: Michael Paquier Reviewed-by: Oleksii Kliukin Discussion: https://postgr.es/m/20190221055431.GO15532@paquier.xyz
-
Tom Lane authored
In the case where inheritance_planner() finds that every table has been excluded by constraints, it thought it could get away with making a plan consisting of just a dummy Result node. While certainly there's no updating or deleting to be done, this had two user-visible problems: the plan did not report the correct set of output columns when a RETURNING clause was present, and if there were any statement-level triggers that should be fired, it didn't fire them. Hence, rather than only generating the dummy Result, we need to stick a valid ModifyTable node on top, which requires a tad more effort here. It's been broken this way for as long as inheritance_planner() has known about deleting excluded subplans at all (cf commit 635d42e9), so back-patch to all supported branches. Amit Langote and Tom Lane, per a report from Petr Fedorov. Discussion: https://postgr.es/m/5da6f0f0-1364-1876-6978-907678f89a3e@phystech.edu
-
Alvaro Herrera authored
We were reporting the database name instead of the relation name to pg_stat_activity. Repair. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20190220185552.GR28750@telsasoft.com
-
Peter Eisentraut authored
New code introduced in 050710b3. The lack of const is not currently a compiler warning, but it's nice to have for consistency with surrounding code.
-
Michael Paquier authored
The same variables are declared twice when checking if a connection is writable, which is useless. Author: Haribabu Kommi Discussion: https://postgr.es/m/CAJrrPGf=rcALB54w_Tg1_hx3y+cgSWaERY-uYSQzGc3Zt5XN4g@mail.gmail.com
-
- 21 Feb, 2019 9 commits
-
-
Tom Lane authored
There isn't any good reason for this test to be a self-join rather than a join between separate tables, except that it saved a couple of SQL commands for setup. A proposed patch to optimize away self-joins breaks the test, so adjust it to avoid that happening. Discussion: https://postgr.es/m/64486b0b-0404-e39e-322d-0801154901f3@postgrespro.ru
-
Tom Lane authored
It seems to make more sense for this to be in selfuncs.c, since it's largely a statistical-estimation thing, and it's related to other functions like estimate_hash_bucket_stats that are there. While at it, change the result type from Size to double. Perhaps at one point it was impossible for the result to overflow an integer, but I've got no confidence in that proposition anymore. Nothing's actually done with the result except to compare it to a work_mem-based limit, so as long as we don't get an overflow on the way to that comparison, things should be fine even with very large dNumGroups. Code movement proposed by Antonin Houska, type change by me Discussion: https://postgr.es/m/25767.1549359615@localhost
-
Peter Eisentraut authored
Change pg_stat_ssl so that an unprivileged user can only see their own rows; other rows will be all null. This makes the behavior consistent with pg_stat_activity, where information about where the connection came from is also restricted. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/63117976-d02c-c8e2-3aef-caa31a5ab8d3%402ndquadrant.com
-
Peter Eisentraut authored
Add a basic note that some columns in pg_stat_activity and related views are not visible to all users. Discussion: https://www.postgresql.org/message-id/3018acd9-e5d8-1e85-5ed7-47276cd77569%402ndquadrant.com
-
Peter Eisentraut authored
Don't expand inputfile and outputfile to absolute paths globally, just where needed. In particular, pass them as is to the file name arguments of the diff command, so that we don't see the full absolute path in the diff header, which makes the diff unnecessarily verbose and harder to read. Discussion: https://www.postgresql.org/message-id/0cc82900-c457-1cee-3ab2-7b0f5d215061@2ndquadrant.com
-
Robert Haas authored
This is similar in spirit to the existing partbounds.c file in the same directory, except that there's a lot less code in the new file created by this commit. Pending work in this area proposes to add a bunch more code related to PartitionDescs, though, and this will give us a good place to put it. Discussion: http://postgr.es/m/CA+TgmoZUwPf_uanjF==gTGBMJrn8uCq52XYvAEorNkLrUdoawg@mail.gmail.com
-
Robert Haas authored
Instead of locking all partitions to which we might route a tuple at executor startup, just lock them as we use them. In some cases such a partition might get locked at executor startup anyway because it appears in the query's range table for some other reason, but in other cases this is a bit savings. This changes the order in which partitions are locked in some cases, which might conceivably create deadlock hazards that don't exist today, but per discussion, it seems like such cases should be rare enough that we can neglect them in favor of improving performance. David Rowley, reviewed and tested by Tomas Vondra, Sho Kato, John Naylor, Tom Lane, and me. Discussion: http://postgr.es/m/CAKJS1f-=FnMqmQP6qitkD+xEddxw22ySLP-0xFk3JAqUX2yfMw@mail.gmail.com
-
Peter Eisentraut authored
In previous releases, the input file of dbtoepub was postgres.xml, and dbtoepub knows to derive the output file name postgres.epub from that automatically. But now the intput file is postgres.sgml (since postgres.sgml is itself an XML file and we no longer need the intermediate postgres.xml file), but dbtoepub doesn't know how to deal with the .sgml suffix, so the automatically derived output file name becomes postgres.sgml.epub. Fix by adding an explicit -o option.
-
Tom Lane authored
Check ec_relids before bothering to iterate through the EC members. On a perhaps extreme, but still real-world, query in which match_eclasses_to_foreign_key_col() accounts for the bulk of the planner's runtime, this saves nearly 40% of the runtime. It's a bit of a stopgap fix, but it's simple enough to be back-patched to 9.6 where this code came in; so let's do that. David Rowley Discussion: https://postgr.es/m/6970.1545327857@sss.pgh.pa.us
-
- 20 Feb, 2019 7 commits
-
-
Andrew Gierth authored
On (rare) platforms where sizeof(bool) > 1, we need to use our own bool, but imported c99 code (such as Ryu) may want to use bool values as array subscripts, which elicits warnings if bool is defined as char. Using unsigned char instead should work just as well for our purposes, and avoid such warnings. Per buildfarm members prariedog and locust.
-
Tom Lane authored
PG type coercions are generally strict, ie a NULL input must produce a NULL output (or, in domain cases, possibly an error). The planner's understanding of that was a bit incomplete though, so improve it: * Teach contain_nonstrict_functions() that CoerceViaIO can always be considered strict. Previously it believed that only if the underlying I/O functions were marked strict, which is often but not always true. * Teach clause_is_strict_for() that CoerceViaIO, ArrayCoerceExpr, ConvertRowtypeExpr, CoerceToDomain can all be considered strict. Previously it knew nothing about any of them. The main user-visible impact of this is that IS NOT NULL predicates can be proven to hold from expressions involving casts in more cases than before, allowing partial indexes with such predicates to be used without extra pushups. This reduces the surprise factor for users, who may well be used to ordinary (function-call-based) casts being known to be strict. Per a gripe from Samuel Williams. This doesn't rise to the level of a bug, IMO, so no back-patch. Discussion: https://postgr.es/m/27571.1550617881@sss.pgh.pa.us
-
Tom Lane authored
The recursion in contain_nonstrict_functions_walker() was done wrong, causing the strictness check to be bypassed for a parse node that is the immediate input of an ArrayCoerceExpr node. This could allow, for example, incorrect decisions about whether a strict SQL function can be inlined. I didn't add a regression test, because (a) the bug is so narrow and (b) I couldn't think of a test case that wasn't dependent on a large number of other behaviors, to the point where it would likely soon rot to the point of not testing what it was intended to. I broke this in commit c12d570f, so back-patch to v11. Discussion: https://postgr.es/m/27571.1550617881@sss.pgh.pa.us
-
Alvaro Herrera authored
pg_identify_object_as_address crashes when passed certain tuples from inconsistent system catalogs. Make it more defensive. Author: Álvaro Herrera Reviewed-by: Michaël Paquier Discussion: https://postgr.es/m/20190218202743.GA12392@alvherre.pgsql
-
Amit Kapila authored
In commit b0eaa4c5, we have avoided the creation of FSM for small tables. So the functions that use FSM to compute the free space can return zero for such tables. This was previously also possible for the cases where the vacuum has not been triggered to update FSM. This commit updates the comments in code and documentation to reflect this behavior. Author: John Naylor Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CACPNZCtba-3m1q3A8gxA_vxg=T7gQf7gMbpR4Ciy5LntY-j+0Q@mail.gmail.com
-
Dean Rasheed authored
INSERT ... VALUES for a single VALUES row is implemented differently from a multi-row VALUES list, which causes inconsistent behaviour in the way that DEFAULT items are handled. In particular, when inserting into an auto-updatable view on top of a table with a column default, a DEFAULT item in a single VALUES row gets correctly replaced with the table column's default, but for a multi-row VALUES list it is replaced with NULL. Fix this by allowing rewriteValuesRTE() to leave DEFAULT items in the VALUES list untouched if the target relation is an auto-updatable view and has no column default, deferring DEFAULT-expansion until the query against the base relation is rewritten. For all other types of target relation, including tables and trigger- and rule-updatable views, we must continue to replace DEFAULT items with NULL in the absence of a column default. This is somewhat complicated by the fact that if an auto-updatable view has DO ALSO rules attached, the VALUES lists for the product queries need to be handled differently from the original query, since the product queries need to act like rule-updatable views whereas the original query has auto-updatable view semantics. Back-patch to all supported versions. Reported by Roger Curley (bug #15623). Patch by Amit Langote and me. Discussion: https://postgr.es/m/15623-5d67a46788ec8b7f@postgresql.org
-
Michael Paquier authored
When building an initial slot snapshot, snapshots are marked with historic MVCC snapshots as type with the marker field being set in SnapBuildBuildSnapshot() but not overriden in SnapBuildInitialSnapshot(). Existing callers of SnapBuildBuildSnapshot() do not care about the type of snapshot used, but extensions calling it actually may, as reported. While on it, mark correctly the snapshot type when importing one. This is cosmetic as the field is enforced to 0. Author: Antonin Houska Reviewed-by: Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/23215.1527665193@localhost Backpatch-through: 9.4
-
- 19 Feb, 2019 2 commits
-
-
Peter Eisentraut authored
Reviewed-by: Andres Freund <andres@anarazel.de>
-
- 18 Feb, 2019 10 commits
-
-
Andres Freund authored
I included the duplicated ExecTypeFromTL in 578b2297 "Remove WITH OIDS support". Reported-By: Peter Eisentraut Discussion: https://postgr.es/m/ba819888-63c6-7f98-6acb-3731142d9414@2ndquadrant.com
-
Tom Lane authored
Add more whitespace, per suggestion from Peter Eisentraut. Discussion: https://postgr.es/m/e265e2ae-e92e-5ab9-dc68-60b6cb047b3d@2ndquadrant.com
-
Andrew Dunstan authored
Changes made by commit 02ddd499 mean that dumps made against pre version 12 instances are no longer comparable with those made against version 12 or later instances. This makes cross-version upgrade testing fail in the buildfarm. Experimentation has shown that the error is cured if the dumps are made when extra_float_digits is set to 0. Hence this patch allows for it to be explicitly set rather than relying on pg_dump's builtin default (3 in almost all cases). This feature might have other uses, but should not normally be used. Discussion: https://postgr.es/m/c76f7051-8fd3-ec10-7579-1f8842305b85@2ndQuadrant.com
-
Michael Meskes authored
-
Michael Meskes authored
Author: Higuchi-san ("Higuchi, Daisuke" <higuchi.daisuke@jp.fujitsu.com>)
-
Michael Meskes authored
So far ECPG programs had to treat binary data for bytea column as 'char' type. But this meant converting from/to escaped format with PQunescapeBytea/ PQescapeBytea() and therefore forcing users to add unnecessary code and cost for the conversion in runtime. By adding a dedicated datatype for bytea most of this special handling is no longer needed. Author: Matsumura-san ("Matsumura, Ryo" <matsumura.ryo@jp.fujitsu.com>) Discussion: https://postgr.es/m/flat/03040DFF97E6E54E88D3BFEE5F5480F737A141F9@G01JPEXMBYT04
-
Etsuro Fujita authored
For the convenience of extensions, we previously only saved PathTargets for grouped, window, and final relations in root->upper_targets[] in grouping_planner(). To improve the convenience, save PathTargets for distinct and ordered relations as well. Author: Antonin Houska, with an additional change by me Discussion: https://postgr.es/m/10994.1549559088@localhost
-
Michael Paquier authored
ee9e1455 has fixed the tests of pg_basebackup for checksums a first time, still one seek() call missed the shot. Also, the data written in files to emulate corruptions was not actually writing zeros as the quoting style was incorrect. Backpatch the portion for pg_basebackup to v11 where these tests have been introduced. The tests of pg_verify_checksums are new as of v12. Author: Michael Banck Discussion: https://postgr.es/m/1550153276.796.35.camel@credativ.de Backpatch-through: 11
-
Michael Paquier authored
The actual range of reserved OIDs in this case is [11000,11999] and not [11000,12000]. Author: John Naylor Discussion: https://postgr.es/m/CAJVSVGV5StmK-inxbmrf0nLbBGeaAKnjnqxXmk+4ufeav8JMSA@mail.gmail.com
-
Michael Paquier authored
When reading a new page internally and depending on the way the WAL reader facility gets used by plugins, the current implementation of the WAL reader may finish by reading a block multiple times while it is not actually necessary as the requested data length may be equal to what has been already read. This can happen for any size, but is more likely to happen at the end of a page. This can cause performance penalties in plugins which rely on the block reads to be purely sequential, zlib not liking backward reads for example. The new behavior also shaves some cycles when doing recovery. Author: Arthur Zakirov Reviewed-by: Andrey Lepikhov, Michael Paquier, Grigory Smolkin Discussion: https://postgr.es/m/2ddf4a32-517e-d6f4-d992-4a63b6035bfd@postgrespro.ru
-
- 17 Feb, 2019 3 commits
-
-
Thomas Munro authored
Teach dsm_unpin_segment() to skip segments that are in the process of being destroyed by another backend, when searching for a handle. Such a segment cannot possibly be the one we are looking for, even if its handle matches. Another slot might hold a recently created segment that has the same handle value by coincidence, and we need to keep searching for that one. The bug caused rare "cannot unpin a segment that is not pinned" errors on 10 and 11. Similar to commit 6c0fb941 for dsm_attach(). Back-patch to 10, where dsm_unpin_segment() landed. Author: Thomas Munro Reported-by: Justin Pryzby Tested-by: Justin Pryzby (along with other recent DSA/DSM fixes) Discussion: https://postgr.es/m/20190216023854.GF30291@telsasoft.com
-
Joe Conway authored
The dblink documentation claims that an empty string is returned if there has been no error, however OK is actually returned in that case. Also, clarify that an async error may not be seen unless dblink_is_busy() or dblink_get_result() have been called first. Backpatch to all supported branches. Reported-by: realyota Backpatch-through: 9.4 Discussion: https://postgr.es/m/153371978486.1298.2091761143788088262@wrigleys.postgresql.org
-
Tom Lane authored
We should logically have allowed this case when we allowed zero-column tables, but it was overlooked. Although this might be thought a feature addition, it's really a bug fix, because it was possible to create a zero-column view via the convert-table-to-view code path, and then you'd have a situation where dump/reload would fail. Hence, back-patch to all supported branches. Arrange the added test cases to provide coverage of the related pg_dump code paths (since these views will be dumped and reloaded during the pg_upgrade regression test). I also made them test the case where pg_dump has to postpone the view rule into post-data, which disturbingly had no regression coverage before. Report and patch by Ashutosh Sharma (test case by me) Discussion: https://postgr.es/m/CAE9k0PkmHdeSaeZt2ujnb_cKucmK3sDDceDzw7+d5UZoNJPYOg@mail.gmail.com
-