Duplicate object names in GRANT

Started by Gavin Sherryover 20 years ago4 messages
#1Gavin Sherry
swm@linuxworld.com.au

Hi all,

I ran across this yesterday on HEAD:

template1=# grant select on foo, foo to swm;
ERROR: tuple already updated by self

We could do away with the error by producing a unique list of object names
-- but that would impose an extra cost on the common case. It seems to me
that producing a useful error message would entail the same cost, however.

Thoughts?

Gavin

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Gavin Sherry (#1)
Re: Duplicate object names in GRANT

Gavin Sherry <swm@linuxworld.com.au> writes:

I ran across this yesterday on HEAD:

template1=# grant select on foo, foo to swm;
ERROR: tuple already updated by self

Seems to fail similarly in every version back to 7.2; probably further,
but that's all I have running at the moment.

We could do away with the error by producing a unique list of object names
-- but that would impose an extra cost on the common case.

CommandCounterIncrement in the GRANT loop would be easier, likely.
I'm having a hard time getting excited about it though...

regards, tom lane

#3Gavin Sherry
swm@linuxworld.com.au
In reply to: Tom Lane (#2)
1 attachment(s)
Re: [HACKERS] Duplicate object names in GRANT

On Wed, 27 Jul 2005, Tom Lane wrote:

Gavin Sherry <swm@linuxworld.com.au> writes:

I ran across this yesterday on HEAD:

template1=# grant select on foo, foo to swm;
ERROR: tuple already updated by self

Seems to fail similarly in every version back to 7.2; probably further,
but that's all I have running at the moment.

We could do away with the error by producing a unique list of object names
-- but that would impose an extra cost on the common case.

CommandCounterIncrement in the GRANT loop would be easier, likely.
I'm having a hard time getting excited about it though...

Yeah, its not that exciting but that error message would throw your
average user.

I've attached a patch which calls CommandCounterIncrement() in each of the
grant loops.

Thanks,

Gavin

Attachments:

grant.patchtext/plain; charset=US-ASCII; name=grant.patchDownload
Index: src/backend/catalog/aclchk.c
===================================================================
RCS file: /usr/local/cvsroot/pgsql/src/backend/catalog/aclchk.c,v
retrieving revision 1.116
diff -u -p -r1.116 aclchk.c
--- src/backend/catalog/aclchk.c	26 Jul 2005 16:38:26 -0000	1.116
+++ src/backend/catalog/aclchk.c	28 Jul 2005 05:25:10 -0000
@@ -388,6 +388,8 @@ ExecuteGrantStmt_Relation(GrantStmt *stm
 		pfree(new_acl);
 
 		heap_close(relation, RowExclusiveLock);
+
+        CommandCounterIncrement();
 	}
 }
 
@@ -565,6 +567,8 @@ ExecuteGrantStmt_Database(GrantStmt *stm
 		heap_endscan(scan);
 
 		heap_close(relation, RowExclusiveLock);
+
+        CommandCounterIncrement();
 	}
 }
 
@@ -738,6 +742,8 @@ ExecuteGrantStmt_Function(GrantStmt *stm
 		pfree(new_acl);
 
 		heap_close(relation, RowExclusiveLock);
+
+        CommandCounterIncrement();
 	}
 }
 
@@ -920,6 +926,8 @@ ExecuteGrantStmt_Language(GrantStmt *stm
 		pfree(new_acl);
 
 		heap_close(relation, RowExclusiveLock);
+
+        CommandCounterIncrement();
 	}
 }
 
@@ -1093,6 +1101,8 @@ ExecuteGrantStmt_Namespace(GrantStmt *st
 		pfree(new_acl);
 
 		heap_close(relation, RowExclusiveLock);
+
+        CommandCounterIncrement();
 	}
 }
 
@@ -1269,6 +1279,8 @@ ExecuteGrantStmt_Tablespace(GrantStmt *s
 
 		heap_endscan(scan);
 		heap_close(relation, RowExclusiveLock);
+
+        CommandCounterIncrement();
 	}
 }
 
#4Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Gavin Sherry (#3)
Re: [HACKERS] Duplicate object names in GRANT

Patch applied. Thanks.

I also added a comment above each one to mention why it is needed.

---------------------------------------------------------------------------

Gavin Sherry wrote:

On Wed, 27 Jul 2005, Tom Lane wrote:

Gavin Sherry <swm@linuxworld.com.au> writes:

I ran across this yesterday on HEAD:

template1=# grant select on foo, foo to swm;
ERROR: tuple already updated by self

Seems to fail similarly in every version back to 7.2; probably further,
but that's all I have running at the moment.

We could do away with the error by producing a unique list of object names
-- but that would impose an extra cost on the common case.

CommandCounterIncrement in the GRANT loop would be easier, likely.
I'm having a hard time getting excited about it though...

Yeah, its not that exciting but that error message would throw your
average user.

I've attached a patch which calls CommandCounterIncrement() in each of the
grant loops.

Thanks,

Gavin

Content-Description:

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073