Merged
Conversation
The assertion was added back in 2017 to make sure that change tracking was disabled when change tracking logs get partially written or corrupted (mostly due to disk full or other disk issues). However, it was not noticed that gpaddmirrors goes through the same code path with mode PMModeMirrorlessSegment (mostly because our gpaddmirrors automated tests used to run on non-assert builds). The assertion would always fail when running gpaddmirrors because getFileRepRoleAndState() only returns valid values for PMModePrimarySegment and PMModeMirrorSegment. Modify the assertion to make an exception for gpaddmirrors. GPDB commit reference: https://github.com/greenplum-db/gpdb/commit/a0cc23d497a001c82b6cff07d5143be6f2e322b1
1. It is not necessary to create dataflow extension when gpload connect to gpdb5. 2. If there's no GUC or not text format is used, do not create dataflow extension even gpload connect tos gpdb6 or above. Co-authored-by: Tony Duan <tonyd@vmware.com>
* add gpload input newline config
This reverts commit 93f9bff.
The server collects up to a bufferload of data whenever it reads data from the client socket. When SSL or GSS encryption is requested during startup, any additional data received with the initial request message remained in the buffer, and would be treated as already-decrypted data once the encryption handshake completed. Thus, a man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could be abused to send faked SQL commands to the server, although that would only work if the server did not demand any authentication data. (However, a server relying on SSL certificate authentication might well not do so.) To fix, throw a protocol-violation error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-23214 (cherry picked from commit 046c2c8)
libpq collects up to a bufferload of data whenever it reads data from the socket. When SSL or GSS encryption is requested during startup, any additional data received with the server's yes-or-no reply remained in the buffer, and would be treated as already-decrypted data once the encryption handshake completed. Thus, a man-in-the-middle with the ability to inject data into the TCP connection could stuff some cleartext data into the start of a supposedly encryption-protected database session. This could probably be abused to inject faked responses to the client's first few queries, although other details of libpq's behavior make that harder than it sounds. A different line of attack is to exfiltrate the client's password, or other sensitive data that might be sent early in the session. That has been shown to be possible with a server vulnerable to CVE-2021-23214. To fix, throw a protocol-violation error if the internal buffer is not empty after the encryption handshake. Our thanks to Jacob Champion for reporting this problem. Security: CVE-2021-23222 (cherry picked from commit d83cdfd)
Cherry-picked from e4c6c36 and follow up 780005f with minor conflicts resolved. Original commit message follows along with a manual repro for 5X that involves named portals in extended protocol: ------------------------------------------------------------------------- Since commit 2fa7c06, we have introduced an opportunity where the active statement count is leaked (the active statements is not decremented with ResLockUpdateLimit(.., .., false, ..). This can happen during a deadlock report or a statement cancellation of a statement if the session has at least one other active named portal. During CheckDeadlock()/ResLockWaitCancel(), we would clean up the locallock, which would cause a subsequent call to ResLockRelease(), for the other active portal to early return here: /* * If the lock request did not get very far, cleanup is easy. */ if (!locallock || !locallock->lock || !locallock->proclock) { elog(LOG, "Resource queue %d: no lock to release", locktag->locktag_field1); if (locallock) { RemoveLocalLock(locallock); } return false; } and not call ResLockUpdateLimit(.., .., false, ..) The resultant active statement leak would cause subsequently submitted statements to block forever on the resource queue lock, once the #active statements = active statement limit. Additionally, added test coverage for query cancellation and general sanity checks for leaks in other tests. ------------------------------------------------------------------------- Manual repro applicable to 5X with extended protocol and named portals: Consider a JDBC program using named portals with extended protocol (with prepareThreshold=1, autoCommit=false, fetchSize=1). Let the program run 2 select statements inside the same transaction. Have 2 sessions run each statement in an interleaved fashion similar to the tests added in resource_queue_multi_portal.sql with jdb. Use a similar resource queue with a limit of 2 active statements. This will give rise to a deadlock and active statement leak. Note: using the same program described above, a leak with cancellation can also be achieved. Co-authored-by: Ashwin Agrawal <aashwin@vmware.com> Co-authored-by: Yao Wang <wayao@vmware.com> Co-authored-by: Hongxu Ma <interma@outlook.com> Co-authored-by: Zhenghua Lyu <78182909+kainwen@users.noreply.github.com>
Discussion: https://groups.google.com/a/greenplum.org/g/gpdb-dev/c/A2JUpJ0NrEA/m/3S6rmd2zBAAJ (cherry picked from commit b1dc547)
gporca 3.121 fixes an issue with casting for EXCEPT & INTERSECT that was crashing executor
Collaborator
|
Failure of regression tests with ORCA on x86_64 (starve_case) is a known problem: https://arenadata.atlassian.net/browse/ADBDEV-2154. @maksm90, do you need more time to analyze the upstream patch? |
maksm90
approved these changes
Dec 21, 2021
Collaborator
|
@deart2k, this one is ready to merge. |
Stolb27
approved these changes
Dec 21, 2021
hilltracer
pushed a commit
that referenced
this pull request
Mar 6, 2026
- Altlinux 10.2 support - AstraLinux 1.8 support Ticket: CI-5297
Stolb27
pushed a commit
that referenced
this pull request
Mar 10, 2026
- Altlinux 10.2 support - AstraLinux 1.8 support Ticket: CI-5297
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Here are some reminders before you submit the pull request
make installcheck