hi,
> "YAMAMOTO Takashi" <y...@mwd.biglobe.ne.jp> writes:
>> 9.2devel (2562dcea811eb642e1c5442e1ede9fe268278157)
>
>> ERROR: could not serialize access due to concurrent update
>> STATEMENT: UPDATE file SET atime = current_timestamp WHERE fileid = $1
>> TRAP: FailedAssertion("!(owner->nsnapshots == 0)", File: "resowner.c", Line:
>> 365)
>> LOG: server process (PID 16832) was terminated by signal 6: Abort trap
>
> There isn't terribly much we can do with this report unless you can
> provide a complete test case to reproduce it.
>
> regards, tom lane
after some investigation, i think it is triggered by protocol-level prepare
of ROLLBACK in an aborted transaction. does the following patch make sense?
YAMAMOTO Takashi
diff --git a/src/backend/utils/cache/plancache.c
b/src/backend/utils/cache/plancache.c
index 9cccc87..d1da7df 100644
--- a/src/backend/utils/cache/plancache.c
+++ b/src/backend/utils/cache/plancache.c
@@ -520,6 +520,7 @@ RevalidateCachedQuery(CachedPlanSource *plansource)
* don't have invalidatable plans, so we'd not get here for such a
* command.
*/
+ Assert(analyze_requires_snapshot(plansource->raw_parse_tree));
snapshot_set = false;
if (!ActiveSnapshotSet())
{
@@ -757,13 +758,11 @@ BuildCachedPlan(CachedPlanSource *plansource, List *qlist,
/*
* If a snapshot is already set (the normal case), we can just use
- * that for parsing/planning. But if it isn't, install one. Note: no
- * point in checking whether parse analysis requires a snapshot;
- * utility commands don't have invalidatable plans, so we'd not get
- * here for such a command.
+ * that for parsing/planning. But if it isn't, install one.
*/
snapshot_set = false;
- if (!ActiveSnapshotSet())
+ if (!ActiveSnapshotSet() &&
+ analyze_requires_snapshot(plansource->raw_parse_tree))
{
PushActiveSnapshot(GetTransactionSnapshot());
snapshot_set = true;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
