Re: Tricky bugs in concurrent index build

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Tricky bugs in concurrent index build
Дата
Msg-id 87k64xufkc.fsf@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Tricky bugs in concurrent index build  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Tricky bugs in concurrent index build
Список pgsql-hackers
Do we want something like this? I just made this error myself so unless I'm
special (pauses for jokes) I imagine others would be prone to it as well.

I would normally be pretty leery of code like this but it seems unlikely
anyone would actually want an index named "concurrently" and the consequences
if you get it wrong in a production environment are pretty dire. We might even
consider making it an outright error.


--- gram.y    25 Aug 2006 10:14:17 +0100    2.558
+++ gram.y    25 Aug 2006 14:04:54 +0100    
@@ -56,6 +56,7 @@#include "commands/defrem.h"#include "nodes/makefuncs.h"#include "parser/gramparse.h"
+#include "parser/scansup.h"#include "storage/lmgr.h"#include "utils/date.h"#include "utils/datetime.h"
@@ -3653,6 +3654,12 @@            opt_definition OptTableSpace where_clause                {
IndexStmt*n = makeNode(IndexStmt);
 
+
+                    if (!strcmp(downcase_truncate_identifier($4,20,false), "concurrently"))
+                        ereport(WARNING,
+                                (errcode(ERRCODE_SYNTAX_ERROR),
+                                 errmsg("performing non-concurrent index build of index named \"concurrently\"")));
+                    n->unique = $2;                    n->concurrent = false;                    n->idxname = $4;
--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Performance testing of COPY (SELECT) TO
Следующее
От: Tom Lane
Дата:
Сообщение: Safer auto-initdb for RPM init script