We have seen the same errors on our production system while loading and overlaying bib records. Our production system is running:

Evergreen 3.7.2
Postgres 9.6
Patch for bug 1947173 applied

Prior to 3.7.2, no deadlocks were logged. Since loading 3.7.2 with the additional patch, we are seeing deadlocks fairly regularly which are NOT related to running pingest.pl. Deadlocks are happening during normal record loading, adding and overlaying via the staff client.

Here's a snippet from the logs:

process 65396 detected deadlock while waiting for ShareLock on transaction 1126196004 after 1000.133 ms
DETAIL:  Process holding the lock: 67365. Wait queue: .
CONTEXT:  while updating tuple (355971,7) in relation "symspell_dictionary"
PL/pgSQL function search.symspell_build_and_merge_entries(text,text,text,boolean) line 34 at RETURN QUERY
SQL statement "SELECT * FROM search.symspell_build_and_merge_entries(new_value, search_class, old_value)"
PL/pgSQL function search.symspell_maintain_entries() line 17 at PERFORM
SQL statement "DELETE FROM metabib.identifier_field_entry WHERE source = 3798324"
[]) line 35 at EXECUTE
SQL statement "SELECT metabib.reingest_metabib_field_entries(NEW.id)"
PL/pgSQL function biblio.indexing_ingest_or_delete() line 55 at PERFORM
STATEMENT:  UPDATE biblio.record_entry
SET marc = '<?xml version="1.0"?>
<record xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.loc.gov/MARC21/slim" xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd"><leader>05691cam a2200625Ki 4500</leader><controlfield tag="001">3798324</controlfield><controlfield tag="003">NOBLE</controlfield><controlfield tag="005">20180905042051.7</controlfield><controlfield tag="006">m     o  d        </controlfield><controlfield tag="007">cr cnu---unuuu</controlfield><controlfield tag="008">140630r19861975enk     ob    000 0 eng d</controlfield><datafield tag="040" ind1=" " ind2=" "><subfield code="a">N$T</subfield><subfield code="b">eng</subfield><subfield code="e">rda</subfield><subfield code="e">pn</subfield><subfield code="c">N$T</subfield><subfield code="d">VLB</subfield><subfield code="d">YDXCP</subfield><subfield
code="d">EBLCP</subfield><subfield code="d">ICA</subfield><subfield code="d">AGLDB</subfield><subfield code="d">OCLCQ</subfield><subfield code="d">VTS</subfield></datafield><datafield tag="019" ind1=" " ind2=" "><subfield code="a">888549609</subfield><subfield code="a">907152912</subfield><subfield code="a">908511865</subfield><subfield code="a">923184802</subfield><subfield code="a">963324551</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="z">9780830897971</subfield><subfield code="q">(electronic bk.)</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="z">0830897976</subfield><subfield code="q">(electronic bk.)</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="z">0877842930</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="z">9780877842934</subfield></datafield><datafield
tag="020" ind1=" " ind2=" "><subfield code="z">0851107397</subfield><subfield code="q">(pbk. UK)</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="z">9780851107394</subfield><subfield code="q">(pbk. UK)</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="z">0877849250</subfield><subfield code="q">(set pbk.)</subfield></datafield><datafield tag="020" ind1=" " ind2=" "><subfield code="z">9780877849254</subfield><subfield code="q">(set pbk.)</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(OCoLC)882106606</subfield><subfield code="z">(OCoLC)888549609</sub:

<snip>

Changing importance to High as this is impacting normal workflows.