PostgreSQL 执行Drop Table等命令型SQL的总体流程

DROP命令(Commands)实现:

/*
 * Drop one or more objects.
 *
 * We don't currently handle all object types here.  Relations, for example,
 * require special handling, because (for example) indexes have additional
 * locking requirements.
 *
 * We look up all the objects first, and then delete them in a single
 * performMultipleDeletions() call.  This avoids unnecessary DROP RESTRICT
 * errors if there are dependencies between them.
 */
void
RemoveObjects(DropStmt *stmt)

/*
 * Dispatch function for DropStmt
 */
static void
ExecDropStmt(DropStmt *stmt, bool isTopLevel)
{
	switch (stmt->removeType)
	{
		case OBJECT_INDEX:
			if (stmt->concurrent)
				PreventTransactionChain(isTopLevel,
										"DROP INDEX CONCURRENTLY");
			/* fall through */

		case OBJECT_TABLE:
		case OBJECT_SEQUENCE:
		case OBJECT_VIEW:
		case OBJECT_MATVIEW:
		case OBJECT_FOREIGN_TABLE:
			RemoveRelations(stmt);
			break;
		default:
			RemoveObjects(stmt);
			break;
	}
}

/*
 * standard_ProcessUtility itself deals only with utility commands for
 * which we do not provide event trigger support.  Commands that do have
 * such support are passed down to ProcessUtilitySlow, which contains the
 * necessary infrastructure for such triggers.
 *
 * This division is not just for performance: it's critical that the
 * event trigger code not be invoked when doing START TRANSACTION for
 * example, because we might need to refresh the event trigger cache,
 * which requires being in a valid transaction.
 */
void
standard_ProcessUtility(Node *parsetree,
						const char *queryString,
						ProcessUtilityContext context,
						ParamListInfo params,
						DestReceiver *dest,
						char *completionTag)
/*
 * ProcessUtility
 *		general utility function invoker
 *
 *	parsetree: the parse tree for the utility statement
 *	queryString: original source text of command
 *	context: identifies source of statement (toplevel client command,
 *		non-toplevel client command, subcommand of a larger utility command)
 *	params: parameters to use during execution
 *	dest: where to send results
 *	completionTag: points to a buffer of size COMPLETION_TAG_BUFSIZE
 *		in which to store a command completion status string.
 *
 * Notes: as of PG 8.4, caller MUST supply a queryString; it is not
 * allowed anymore to pass NULL.  (If you really don't have source text,
 * you can pass a constant string, perhaps "(query not available)".)
 *
 * completionTag is only set nonempty if we want to return a nondefault status.
 *
 * completionTag may be NULL if caller doesn't want a status string.
 */
void
ProcessUtility(Node *parsetree,
			   const char *queryString,
			   ProcessUtilityContext context,
			   ParamListInfo params,
			   DestReceiver *dest,
			   char *completionTag)

详细调用栈如下:

#0  ExecDropStmt (stmt=0x17e9b40, isTopLevel=1 '\001') at utility.c:1349
#1  0x0000000000759457 in ProcessUtilitySlow (parsetree=0x17e9b40, queryString=0x17e90b0 "drop table t1;", context=PROCESS_UTILITY_TOPLEVEL, params=0x0,
    dest=0x17e9ea0, completionTag=0x7fff06aee670 "") at utility.c:1296
#2  0x0000000000758849 in standard_ProcessUtility (parsetree=0x17e9b40, queryString=0x17e90b0 "drop table t1;", context=PROCESS_UTILITY_TOPLEVEL, params=0x0,
    dest=0x17e9ea0, completionTag=0x7fff06aee670 "") at utility.c:792
#3  0x0000000000757c88 in ProcessUtility (parsetree=0x17e9b40, queryString=0x17e90b0 "drop table t1;", context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=0x17e9ea0,
    completionTag=0x7fff06aee670 "") at utility.c:310
#4  0x0000000000756e92 in PortalRunUtility (portal=0x1822d70, utilityStmt=0x17e9b40, isTopLevel=1 '\001', dest=0x17e9ea0, completionTag=0x7fff06aee670 "")
    at pquery.c:1187
#5  0x0000000000757048 in PortalRunMulti (portal=0x1822d70, isTopLevel=1 '\001', dest=0x17e9ea0, altdest=0x17e9ea0, completionTag=0x7fff06aee670 "") at pquery.c:1318
#6  0x000000000075661c in PortalRun (portal=0x1822d70, count=9223372036854775807, isTopLevel=1 '\001', dest=0x17e9ea0, altdest=0x17e9ea0,
    completionTag=0x7fff06aee670 "") at pquery.c:816
#7  0x0000000000750944 in exec_simple_query (query_string=0x17e90b0 "drop table t1;") at postgres.c:1045
#8  0x0000000000754967 in PostgresMain (argc=1, argv=0x1784148, dbname=0x1784130 "wzy", username=0x1784110 "xiaochu.yh") at postgres.c:4004
#9  0x00000000006e80ba in BackendRun (port=0x17a3e00) at postmaster.c:4117
#10 0x00000000006e77fd in BackendStartup (port=0x17a3e00) at postmaster.c:3791
#11 0x00000000006e41b2 in ServerLoop () at postmaster.c:1570
#12 0x00000000006e392e in PostmasterMain (argc=3, argv=0x1783380) at postmaster.c:1223
#13 0x000000000064d3d3 in main (argc=3, argv=0x1783380) at main.c:225

Portal,入口的意思。

对于可以生成执行计划的SQL语句(planable SQL),都通过ProcessQuery来处理;对于不能生成执行计划的SQL语句,取名为命令型SQL(Command SQL),都通过PortalRunUtility来处理。

参考:

1. gdb使用 http://blog.chinaunix.net/uid-20788636-id-1841301.html

2. postgre编译安装启动 http://blog.chinaunix.net/uid-11161675-id-2903295.html

3. postgre官方文档 http://www.postgresql.org/docs/current/static/index.html

4. 如何做postgre源码分析 http://blog.csdn.net/anzelin_ruc/article/details/8622770

时间: 2024-10-18 09:10:18

PostgreSQL 执行Drop Table等命令型SQL的总体流程的相关文章

mysql drop table and purge

一.drop表 执行drop table xx 语句 drop后的表被放在回收站(user_recyclebin)里,而不是直接删除掉.这样,回收站里的表信息就可以被恢复,或彻底清除. 通过查询回收站user_recyclebin获取被删除的表信息,然后使用语句 flashback table <user_recyclebin.object_name or user_recyclebin.original_name> to before drop [rename to <new_tabl

SQL Server数据库的存储过程中定义的临时表,真的有必要显式删除(drop table #tableName)吗?

本文出处:http://www.cnblogs.com/wy123/p/6704619.html 问题背景 在写SQL Server存储过程中,如果存储过程中定义了临时表,有些人习惯在存储过程结束的时候一个一个显式地删除过程中定义的临时表(drop table #tName),有些人又没有这个习惯,对于不明真相的群众或者喜欢思考的人会问,存储过程中定义的临时表,最后要不要主动删除,为什么?或者说是不是存储过程结束的时候删除临时表更加规范?不止一个人问过这个问题了,说实在话,本人之前确实不清楚,只

hive drop table命令没反应

问题:执行次命令没反应,表示空表 hive> drop table tt; 不多说,是因为mysql数据库字符集问题,解决办法把之前的库删掉,重新创建一个,并修改字符集为latin1 alter database hive character set latin1; 再次启动hive问题解决

转换sql文件的create table语句为drop table语句

1 package com.csii.pweb.query.action; 2 3 import java.io.BufferedReader; 4 import java.io.FileNotFoundException; 5 import java.io.FileReader; 6 import java.io.IOException; 7 import java.util.ArrayList; 8 import java.util.List; 9 10 11 public class Ja

Oracle Flashback Drop: Undo a DROP TABLE Operation

7.4 Oracle Flashback Drop: Undoa DROP TABLE Operation Oracle Flashback Drop reverses theeffects of a DROP TABLE operation. It can be used to recover afterthe accidental drop of a table. Flashback Drop is substantially faster thanother recovery mechan

用命令对sql进行备份

利用T-SQL语句,实现数据库的备份与还原的功能 体现了SQL Server中的四个知识点: 1. 获取SQL Server服务器上的默认目录 2. 备份SQL语句的使用 3. 恢复SQL语句的使用,同时考虑了强制恢复时关闭其他用户进程的处理 4. 作业创建SQL语句的使用 /*1.--得到数据库的文件目录 @dbname 指定要取得目录的数据库名如果指定的数据不存在,返回安装SQL时设置的默认数据目录如果指定NULL,则返回默认的SQL备份目录名*/ /*--调用示例select 数据库文件目

Truncate table、Delete与Drop table的区别

Truncate table.Delete与Drop table的区别 TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同:二者均删除表中的全部行.但 TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少. DELETE 语句每次删除一行,并在事务日志中为所删除的每行记录一项.TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据,并且只在事务日志中记录页的释放. TRUNCATE TABLE 删除表中的所有行

MongoDB命令及SQL语法对比

mongodb与mysql命令对比 传统的关系数据库一般由数据库(database).表(table).记录(record)三个层次概念组成,MongoDB是由数据库(database).集合(collection).文档对象(document)三个层次组成.MongoDB对于关系型数据库里的表,但是集合中没有列.行和关系概念,这体现了模式自由的特点. MySQL MongoDB 说明 mysqld mongod 服务器守护进程 mysql mongo 客户端工具 mysqldump mongo

DROP TABLE 恢复【一】

当DROP TABLE指令敲下的时候,你很爽,你有考虑过后果么?如果该表真的没用,你DROP到无所谓,如果还有用的,这时你肯定吓惨了吧,如果你有备份,那么恭喜你,逃过一劫,如果没有备份呢?这时就该绝望了?NO! 如果你的表是innodb表,那么还有希望挽救,如果是myisam表,那么真的没救了.前面文章介绍了 Recover InnoDB dictionary,这是恢复数据的前提.恢复innodb字典信息使用的是TwinDB recovery toolkit,我们恢复数据也是使用该工具.下面的案