Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Greenplum
Gpdb
提交
6c3dff42
G
Gpdb
项目概览
Greenplum
/
Gpdb
通知
7
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
Gpdb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
6c3dff42
编写于
10月 18, 1996
作者:
M
Marc G. Fournier
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Document #ifdef's from backend/access subdirs so that we know what
features(?) are available
上级
2ecb7e5e
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
48 addition
and
29 deletion
+48
-29
src/include/config.h
src/include/config.h
+48
-29
未找到文件。
src/include/config.h
浏览文件 @
6c3dff42
...
...
@@ -184,50 +184,69 @@
#define DEADLOCK_TIMEOUT 60
/* Fixes use of indexes infunctions */
#define INDEXSCAN_PATCH
/* found in src/backend/utils/adt/date.c */
/* #define DATEDEBUG */
/* found in src/backend/utils/adt/datetimes.c */
/* #define USE_SHORT_YEAR */
/* #define AMERICAN_STYLE */
/*----------------------------------------*/
/* found in src/backend/utils/adt/float.c */
/*------------------------------------------------------*/
/* defining unsafe floats's will make float4 and float8 */
/* ops faster at the cost of safety, of course! */
/*------------------------------------------------------*/
/*
* defining unsafe floats's will make float4 and float8
* ops faster at the cost of safety, of course!
*/
/* #define UNSAFE_FLOATS */
/*
There is a bug in the function executor. The backend crashes while trying to
execute an sql function containing an utility command (create, notify, ...).
The bug is part in the planner, which returns a number of plans different
than the number of commands if there are utility commands in the query, and
in part in the function executor which assumes that all commands are normal
query commands and causes a SIGSEGV trying to execute commands without plan.
*/
* There is a bug in the function executor. The backend crashes while trying to
* execute an sql function containing an utility command (create, notify, ...).
* The bug is part in the planner, which returns a number of plans different
* than the number of commands if there are utility commands in the query, and
* in part in the function executor which assumes that all commands are normal
* query commands and causes a SIGSEGV trying to execute commands without plan.
*/
#define FUNC_UTIL_PATCH
/*
* Async notifies received while a backend is in the middle of a begin/end
* transaction block are lost by libpq when the final end command is issued.
*
* The bug is in the routine PQexec of libpq. The routine throws away any
* message from the backend when a message of type 'C' is received. This
* type of message is sent when the result of a portal query command with
* no tuples is returned. Unfortunately this is the case of the end command.
* As all async notification are sent only when the transaction is finished,
* if they are received in the middle of a transaction they are lost in the
* libpq library. I added some tracing code to PQexec and this is the output:
*/
#define PQ_NOTIFY_PATCH
/* Debug #defines */
/* #define IPORTAL_DEBUG /* access/common/printtup.c */
/* #define HEAPDEBUGALL /* access/heap/heapam.c */
/* #define ISTRATDEBUG /* access/index/istrat.c */
/* #define FASTBUILD_DEBUG /* access/nbtree/nbtsort.c */
#define RTDEBUG
/* access/rtree/rtree.c */
#define GISTDEBUG
/* access/gist/gist.c */
/* The following don't have any apparent purpose, but are in the
* code. someday, will take them out altogether, but for now,
* document them here
*/
/* #define OMIT_PARTIAL_INDEX /* access/hash/hash.c */
/* #define PERFECT_MMGR /* access/hash/hash.c */
/* #define PERFECT_MEM /* access/hash/hashscan.c */
/* #define NO_BUFFERISVALID /* access/heap/heapam.c */
/* Undocumented "features"? */
#define FASTBUILD
/* access/nbtree/nbtsort.c */
Async notifies received while a backend is in the middle of a begin/end
transaction block are lost by libpq when the final end command is issued.
The bug is in the routine PQexec of libpq. The routine throws away any
message from the backend when a message of type 'C' is received. This
type of message is sent when the result of a portal query command with
no tuples is returned. Unfortunately this is the case of the end command.
As all async notification are sent only when the transaction is finished,
if they are received in the middle of a transaction they are lost in the
libpq library. I added some tracing code to PQexec and this is the output:
*/
#define PQ_NOTIFY_PATCH
#endif
/* CONFIG_H */
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录