Re: [PERFORM] How much memory is PostgreSQL using
Le 02/04/2010 22:10, Campbell, Lance a écrit : Greg, Thanks for your help. 1) How does the number of buffers provided by pg_buffercache compare to memory (buffers * X = Y meg)? 1 buffer is 8 KB. 2) Is there a way to tell how many total buffers I have available/max? With pg_buffercache, yes. SELECT count(*) FROM pg_buffercache WHERE relfilenode IS NOT NULL; should give you the number of non-empty buffers. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
[PERFORM] ERROR: cache lookup failed for relation X
Hi All, I am facing the error cache lookup failed for relation X in Postgres-8.4.2 version. As you all know, its a reproducable and below is the example. This can be generated with two sessions; Am opening two sessions here Session A and Session B Session A = step 1 - creating the table postgres=# create table cache(id integer); step 2 - Create the trigger and the function on particular table postgres=# CREATE FUNCTION cachefunc() RETURNS trigger AS $$ BEGIN RETURN NEW; END; $$ LANGUAGE plpgsql; postgres=# CREATE TRIGGER cachetrig BEFORE INSERT ON cache FOR EACH ROW EXECUTE PROCEDURE cachefunc(); Step 3 - Inserting a row in a table postgres=# insert into cache values (1); Step 4 - Droping the table in BEGIN block and issuing the same drop in another session B postgres=# begin; postgres=# drop table cache; step 5 - Open the second session B and issue the same command postgres=# drop table cache; --- In session B, this will wait untill commit is issued by the Session A. step 6 - Issue the commit in Session A postgres=# commit; Step -7 now we can the see the error in the session B ERROR: cache lookup failed for relation X Could plese tell me, why this is generated and what is the cause. Thanks in advance Regards Raghavendra
Re: [PERFORM] [GENERAL] ERROR: cache lookup failed for relation X
Because You dropped/deleted the table cache in Session A. The simplest way to look at it is Session B was lock out when the Drop table command was issued from Session A. Now when session B finally got its chance to drop/delete the table it was already gone . What kind error were you expecting from Postgresql to Return when it can't find the table??? In the future please don't cross post to multiple lists. Message from mailto:raagavendra@gmail.com raghavendra t raagavendra@gmail.com at 04-03-2010 10:08:11 PM -- step 6 - Issue the commit in Session A postgres=# commit; Step -7 nowwe can the see the error in the session B ERROR: cache lookup failed for relation X Could plese tell me, why this is generated and what is the cause. Thanks in advance Regards Raghavendra All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored. CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately. Thank you.
Re: [PERFORM] [GENERAL] ERROR: cache lookup failed for relation X
raghavendra t raagavendra@gmail.com writes: I am facing the error cache lookup failed for relation X in Postgres-8.4.2 [ when dropping the same table concurrently in two sessions ] Could plese tell me, why this is generated and what is the cause. From the perspective of session B, the table disappeared after it had already found the table in the catalogs and obtained a lock on it. This is not readily distinguishable from a serious problem such as catalog corruption. While we could play dumb and just issue a table does not exist message as though we'd never found it in the catalog at all, that behavior could mask real problems, so it seems better to not try to hide that something unusual happened. In general I would say that an application that is trying to do this has got its own problems anyway --- how do you know which version of the table you're dropping, and that that's the right thing? regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] [GENERAL] ERROR: cache lookup failed for relation X
Hi Justin, Thank you for your reply.. In the future please don't cross post to multiple lists. Appoligies for it... Regards Raghavendra On Sat, Apr 3, 2010 at 10:34 PM, jus...@magwerks.com jus...@magwerks.comwrote: Because You dropped/deleted the table cache in Session A. The simplest way to look at it is Session B was lock out when the Drop table command was issued from Session A. Now when session B finally got its chance to drop/delete the table it was already gone . What kind error were you expecting from Postgresql to Return when it can't find the table??? In the future please don't cross post to multiple lists. Message from raghavendra t raagavendra@gmail.comraagavendra@gmail.comat 04-03-2010 10:08:11 PM -- step 6 - Issue the commit in Session A postgres=# commit; Step -7 now we can the see the error in the session B ERROR: cache lookup failed for relation X Could plese tell me, why this is generated and what is the cause. Thanks in advance Regards Raghavendra All legitimate Magwerks Corporation quotations are sent in a .PDF file attachment with a unique ID number generated by our proprietary quotation system. Quotations received via any other form of communication will not be honored. CONFIDENTIALITY NOTICE: This e-mail, including attachments, may contain legally privileged, confidential or other information proprietary to Magwerks Corporation and is intended solely for the use of the individual to whom it addresses. If the reader of this e-mail is not the intended recipient or authorized agent, the reader is hereby notified that any unauthorized viewing, dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and destroy all occurrences of this e-mail immediately. Thank you.
