aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/arrayfuncs.c
diff options
context:
space:
mode:
authorBruce Momjian <bruce@momjian.us>2005-08-12 21:20:24 +0000
committerBruce Momjian <bruce@momjian.us>2005-08-12 21:20:24 +0000
commit479a8fd69e7e1a934dbe271aee88d1244ed5ca10 (patch)
tree28dd8a1780e747d7390906e19fcb147544c065ce /src/backend/utils/adt/arrayfuncs.c
parentabc8a0a0fecf5c37e683d26fcc9d105d92f5096f (diff)
downloadpostgresql-479a8fd69e7e1a934dbe271aee88d1244ed5ca10.tar.gz
postgresql-479a8fd69e7e1a934dbe271aee88d1244ed5ca10.zip
> 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. Gavin Sherry
Diffstat (limited to 'src/backend/utils/adt/arrayfuncs.c')
0 files changed, 0 insertions, 0 deletions