Merge pull request #511 from the-luap/fix/install-postgres-log-noise

fix(install): silence clean-install postgres log noise (#484)
This commit is contained in:
Paul Nothaft
2026-05-17 00:52:48 +02:00
committed by GitHub
3 changed files with 83 additions and 12 deletions
@@ -83,11 +83,15 @@ async function up() {
});
}
// Add indexes if they don't exist
// Add indexes if they don't exist. backup_runs (created in 029) tracks
// chronology via `started_at` — the original `created_at` reference
// here was a bug that emitted a "column does not exist" ERROR in the
// postgres log on every fresh install (silently caught below). See
// migration 105 for the matching back-fix on already-applied installs.
try {
await db.raw('CREATE INDEX IF NOT EXISTS idx_backup_runs_mode_status ON backup_runs(backup_mode, status)');
await db.raw('CREATE INDEX IF NOT EXISTS idx_backup_runs_parent ON backup_runs(parent_backup_id)');
await db.raw('CREATE INDEX IF NOT EXISTS idx_backup_runs_created_mode ON backup_runs(created_at, backup_mode)');
await db.raw('CREATE INDEX IF NOT EXISTS idx_backup_runs_started_mode ON backup_runs(started_at, backup_mode)');
} catch (error) {
console.log('Note: Some indexes may already exist, continuing...');
}
@@ -144,16 +148,17 @@ async function up() {
});
}
// Add composite indexes for common query patterns
// Add composite indexes for common query patterns. Same `started_at`
// correction as above — `created_at` doesn't exist on backup_runs.
try {
await db.raw(`
CREATE INDEX IF NOT EXISTS idx_backup_runs_recent_successful
ON backup_runs(created_at DESC)
CREATE INDEX IF NOT EXISTS idx_backup_runs_recent_successful
ON backup_runs(started_at DESC)
WHERE status = 'completed' AND backup_mode = 'full';
`);
await db.raw(`
CREATE INDEX IF NOT EXISTS idx_backup_runs_incremental_chain
ON backup_runs(parent_backup_id, created_at)
CREATE INDEX IF NOT EXISTS idx_backup_runs_incremental_chain
ON backup_runs(parent_backup_id, started_at)
WHERE backup_mode = 'incremental';
`);
} catch (error) {
@@ -194,10 +199,13 @@ async function down() {
});
}
// Drop indexes
// Drop indexes. `idx_backup_runs_created_mode` is the legacy name
// shipped by an earlier revision of this migration; kept in the drop
// list so a down() against any historic state cleans up either name.
try {
await db.raw('DROP INDEX IF EXISTS idx_backup_runs_mode_status');
await db.raw('DROP INDEX IF EXISTS idx_backup_runs_parent');
await db.raw('DROP INDEX IF EXISTS idx_backup_runs_started_mode');
await db.raw('DROP INDEX IF EXISTS idx_backup_runs_created_mode');
} catch (error) {
// Ignore errors if indexes don't exist
@@ -0,0 +1,55 @@
/**
* Migration: back-fix the backup_runs indexes that migration 035 tried to
* create on the nonexistent `created_at` column (#484).
*
* On Postgres, 035's `CREATE INDEX ... ON backup_runs(created_at, ...)`
* statements raised `column "created_at" does not exist`, which was caught
* silently by the wrapping try/catch — so the migration "succeeded" but the
* indexes never got created. Fresh installs saw the ERROR in the postgres
* log; existing installs simply ran without those indexes.
*
* 035 has now been corrected to use `started_at` (the column that does
* exist on backup_runs and carries the same chronological semantics).
* This migration creates the same indexes idempotently for any deployment
* whose 035 silently failed — no-op on fresh installs because 035 already
* built them.
*
* SQLite: partial indexes (`WHERE …`) work but cross-table semantics differ
* slightly from Postgres; we still emit them because the only consumer is
* the backup-history query in `backupService` and it issues identical SQL
* across both backends.
*/
exports.up = async function(knex) {
if (!(await knex.schema.hasTable('backup_runs'))) return;
if (!(await knex.schema.hasColumn('backup_runs', 'started_at'))) return;
// Plain composite index — matches the corrected statement in 035.
await knex.raw(
'CREATE INDEX IF NOT EXISTS idx_backup_runs_started_mode ON backup_runs(started_at, backup_mode)'
);
// Partial indexes only get created if backup_mode exists (035 added it).
if (!(await knex.schema.hasColumn('backup_runs', 'backup_mode'))) return;
await knex.raw(`
CREATE INDEX IF NOT EXISTS idx_backup_runs_recent_successful
ON backup_runs(started_at DESC)
WHERE status = 'completed' AND backup_mode = 'full'
`);
if (await knex.schema.hasColumn('backup_runs', 'parent_backup_id')) {
await knex.raw(`
CREATE INDEX IF NOT EXISTS idx_backup_runs_incremental_chain
ON backup_runs(parent_backup_id, started_at)
WHERE backup_mode = 'incremental'
`);
}
};
exports.down = async function(knex) {
if (!(await knex.schema.hasTable('backup_runs'))) return;
await knex.raw('DROP INDEX IF EXISTS idx_backup_runs_started_mode');
await knex.raw('DROP INDEX IF EXISTS idx_backup_runs_recent_successful');
await knex.raw('DROP INDEX IF EXISTS idx_backup_runs_incremental_chain');
};
+12 -4
View File
@@ -126,18 +126,26 @@ async function runMigrations() {
const hasActivityLogsTable = await db.schema.hasTable('activity_logs');
// Get applied migrations
const appliedMigrations = await db('migrations').select('filename');
const appliedFilenames = appliedMigrations.map(m => m.filename);
let appliedMigrations = await db('migrations').select('filename');
let appliedFilenames = appliedMigrations.map(m => m.filename);
// Check if this is a new deployment
// It's new if no essential tables exist OR no migrations have been applied
const hasEssentialTables = hasEventsTable && hasPhotosTable && hasAdminTable && hasActivityLogsTable;
const isDatabaseEmpty = !hasEventsTable && !hasPhotosTable && !hasAdminTable && !hasActivityLogsTable;
const isNewDeployment = isDatabaseEmpty || (appliedFilenames.length === 0 && !hasEssentialTables);
// Only detect existing schema for truly existing deployments
if (!isNewDeployment) {
await detectExistingSchema();
// detectExistingSchema may have inserted rows into the migrations
// table (e.g. for 004_add_categories_and_cms.js when photo_categories
// already exists). Re-query so the iteration below sees the up-to-date
// applied set — otherwise the loop attempts those migrations again,
// their tx-internal `insert into migrations` conflicts, and postgres
// logs a "duplicate key" ERROR on every fresh-after-partial install.
appliedMigrations = await db('migrations').select('filename');
appliedFilenames = appliedMigrations.map(m => m.filename);
}
// Get migration files from appropriate directories