- 25 8月, 2016 6 次提交
-
-
由 Heikki Linnakangas 提交于
Since there is a function specifically for this lookup, might as well use it.
-
由 Heikki Linnakangas 提交于
We surely want to have a syscache for any lookups done at execution, for speed. This makes it more clear that there indeed is a syscache for these. (And I'm trying to remove CaQL altogether, anyway) The CaQL lookup in assign_func_result_transient_type(Oid) was in fact wrong before. It called caql_endscan(), and continued to access the tuple after that. Fix that while we're at it.
-
由 Heikki Linnakangas 提交于
The ExecuteDoStmt() function was backported from PostgreSQL 9.0, but it was put before the AlterFunctionNameSpace() function, even though it's after it in the upstream. Move it to where it is in the upstream, to reduce merge conflicts in the future.
-
由 Heikki Linnakangas 提交于
Not sure why the handling of language attribute was changed in GPDB. Let's revert it back to the way it's done in the upstream. Also change the handling of "prodataaccess" to follow the same pattern.
-
由 Heikki Linnakangas 提交于
I tried to change all of these in commit 6d7f09f3, but missed a few.
-
由 pengxindong 提交于
-
- 23 8月, 2016 11 次提交
-
-
由 Daniel Gustafsson 提交于
-
由 Daniel Gustafsson 提交于
-
由 Daniel Gustafsson 提交于
This removes all utilities which are known to be deprecated from gpMgmt and it also clears out any command line switches marked as deprecated along with code marked deprecated. It also removes the leftovers from previously removed utilities such as gpsuspend and gpcheck_hostdump etc and fixes mentions of renamed utilities. There should be no functional change from this commit as the only removed utils have been marked deprecated for some time.
-
由 Heikki Linnakangas 提交于
Not sure why we had these twice in the tinc suite. In any case, these are straightforward DDL tests, so they can well live in the main test suite.
-
由 Heikki Linnakangas 提交于
We have the same tests in src/test/regress/bugbuster/sql/spi.sql already.
-
由 Heikki Linnakangas 提交于
I don't see any references to "phone_book", by grepping the tincrepo directory. So seems to be unused. Moreover, we have this same data in src/test/regress/input/qp_regexp.source.
-
由 Heikki Linnakangas 提交于
This is mostly the same as the README on previous directory level.
-
由 Heikki Linnakangas 提交于
These are straightforward "run SQL, check expected output" style tests, and only take a few seconds to run. Let's get them into the normal regression suite.
-
由 Heikki Linnakangas 提交于
We have all of these same tests in src/test/regress/bugbuster/sql/schema_topology.sql.
-
由 Heikki Linnakangas 提交于
We already have the exact same tests in the normal regression suite, as src/test/regress/sql/DML_over_joins.sql.
-
由 Heikki Linnakangas 提交于
We have new, improved versions of these in src/test/regress. It seems that TINC will happily use those versions, if we just remove these old copies from ext.
-
- 20 8月, 2016 10 次提交
-
-
由 Heikki Linnakangas 提交于
These are all direct ReleaseSysCache() calls in the upstream.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
Move GPDB-specific keywords to a separate section.
-
由 Heikki Linnakangas 提交于
The return value was unused, and the 'spin' and 'putInFreeList' argument were alwasy passed as 'true', which gave the upstream behaviour.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
I think these were left out by accident when we cherry-picked the upstream patches to add location information to various structs.
-
由 Haisheng Yuan 提交于
-
-
-
- 19 8月, 2016 4 次提交
-
-
由 Wang Hao 提交于
-
由 Chumki Roy 提交于
-
由 Chumki Roy 提交于
This reverts commit ce3b3675.
-
由 Chumki Roy 提交于
-
- 18 8月, 2016 5 次提交
-
-
由 Heikki Linnakangas 提交于
I found these with "callcatcher", written by Caolán McNamara. Many thanks for the tool! See https://www.skynet.ie/~caolan/Packages/callcatcher.html
-
由 Wang Hao 提交于
-
由 Heikki Linnakangas 提交于
-
由 Jimmy Yih 提交于
-
由 Chumki Roy 提交于
Add -H option to disable update gpcrondump history table. Option '-h' will not be deleted in this release, but it will be deprecated in a future release. Update behave tests and unit tests. Modify gpcrondump help file. Authors: Chumki Roy, Marbin Tan, Nikhil Kak
-
- 17 8月, 2016 4 次提交
-
-
由 Gang Xiong 提交于
After commit c63f1b5d, RowExclusiveLock lock on pg_class won't be held till the end of transaction. Update the expected output file accordingly.
-
由 Ashwin Agrawal 提交于
SnapshotNow MUST be used during insert flow to fetch the latest EOF value from aoseg table. Earlier usage of ActiveSnapshot in AO insert flow caused data corruption as potentially could read incorrect or stale EOF value from aoseg. The specific scenario this happens when entry from AppendOnlyHash table gets evicted out. It invalidates (zeros out) the latestWriteXid and hence check for usedByConcurrentTransaction cannot be performed. So, any transaction later inserting data to same AO table, if it has aquired the snapshot and has latestWriteXid listed in its in-progress distributed transaction list, gets the same segfile to write. Based on DTM visibility rules using ActiveSnapshot current transaction will not read the EOF value from previous inserted transaction as its listed in its in-progress list and hence will overwrite the data but SnapshotNow will see the latest and make sure to append.
-
由 Ashwin Agrawal 提交于
Currenty, there is no easy way to evict entry from appendonly writer hash table, most of current tests reduce the value of max_appendonly_tables which needs database restart to take effect and then need to actually create that many concurrent AO table inserts to evict the hash table entry. Using this GUC can easily tests the eviction behavior.
-
由 Ashwin Agrawal 提交于
Currently, during insert to AO/CO tables check is performed to validate file-offset (EOF) found from pg_aoseg which would be used to start writing the data to file. The offset to start writing needs to be greater than currently marked EOF in persistent table. The validation is currently performed for all other scenarios except EOF=0, so this commit is modifing to enable it for EOF-0 case as well. As it was seen in field for yet to be known reasons maybe indexing issues on pg_aoseg table, that incorrect EOF=0 was fetched from aoseg and valid data was over-written. So, this protection will prevent data-loss scenarios.
-