brin index vacuum versus transaction snapshots

If you run `make installcheck` against a cluster with
default_transaction_isolation = 'repeatable read' you get one
failure:

*** /home/kgrittn/pg/master/src/test/regress/expected/brin.out 2015-07-21 10:21:58.798619111 -0500
--- /home/kgrittn/pg/master/src/test/regress/results/brin.out 2015-07-21 14:00:25.169320059 -0500
***************
*** 405,409 ****
--- 405,410 ----       box(point(odd, even), point(thousand, twothousand)) FROM tenk1 ORDER BY unique2 LIMIT 5 OFFSET
5;VACUUM brintest; -- force a summarization cycle in brinidx
 
+ ERROR: brin_summarize_new_values() cannot run in a transaction that has already obtained a snapshot UPDATE brintest
SETint8col = int8col * int4col; UPDATE brintest SET textcol = '' WHERE textcol IS NOT NULL;
 


The stacktrace is:

#0 brinsummarize (index=0x7f1fe0eca6b8, heapRel=0x7f1fe0ed64f8, numSummarized=0x30e1da8, numExisting=0x30e1da8) at
brin.c:1080
#1 0x00000000004683d3 in brinvacuumcleanup (fcinfo=0x7ffd41b95c98) at brin.c:731
#2 0x0000000000a69b28 in FunctionCall2Coll (flinfo=0x7ffd41b96078, collation=0, arg1=140725706121624, arg2=0) at
fmgr.c:1323
#3 0x00000000004f7b60 in index_vacuum_cleanup (info=0x7ffd41b96198, stats=0x0) at indexam.c:717
#4 0x00000000006e1004 in lazy_cleanup_index (indrel=0x7f1fe0eca6b8, stats=0x0, vacrelstats=0x30e0bb0) at
vacuumlazy.c:1397
#5 0x00000000006df637 in lazy_scan_heap (onerel=0x7f1fe0ed64f8, vacrelstats=0x30e0bb0, Irel=0x30e0ca8, nindexes=1,
scan_all=0'\000') at vacuumlazy.c:1108
 
#6 0x00000000006dda3b in lazy_vacuum_rel (onerel=0x7f1fe0ed64f8, options=1, params=0x7ffd41b96798, bstrategy=0x30d9a38)
atvacuumlazy.c:244
 
#7 0x00000000006dc18d in vacuum_rel (relid=30220, relation=0x2f8d1a8, options=1, params=0x7ffd41b96798) at
vacuum.c:1372
#8 0x00000000006db711 in vacuum (options=1, relation=0x2f8d1a8, relid=0, params=0x7ffd41b96798, va_cols=0x0,
bstrategy=0x30d9a38,isTopLevel=1 '\001') at vacuum.c:293
 
#9 0x00000000006db31d in ExecVacuum (vacstmt=0x2f8d200, isTopLevel=1 '\001') at vacuum.c:121
#10 0x00000000008bef36 in standard_ProcessUtility (parsetree=0x2f8d200, queryString=0x2f8c788 "VACUUM brintest;",
context=PROCESS_UTILITY_TOPLEVEL,params=0x0, dest=0x2f8d588, completionTag=0x7ffd41b96d50 "") at utility.c:654
 
#11 0x00000000008be69e in ProcessUtility (parsetree=0x2f8d200, queryString=0x2f8c788 "VACUUM brintest;",
context=PROCESS_UTILITY_TOPLEVEL,params=0x0, dest=0x2f8d588, completionTag=0x7ffd41b96d50 "") at utility.c:335
 
#12 0x00000000008be1a7 in PortalRunUtility (portal=0x2f36b18, utilityStmt=0x2f8d200, isTopLevel=1 '\001',
dest=0x2f8d588,completionTag=0x7ffd41b96d50 "") at pquery.c:1187
 
#13 0x00000000008bd1bd in PortalRunMulti (portal=0x2f36b18, isTopLevel=1 '\001', dest=0x2f8d588, altdest=0x2f8d588,
completionTag=0x7ffd41b96d50"") at pquery.c:1318
 
#14 0x00000000008bc80d in PortalRun (portal=0x2f36b18, count=9223372036854775807, isTopLevel=1 '\001', dest=0x2f8d588,
altdest=0x2f8d588,completionTag=0x7ffd41b96d50 "") at pquery.c:816
 
#15 0x00000000008b7edf in exec_simple_query (query_string=0x2f8c788 "VACUUM brintest;") at postgres.c:1104
#16 0x00000000008b720c in PostgresMain (argc=1, argv=0x2f1d450, dbname=0x2f1d2b0 "regression", username=0x2f1d290
"kgrittn")at postgres.c:4025
 
#17 0x000000000081ab99 in BackendRun (port=0x2f3d610) at postmaster.c:4183
#18 0x000000000081a17a in BackendStartup (port=0x2f3d610) at postmaster.c:3859
#19 0x0000000000816753 in ServerLoop () at postmaster.c:1618
#20 0x0000000000813d4a in PostmasterMain (argc=3, argv=0x2f1c460) at postmaster.c:1263
#21 0x000000000074ec36 in main (argc=3, argv=0x2f1c460) at main.c:223


Note that the function mentioned in the error message is not
anywhere in the stack trace, and that there was not any explicit
transaction started -- just a VACUUM command for the table, without
any BEGIN/COMMIT.


This is using source at commit 9faa6ae14f6098e4b55f0131f7ec2694a381fb87.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company