Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 36,070
    • Issues 36,070
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 1,299
    • Merge Requests 1,299
  • Requirements
    • Requirements
    • List
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #23211

Closed
Open
Created Jul 10, 2018 by Stan Hu@stanhuOwner

Executing a backup with PgBouncer can cause a full site outage

ZD: https://gitlab.zendesk.com/agent/tickets/99873

Customer has an HA setup with PgBouncer. Upon running the backup Rake task, customer saw these types of errors:

ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR:  relation "keys" does not exist
LINE 1: SELECT  "keys".* FROM "keys" WHERE "keys"."fingerprint" = 'b...

It turns out PostgreSQL 9.6.8 changed the behavior of pg_dump to set a null search path and explicitly include the schema in every SQL query to address CVE-2018-1058 (Uncontrolled search path element in pg_dump and other client applications). When Rails uses the connection, the SQL query fails because the public schema isn't in the search path.

The workaround is to bypass PgBouncer and conduct a backup directly.

Discourse worked around this by adding configuration options to allow the backup task to specify a separate database connection for backups. We should consider doing this too.

Related links:

  • https://www.postgresql.org/about/news/1834/
  • https://github.com/pgbouncer/pgbouncer/issues/246#issuecomment-383582053
  • https://meta.discourse.org/t/changes-introduced-in-postgresql-9-5-12-and-10-3-cause-backup-related-failures/82555/3
  • https://github.com/discourse/discourse/commit/a89f3160a53081adbd2c05c4b3b146414500248a

/cc: @collen, @dblessing, @yorickpeterse

Assignee
Assign to
13.6
Milestone
13.6 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab#23211