[BUGS] Bug with temporary child of a permanent table after recovery
Spotted by accident while working on a patch: Open psql and do: CREATE TABLE uctest(f1 int, f2 text); -- Create a temporary child of the permanent table CREATE TEMP TABLE ucchild () inherits (uctest); In another terminal: pg_ctl stop -m immediate pg_ctl start psql (9.3devel) Type "help" for help. postgres=# SELECT * FROM uctest; ERROR: could not open file "base/12030/t2_16392": No such file or directory This goes back to 9.1. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7752: FATAL btree error on PITR
On 12 December 2012 01:55, wrote: > The following bug has been logged on the website: > > Bug reference: 7752 > Logged by: Maciek Sakrejda > Email address: m.sakre...@gmail.com > PostgreSQL version: 9.1.6 > Operating system: Ubuntu 10.04 LTS 64-bit > Description: > > Ran into the following error in trying to perform a PITR: > > FATAL: btree level 66135134 not found in index "436254" > > This happened when the PITR was almost complete (judging by on-disk database > size). I guess this may be related to one of the index corruption issues > fixed in 9.1.7, but if that's the case, would it perhaps make sense to > complete the PITR without the corrupt index(es) and deal with the index > issue separately? Clearly, just a warning is dangerously likely to be > skipped, but maybe a mechanism like backup_label, that prevents normal > startup before the issue is resolved? Yes, I've thought about allowing recovery to skip corrupt indexes, but that feature hasn't been implemented yet. We'd need to track such things as recovery proceeds and then mark them as invalid when recovery completes. Patches welcome. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug with temporary child of a permanent table after recovery
Heikki Linnakangas writes: > Spotted by accident while working on a patch: > Open psql and do: > CREATE TABLE uctest(f1 int, f2 text); > -- Create a temporary child of the permanent table > CREATE TEMP TABLE ucchild () inherits (uctest); > In another terminal: > pg_ctl stop -m immediate > pg_ctl start > psql (9.3devel) > Type "help" for help. > postgres=# SELECT * FROM uctest; > ERROR: could not open file "base/12030/t2_16392": No such file or directory > This goes back to 9.1. I believe this used to work before Robert redesigned temp relations. The underlying physical file got removed during postmaster restart, but at this point the catalog entry for the temp table is still there, and the planner is failing to disregard it as intended. The problem is that the RELATION_IS_OTHER_TEMP macro #define RELATION_IS_OTHER_TEMP(relation) \ ((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP \ && (relation)->rd_backend != MyBackendId) is getting fooled by a chance collision of backend IDs --- that is, the failure only occurs in sessions with the same BackendId that the original table creator had. It worked before because the "is my temp table" test was based on whether the table belonged to myTempNamespace, which would be InvalidOid until the backend had started using the temp namespace --- and one of the things involved in that is to run around and clean out any leftover tables in that schema. I'm not sure where rd_backend gets set up, but maybe we can fix this by not allowing rd_backend to acquire a valid value unless we've begun using the temp namespace. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug with temporary child of a permanent table after recovery
I wrote:
> I'm not sure where rd_backend gets set up, but maybe we can fix this
> by not allowing rd_backend to acquire a valid value unless we've begun
> using the temp namespace.
The key bit of code seems to be this in RelationBuildDesc():
switch (relation->rd_rel->relpersistence)
...
case RELPERSISTENCE_TEMP:
if (isTempOrToastNamespace(relation->rd_rel->relnamespace))
relation->rd_backend = MyBackendId;
else
{
/*
* If it's a local temp table, but not one of ours, we have to
* use the slow, grotty method to figure out the owning
* backend.
*/
relation->rd_backend =
GetTempNamespaceBackendId(relation->rd_rel->relnamespace);
Assert(relation->rd_backend != InvalidBackendId);
}
where the second part of the if() will happily set rd_backend to
MyBackendId if that's what comes out of the namespace name, never
mind that we ought not to consider it "our" temp table.
The pre-9.1 coding in this area got it right:
relation->rd_istemp = relation->rd_rel->relistemp;
if (relation->rd_istemp)
relation->rd_islocaltemp =
isTempOrToastNamespace(relation->rd_rel->relnamespace);
else
relation->rd_islocaltemp = false;
There was no way to consider a temp table "ours" unless it satisfied
isTempOrToastNamespace.
Possibly we could reset rd_backend to InvalidBackendId here if the
computed value is equal to MyBackendId, but it seems a bit fragile.
That would prevent us from computing a correct pathname for the
underlying file --- not that that file should be there anymore,
but this could hinder relation creation for instance.
Perhaps a better idea is to not overload rd_backend to serve both
the "physical name of file" purpose and the "is it my temp table"
purpose. We could add an additional relcache field with the
three possible states "not temp, my temp, somebody else's temp"
and make sure that the third state gets selected when there's
a chance collision like this. Or resurrect the old rd_istemp and
rd_islocaltemp flags.
Thoughts?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Bug with temporary child of a permanent table after recovery
On Fri, 2012-12-14 at 17:56 -0500, Tom Lane wrote: > Perhaps a better idea is to not overload rd_backend to serve both > the "physical name of file" purpose and the "is it my temp table" > purpose. We could add an additional relcache field with the > three possible states "not temp, my temp, somebody else's temp" > and make sure that the third state gets selected when there's > a chance collision like this. Or resurrect the old rd_istemp and > rd_islocaltemp flags. > > Thoughts? Rather than bring back that flag, can we just use isTempOrToastNamespace within RELATION_IS_OTHER_TEMP? #define RELATION_IS_OTHER_TEMP(relation) \ ((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP \ && !isTempOrToastNamespace((relation)->rd_rel->relnamespace)) (I haven't analyzed the above code very carefully; it's just for illustration purposes). Regards, Jeff Davis -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7754: Contrib start scipt comment refers to dead URL
The following bug has been logged on the website: Bug reference: 7754 Logged by: Gavan Schneider Email address: pg-...@snkmail.com PostgreSQL version: 9.2.2 Operating system: OSX Description: FILE: postgresql-9.2.2/contrib/start-scripts/osx/PostgreSQL ; and many previous versions PBOBLEM: The comment: # For more information on Darwin/Mac OS X startup bundles, see this article: # # http://www.opensource.apple.com/projects/documentation/howto/html/SystemStarter_HOWTO.html # refers to a dead link. I wrote to Apple who confirmed it was dead, implicitly declined my request for a redirection, and suggested I report here. Suggest this bit of text be snipped as the underlying methodology has been deprecated for years, and is likely to be dropped soon. Specifically there seems little point educating those who don't already know this method. OBSERVATION: I am thinking this contribution should be enhanced/replaced with a method suitable for current versions of OSX? So far I have not found a working recipe for my situation (and I have tried quite a few) so feel poorly placed to offer anything just now. Happy to trial ideas as suggested. Esp. since I seem to have invented a 'tough' environment :( Could you point me to an active postgresql discussion of this, so I can get up to speed (still pretty new to the pg community). Many thanks. G -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
