NotificationsYou must be signed in to change notification settings
Fork5
Star26

Commite518fa7

committed

Cope with heap_fetch failure while locking an update chain

The reason for the fetch failure is that the tuple was removed becauseit was dead; so the failure is innocuous and can be ignored. Moreover,there's no need for further work and we can return success to the callerimmediately. EvalPlanQualFetch is doing something very similar to thisalready.Report and test case from Andres Freund in20131124000203.GA4403@alap2.anarazel.de

1 parentb6ecde8 commite518fa7Copy full SHA for e518fa7

File tree

1 file changed

+10

-1

lines changed

src/backend/access/heap
- heapam.c

1 file changed

+10

-1

lines changed

`‎src/backend/access/heap/heapam.c`

Lines changed: 10 additions & 1 deletion

Original file line number	Diff line number	Diff line change
`@@ -4824,7 +4824,16 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid,`
`4824`	`4824`	`ItemPointerCopy(&tupid,&(mytup.t_self));`
`4825`	`4825`
`4826`	`4826`	`if (!heap_fetch(rel,SnapshotAny,&mytup,&buf, false,NULL))`
`4827`		`-elog(ERROR,"unable to fetch updated version of tuple");`
	`4827`	`+{`
	`4828`	`+/*`
	`4829`	`+ * if we fail to find the updated version of the tuple, it's`
	`4830`	`+ * because it was vacuumed/pruned away after its creator`
	`4831`	`+ * transaction aborted. So behave as if we got to the end of the`
	`4832`	`+ * chain, and there's no further tuple to lock: return success to`
	`4833`	`+ * caller.`
	`4834`	`+ */`
	`4835`	`+returnHeapTupleMayBeUpdated;`
	`4836`	`+}`
`4828`	`4837`
`4829`	`4838`	`l4:`
`4830`	`4839`	`CHECK_FOR_INTERRUPTS();`

0 commit comments

Comments

(0)

Movatterモバイル変換

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Commite518fa7

File tree

1 file changed

1 file changed

`‎src/backend/access/heap/heapam.c`

0 commit comments