Parallel scan is not supported #2
Labels
Comments
kelvich
added a commit
that referenced
this issue
Jul 19, 2016
kelvich
added a commit
that referenced
this issue
Aug 25, 2016
kelvich
added a commit
that referenced
this issue
Oct 17, 2016
kelvich
added a commit
that referenced
this issue
Oct 21, 2016
kelvich
added a commit
that referenced
this issue
Oct 24, 2016
kelvich
pushed a commit
that referenced
this issue
Mar 27, 2017
kelvich
pushed a commit
that referenced
this issue
Nov 13, 2017
…DeserializeTransactionState to XTM API
kelvich
added a commit
that referenced
this issue
Nov 13, 2017
kelvich
added a commit
that referenced
this issue
Nov 13, 2017
kelvich
added a commit
that referenced
this issue
Nov 13, 2017
kelvich
added a commit
that referenced
this issue
Nov 13, 2017
kelvich
pushed a commit
that referenced
this issue
May 2, 2018
refresh_by_match_merge() has some issues in the way it builds a SQL query to construct the "diff" table: 1. It doesn't require the selected unique index(es) to be indimmediate. 2. It doesn't pay attention to the particular equality semantics enforced by a given index, but just assumes that they must be those of the column datatype's default btree opclass. 3. It doesn't check that the indexes are btrees. 4. It's insufficiently careful to ensure that the parser will pick the intended operator when parsing the query. (This would have been a security bug before CVE-2018-1058.) 5. It's not careful about indexes on system columns. The way to fix #4 is to make use of the existing code in ri_triggers.c for generating an arbitrary binary operator clause. I chose to move that to ruleutils.c, since that seems a more reasonable place to be exporting such functionality from than ri_triggers.c. While #1, #3, and #5 are just latent given existing feature restrictions, and #2 doesn't arise in the core system for lack of alternate opclasses with different equality behaviors, #4 seems like an issue worth back-patching. That's the bulk of the change anyway, so just back-patch the whole thing to 9.4 where this code was introduced. Discussion: https://postgr.es/m/13836.1521413227@sss.pgh.pa.us
arssher
added a commit
that referenced
this issue
Jul 18, 2018
This is the commit message #2: Tracking on which foreign servers we already started COPY. If foreign server holds several partitions, COPY FROM to local root partition will try to perform several copies at the same time through one connection, obviously without much success. Now we track that and start/end COPY only once. We also allow to pass destination relation name which may be different from foreing table -- so we can copy into foreign root partition in shardman. This is pretty narrow solution. However, keeping several connections to the same foreign server requires significant changes, especially in 2pc handling, so staying here for now. This is the commit message #3: Allow COPY FROM to par8d table even if some FDW parts can't do that. This behaviour was broken in patches allowing COPY FROM to FDW tables. This is the commit message #4: COPY FROM deparse more complete, PG_SHARDMAN macro. Now column names, FORCE NULL and FORCE NOT NULL are deparsed too. PG_SHARDMAN macro ensures this PG contains patches for Postgres. This is the commit message #5: Disable COPY FROM to foreign parts, because no generic impl exists. This is the commit message #6: Fix COPY FROM deparse, forgotten comma for FORCE_NULL etc.
arssher
added a commit
that referenced
this issue
Jul 19, 2018
Cherry-picked from af234df. This is the commit message #2: Tracking on which foreign servers we already started COPY. If foreign server holds several partitions, COPY FROM to local root partition will try to perform several copies at the same time through one connection, obviously without much success. Now we track that and start/end COPY only once. We also allow to pass destination relation name which may be different from foreing table -- so we can copy into foreign root partition in shardman. This is pretty narrow solution. However, keeping several connections to the same foreign server requires significant changes, especially in 2pc handling, so staying here for now. This is the commit message #3: Allow COPY FROM to par8d table even if some FDW parts can't do that. This behaviour was broken in patches allowing COPY FROM to FDW tables. This is the commit message #4: COPY FROM deparse more complete, PG_SHARDMAN macro. Now column names, FORCE NULL and FORCE NOT NULL are deparsed too. PG_SHARDMAN macro ensures this PG contains patches for Postgres. This is the commit message #5: Disable COPY FROM to foreign parts, because no generic impl exists. This is the commit message #6: Fix COPY FROM deparse, forgotten comma for FORCE_NULL etc.
arssher
added a commit
that referenced
this issue
Sep 17, 2018
Cherry-picked from af234df. This is the commit message #2: Tracking on which foreign servers we already started COPY. If foreign server holds several partitions, COPY FROM to local root partition will try to perform several copies at the same time through one connection, obviously without much success. Now we track that and start/end COPY only once. We also allow to pass destination relation name which may be different from foreing table -- so we can copy into foreign root partition in shardman. This is pretty narrow solution. However, keeping several connections to the same foreign server requires significant changes, especially in 2pc handling, so staying here for now. This is the commit message #3: Allow COPY FROM to par8d table even if some FDW parts can't do that. This behaviour was broken in patches allowing COPY FROM to FDW tables. This is the commit message #4: COPY FROM deparse more complete, PG_SHARDMAN macro. Now column names, FORCE NULL and FORCE NOT NULL are deparsed too. PG_SHARDMAN macro ensures this PG contains patches for Postgres. This is the commit message #5: Disable COPY FROM to foreign parts, because no generic impl exists. This is the commit message #6: Fix COPY FROM deparse, forgotten comma for FORCE_NULL etc.
arssher
added a commit
that referenced
this issue
Oct 5, 2018
Cherry-picked from af234df. This is the commit message #2: Tracking on which foreign servers we already started COPY. If foreign server holds several partitions, COPY FROM to local root partition will try to perform several copies at the same time through one connection, obviously without much success. Now we track that and start/end COPY only once. We also allow to pass destination relation name which may be different from foreing table -- so we can copy into foreign root partition in shardman. This is pretty narrow solution. However, keeping several connections to the same foreign server requires significant changes, especially in 2pc handling, so staying here for now. This is the commit message #3: Allow COPY FROM to par8d table even if some FDW parts can't do that. This behaviour was broken in patches allowing COPY FROM to FDW tables. This is the commit message #4: COPY FROM deparse more complete, PG_SHARDMAN macro. Now column names, FORCE NULL and FORCE NOT NULL are deparsed too. PG_SHARDMAN macro ensures this PG contains patches for Postgres. This is the commit message #5: Disable COPY FROM to foreign parts, because no generic impl exists. This is the commit message #6: Fix COPY FROM deparse, forgotten comma for FORCE_NULL etc.
Charles-Schleich
pushed a commit
to Charles-Schleich/postgres_cluster
that referenced
this issue
Jul 15, 2021
Due to how pg_size_pretty(bigint) was implemented, it's possible that when given a negative number of bytes that the returning value would not match the equivalent positive return value when given the equivalent positive number of bytes. This was due to two separate issues. 1. The function used bit shifting to convert the number of bytes into larger units. The rounding performed by bit shifting is not the same as dividing. For example -3 >> 1 = -2, but -3 / 2 = -1. These two operations are only equivalent with positive numbers. 2. The half_rounded() macro rounded towards positive infinity. This meant that negative numbers rounded towards zero and positive numbers rounded away from zero. Here we fix postgrespro#1 by dividing the values instead of bit shifting. We fix postgrespro#2 by adjusting the half_rounded macro always to round away from zero. Additionally, adjust the pg_size_pretty(numeric) function to be more explicit that it's using division rather than bit shifting. A casual observer might have believed bit shifting was used due to a static function being named numeric_shift_right. However, that function was calculating the divisor from the number of bits and performed division. Here we make that more clear. This change is just cosmetic and does not affect the return value of the numeric version of the function. Here we also add a set of regression tests both versions of pg_size_pretty() which test the values directly before and after the function switches to the next unit. This bug was introduced in 8a1fab3. Prior to that negative values were always displayed in bytes. Author: Dean Rasheed, David Rowley Discussion: https://postgr.es/m/CAEZATCXnNW4HsmZnxhfezR5FuiGgp+mkY4AzcL5eRGO4fuadWg@mail.gmail.com Backpatch-through: 9.6, where the bug was introduced.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Transaction context should be copied to parallel workers
The text was updated successfully, but these errors were encountered: