Re: Tricky bugs in concurrent index build

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tricky bugs in concurrent index build
Date: 2006-08-25 13:10:11
Message-ID: 87k64xufkc.fsf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-25 13:19:52 Safer auto-initdb for RPM init script
Previous Message Tom Lane 2006-08-25 12:53:07 Re: Performance testing of COPY (SELECT) TO