Incorrect format on config.metabib_field insert results in segmentation fault

Bug #1764542 reported by Jeff Davis
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
High
Unassigned
3.0
Won't Fix
Undecided
Unassigned
3.1
Fix Released
Undecided
Unassigned

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/1100.data.display-field-seed-data.sql 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.

Tags: pullrequest
Galen Charlton (gmc)
Changed in evergreen:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Galen Charlton (gmc)
milestone: none → 3.1.2
Revision history for this message
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
Revision history for this message
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
Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.