FS#45071 - [postgresql] could not access status of transaction after upgrade to 9.4.2

Attached to Project: Arch Linux
Opened by Andrew Gaydenko (student975) - Sunday, 24 May 2015, 18:36 GMT
Last edited by Dan McGee (toofishes) - Monday, 25 May 2015, 20:52 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Dan McGee (toofishes)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

After today upgrade I have got:

май 24 17:42:34 jazz systemd[1]: Stopping PostgreSQL database server...
май 24 17:42:35 jazz systemd[1]: Stopped PostgreSQL database server.
май 24 17:42:38 jazz systemd[1]: Starting PostgreSQL database server...
май 24 17:42:38 jazz postgres[11892]: LOG: database system was shut down at 2015-05-24 17:42:34 MSK
май 24 17:42:38 jazz postgres[11892]: FATAL: could not access status of transaction 1
май 24 17:42:38 jazz postgres[11892]: DETAIL: Could not open file "pg_multixact/offsets/0000": No such file or directory.
май 24 17:42:38 jazz postgres[11892]: LOG: startup process (PID 11898) exited with exit code 1
май 24 17:42:38 jazz postgres[11892]: LOG: aborting startup due to startup process failure
май 24 17:42:43 jazz postgres[11892]: pg_ctl: could not start server
май 24 17:42:43 jazz systemd[1]: postgresql.service: control process exited, code=exited status=1
май 24 17:42:43 jazz systemd[1]: Failed to start PostgreSQL database server.
май 24 17:42:43 jazz systemd[1]: Unit postgresql.service entered failed state.
май 24 17:42:43 jazz systemd[1]: postgresql.service failed.

I use custom PGROOT:

~ $ cat /etc/systemd/system/postgresql.service
[Unit]
Description=PostgreSQL database server
After=network.target

[Service]
Type=forking
TimeoutSec=120
User=postgres
Group=postgres

Environment=PGROOT=/wrk/usr/pg

SyslogIdentifier=postgres
PIDFile=/var/lib/postgres/data/postmaster.pid

ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGROOT}/data
ExecStart= /usr/bin/pg_ctl -s -D ${PGROOT}/data start -w -t 120
ExecReload=/usr/bin/pg_ctl -s -D ${PGROOT}/data reload
ExecStop= /usr/bin/pg_ctl -s -D ${PGROOT}/data stop -m fast

# Due to PostgreSQL's use of shared memory, OOM killer is often overzealous in
# killing Postgres, so adjust it downward
OOMScoreAdjust=-200

# Additional security-related features
PrivateTmp=true
ProtectSystem=full
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

That file is indeed absent:

# ls /wrk/usr/pg/data/pg_multixact/offsets/*
/wrk/usr/pg/data/pg_multixact/offsets/0069
This task depends upon

Closed by  Dan McGee (toofishes)
Monday, 25 May 2015, 20:52 GMT
Reason for closing:  Upstream
Comment by Andrew Gaydenko (student975) - Sunday, 24 May 2015, 21:09 GMT
pg_resetxlog (used without or with -f option) completes successfully, but doesn't help: on service start the same error takes place.
Comment by Dan McGee (toofishes) - Monday, 25 May 2015, 15:54 GMT
Is everyone having this issue? I didn't have a problem on either of my two installations.

From the release notes:

For users of PostgreSQL versions 9.3 or 9.4, this release fixes a problem where the database will fail to protect against "multixact wraparound", resulting in data corruption or loss. Users with a high transaction rate (1 million or more per hour) in a database with many foreign keys are especially vulnerable. We strongly urge all users of 9.4 and 9.3 to update their installations in the next few days.
Comment by Andrew Gaydenko (student975) - Monday, 25 May 2015, 15:59 GMT
It was just minor 9.4.1-1 -> 9.4.2-1 upgrade, and the database hasn't got any noticeable loading as far as it runs on a workstation for developer. So I'm ready to reinit a database, but am in doubt would the issue can be important for somebody else.
Comment by Dan McGee (toofishes) - Monday, 25 May 2015, 16:19 GMT
You might want to bring this up on the Postgres mailing lists or see if anyone else is having this problem. We didn't change any build options from 9.4.1 to 9.4.2, so I am not totally certain what could be causing this kind of thing.
Comment by Andrew Gaydenko (student975) - Monday, 25 May 2015, 16:20 GMT
OK, let's close the task for now.

Loading...