agora inbox for [email protected]help / color / mirror / Atom feed
Re: clog segment truncation 3+ messages / 3 participants [nested] [flat]
* Re: clog segment truncation @ 2025-11-10 14:35 Smolkin Grigory <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Smolkin Grigory @ 2025-11-10 14:35 UTC (permalink / raw) To: Matheus Alcantara <[email protected]>; +Cc: [email protected] > On Mon Nov 10, 2025 at 9:29 AM -03, Smolkin Grigory wrote: > > Hello, hackers! > > > > I`m currently investigating the case of one of our PostgreSQL instance > > having started issuing error messages about missing clog segment: > > ERROR: could not access status of transaction 1550558894 > > DETAIL: Could not open file "pg_xact/05C6": No such file or directory. > > > Is this error happening with the LISTEN/NOTIFY? There is a discussion > going on [1] that aims to fix this issue for the LISTEN/NOTIFY. No, LISTEN/NOTIFY are not used. So do you have a step by step to reproduce the issue? Unfortunately, no. > Or at least some more information about what the server was running that > caused the > error? By the looks of it, nothing special, really, just plain inserts and occasional index-scan reads (tuple (5456224,2) looks like it was read by index-scan, because it has HEAP_XMIN_COMMITTED stamped on). Instance wasn't subjected to power outages, kernel crashes or hardware issues. On Mon, Nov 10, 2025 at 4:43 PM Matheus Alcantara <[email protected]> wrote: > On Mon Nov 10, 2025 at 9:29 AM -03, Smolkin Grigory wrote: > > So is it possible that either all_frozen bit was set incorrectly or > wansn't > > unset when tuples were created? > > I will be happy to provide any additional information if required. > > PostgreSQL version: 15.6, data_checksums: on > > > Actually the 15.6 is quite old. > It is, but I didn't see any fixes that can possibly be related to this case, but maybe I've missed something. > > I didn't find any specific release note about clog truncation but you > are missing some important fixes though. > > There is this fix [1] on 15.8 but I'm not sure if it's fully related > with your issue faced here. > > [1] > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=c809a2b2d > > Looks like it is more about multi-xact truncation, so I'm also not sure. ^ permalink raw reply [nested|flat] 3+ messages in thread
* BUG #19543: ALTER RULE ... RENAME accepts reserved name "_RETURN" for a non-view rule; breaks a restored dump @ 2026-07-03 23:26 PG Bug reporting form <[email protected]> 2026-07-04 14:37 ` Re: BUG #19543: ALTER RULE ... RENAME accepts reserved name "_RETURN" for a non-view rule; breaks a restored dump Tom Lane <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: PG Bug reporting form @ 2026-07-03 23:26 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] The following bug has been logged on the website: Bug reference: 19543 Logged by: Adam Pickering Email address: [email protected] PostgreSQL version: 18.4 Operating system: Debian (using an official postgres docker image) Description: PostgreSQL version Official postgres container from dockerhub (Debian 18.4-1.pgdg13+1) on aarch64-unknown-linux-gnu, compiled by gcc (Debian 14.2.0-19) 14.2.0, 64-bit (also observed on 17.10 and current 14) Platform aarch64, Debian 13-based (official postgres:18 image), Linux 6.6, default server config. Description CREATE RULE rejects the name _RETURN for a rule that is not an ON SELECT rule. ALTER RULE ... RENAME does not: an existing ON UPDATE/INSERT/DELETE rule on an ordinary table can be renamed to _RETURN and the server accepts it. A subsequent pg_dump emits a CREATE RULE "_RETURN" ... statement the server rejects on reload, so the database can be dumped but not restored. Exact steps to reproduce (run with psql -X, no ~/.psqlrc) CREATE TABLE t (a int); CREATE RULE r AS ON UPDATE TO t DO ALSO SELECT 1; -- rejected CREATE RULE "_RETURN" AS ON UPDATE TO t DO ALSO SELECT 1; -- accepted; this is the bug ALTER RULE r ON t RENAME TO "_RETURN"; then: $ createdb fresh $ pg_dump -t t --no-owner | psql -X -d fresh -v ON_ERROR_STOP=1 Output I got: CREATE TABLE CREATE RULE ERROR: 42P17: non-view rule for "t" must not be named "_RETURN" LOCATION: DefineQueryRewrite, rewriteDefine.c:456 ALTER RULE The CREATE RULE "_RETURN" is rejected (expected); the ALTER RULE ... RENAME TO "_RETURN" reports ALTER RULE, i.e. it succeeds. pg_dump then produces CREATE RULE "_RETURN" AS ON UPDATE TO public.t DO SELECT 1 ..., and reloading it fails with the same 42P17 error. Output I expected: ALTER RULE ... RENAME TO "_RETURN" rejected the same way CREATE RULE rejects it, so _RETURN can only ever be a view's ON SELECT rule and any relation that dumps cleanly can be reloaded. Context The guard on CREATE RULE was added deliberately (commit by Tom Lane, released in 14.3 / 13.7 / 12.11 / 11.16 / 10.23, "Disallow rules named _RETURN that are not ON SELECT"; the in-tree comment states it "prevents accidentally or maliciously replacing a view's ON SELECT rule with some other kind of rule"). ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #19543: ALTER RULE ... RENAME accepts reserved name "_RETURN" for a non-view rule; breaks a restored dump 2026-07-03 23:26 BUG #19543: ALTER RULE ... RENAME accepts reserved name "_RETURN" for a non-view rule; breaks a restored dump PG Bug reporting form <[email protected]> @ 2026-07-04 14:37 ` Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tom Lane @ 2026-07-04 14:37 UTC (permalink / raw) To: [email protected]; +Cc: [email protected] PG Bug reporting form <[email protected]> writes: > CREATE RULE rejects the name _RETURN for a rule that is not an ON SELECT > rule. ALTER RULE ... RENAME does not: an existing ON UPDATE/INSERT/DELETE > rule on an ordinary table can be renamed to _RETURN and the server accepts > it. Good catch, will fix. While we're here, I'm tempted to discard the obsolete logic in CREATE RULE's implementation of a related check: /* * ... and finally the rule must be named _RETURN. */ if (strcmp(rulename, ViewSelectRuleName) != 0) { /* * In versions before 7.3, the expected name was _RETviewname. For * backwards compatibility with old pg_dump output, accept that * and silently change it to _RETURN. Since this is just a quick * backwards-compatibility hack, limit the number of characters * checked to a few less than NAMEDATALEN; this saves having to * worry about where a multibyte character might have gotten * truncated. */ if (strncmp(rulename, "_RET", 4) != 0 || strncmp(rulename + 4, RelationGetRelationName(event_relation), NAMEDATALEN - 4 - 4) != 0) ereport(ERROR, (errcode(ERRCODE_INVALID_OBJECT_DEFINITION), errmsg("view rule for \"%s\" must be named \"%s\"", RelationGetRelationName(event_relation), ViewSelectRuleName))); We discarded compatibility with pre-7.3 dump files some time ago (notably in e58a59975 and adjacent commits), but this small detail wasn't noticed at the time. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-07-04 14:37 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-10 14:35 Re: clog segment truncation Smolkin Grigory <[email protected]> 2026-07-03 23:26 BUG #19543: ALTER RULE ... RENAME accepts reserved name "_RETURN" for a non-view rule; breaks a restored dump PG Bug reporting form <[email protected]> 2026-07-04 14:37 ` Re: BUG #19543: ALTER RULE ... RENAME accepts reserved name "_RETURN" for a non-view rule; breaks a restored dump Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox