- 20 8月, 2016 5 次提交
-
-
由 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 1 次提交
-
-
由 Wang Hao 提交于
-
- 18 8月, 2016 4 次提交
-
-
由 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 提交于
-
- 17 8月, 2016 6 次提交
-
-
由 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.
-
由 Amil Khanzada 提交于
This commit adds gpperfmon/logs/ to the exclusion list and also corrects gp_dumps/ to db_dumps/ which gpinitstandby sends as args to pg_basebackup to initialize the standby master. This should speed up gpinitstandby if a user uses gpperfmon/gpcc or gpcrondump. Authors: Amil Khanzada and Jimmy Yih
-
由 Haisheng Yuan 提交于
Also updated gp_optimizer expected output and ignore line number difference for functions.c
-
- 16 8月, 2016 17 次提交
-
-
由 Heikki Linnakangas 提交于
We don't use CaQL here anymore. Fix to match upstream.
-
由 Heikki Linnakangas 提交于
We don't use CaQL here anymore.
-
由 Heikki Linnakangas 提交于
We just got rid of the last users of them.
-
由 Heikki Linnakangas 提交于
To reduce our diff vs upstream, to make diffing and merging easier.
-
由 Heikki Linnakangas 提交于
It's a plain heap tuple in the usptream. This reduces the diff vs. upstream.
-
由 Heikki Linnakangas 提交于
Use a regular syscache lookup like in the upstream, and get rid of the now-unused get_func_namespace function.
-
由 Heikki Linnakangas 提交于
While it might make sense to extract this duplicated code to a function, let's rather avoid the difference from upstream.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
FTS doesn't actually seem to use the superuser's username for anything. That allowed removing probeUser and retrieveUserAndDb(). All the remaining calls to FtsFindSuperuser() were from cdbresynchronizechangetracking.c, but all of those callers just discarded the return value. FtsFindSuperuser() doesn't throw any errors, either, so it didn't serve any error-checking purpose either. Remove it all.
-
由 Heikki Linnakangas 提交于
Not that it matters from a performance point of view, but surely it was not intended.
-
由 Heikki Linnakangas 提交于
We just looked up the relation with RangeVarGetRelidExtended(). There's no reason to believe it might've been removed since then, especially when we just locked it.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
I'm not sure why it ever existed, but it's been dead for a long time.
-
由 Pengzhou Tang 提交于
-
由 Pengzhou Tang 提交于
-
- 15 8月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
-
- 13 8月, 2016 1 次提交
-
-
由 Heikki Linnakangas 提交于
The functions in memtuple.c were only called when building a column binding struct. That's not a hot path, as that only gets done once, when starting the executor, not at every row. handleAckedPacket() is probably in a somewhat hot path, as it's called for every received Ack interconnect packet. However, all the calls to it are straight unconditional jumps, so branch prediction should make those very cheap. Inlining them would increase the code size quite a bit, so the compiler is probably making a good choice by refusing to inline them. Let's not try to force it. I'm seeing a few more warnings like this from tqual.c and tuplesort.c, but those are in upstream code, so I'm reluctant to just remove the inline attributes there. Should do something about those too, to reduce the noise, but let's at least get these straightforward gpdb-specific cases fixed. For reference, these are the warnings I was getting: memtuple.c: In function ‘create_col_bind’: memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline] static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align) ^ memtuple.c:241:10: warning: called from here [-Winline] if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 'd')) ^ memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline] static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align) ^ memtuple.c:270:10: warning: called from here [-Winline] if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 'i')) ^ memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline] static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align) ^ memtuple.c:308:10: warning: called from here [-Winline] if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 's')) ^ memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline] static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align) ^ memtuple.c:354:10: warning: called from here [-Winline] if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 'c')) ^ ic_udpifc.c: In function ‘handleAcks.isra.25’: ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline] handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now) ^ ic_udpifc.c:5177:3: warning: called from here [-Winline] handleAckedPacket(conn, buf, now); ^ ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline] handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now) ^ ic_udpifc.c:5189:4: warning: called from here [-Winline] handleAckedPacket(conn, buf, now); ^ ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline] handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now) ^ ic_udpifc.c:5073:4: warning: called from here [-Winline] handleAckedPacket(conn, buf, now); ^ ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline] handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now) ^ ic_udpifc.c:5112:4: warning: called from here [-Winline] handleAckedPacket(conn, buf, now); ^
-
- 12 8月, 2016 5 次提交
-
-
由 Heikki Linnakangas 提交于
Also rename the argument to adjust_inherited_tlist() to what it is in the upstream.
-
由 Heikki Linnakangas 提交于
Now that it's purely GPDB code, let's be tidy. (Running pgindent on files with mixed gpdb-specific and upstream code would easily mess up the formatting of upstream code, if a different version of pgindent is used, or if the gpdb-additions have changed indentation.)
-
由 Heikki Linnakangas 提交于
tablecmds.c is huge, and it's inherited from upstream. This makes diffing and merging with upstream a little bit easier.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
-