Incorrect format on config.metabib_field insert results in segmentation fault

Bug #1764542 reported by Jeff Davis on 2018-04-16
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

EG 3.1

During an upgrade to EG 3.1.0, a number of new rows with mods33 xpath values are inserted into config.metabib_field by update 1100. However, the insert statements do not specify a value for the format column. On a system where the default format value is something other than mods33, the rows will be inserted successfully, but any subsequent attempt to ingest a MARC record results in a segmentation fault.

How to test:

1. Create an EG 3.0.6 database.
2. ALTER TABLE config.metabib_field ALTER COLUMN format SET DEFAULT 'mods32'::TEXT;
3. Upgrade the database to 3.1.0.
4. UPDATE config.internal_flag SET enabled = TRUE WHERE name = 'ingest.reingest.force_on_same_marc';
5. UPDATE biblio.record_entry SET id = id WHERE id = 1;

The final update fails and the database connection is lost; other connections to the same cluster may also be affected. Postgres logs and dmesg show a segfault.

Most users will never run into this problem, since the default cmf format was changed to mods33 way back in 2009. But a proper database update script was never created for that change, and certain very old EG installs may still have mods32 as the default.

I propose several fixes:

1. Ensure the default value for config.metabib_field.format is set to mods33.
2. Modify the rows inserted by db update 1100 to ensure they use the correct format value.
3. In future, always specify a format value when inserting new rows into config.metabib_field.

I'm not sure whether upgrade/ and version-upgrade/3.0.6-3.1.0-upgrade-db.sql should be modified, or if making the changes via further upgrade scripts is good enough.

Galen Charlton (gmc) on 2018-04-20
Changed in evergreen:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Galen Charlton (gmc)
milestone: none → 3.1.2
Bill Ott (bott) wrote :

I've just come across this as well. Excellent description, and not surprising considering our database epoch is 2008.

I eliminated the segfaults by updating with:
update config.metabib_field set xpath=regexp_replace(xpath,'mods32','mods33','g') where xpath ~ 'mods32';

Changed in evergreen:
milestone: 3.1.2 → 3.1.3
Chris Sharp (chrissharp123) wrote :
tags: added: pullrequest
Changed in evergreen:
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
milestone: 3.1.3 → 3.1.4
Changed in evergreen:
milestone: 3.1.4 → 3.1.5
Changed in evergreen:
milestone: 3.1.5 → 3.1.6
Changed in evergreen:
milestone: 3.1.6 → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Ben Shum (bshum) wrote :

Seems like a simple preventative measure. Added to master and backported to rel_3_2 and rel_3_1. Thanks Chris.

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers