Re: [BUGS] [GENERAL] cache lookup of relation 165058647 failed
temp tables don't use the shared buffer cache, how can this be related to the BG writer? Don't the system catalogs use the shared buffer cache? BEGIN; SELECT create_temp_table_func(); -- Inserts a row into pg_class via CREATE TEMP TABLE -- Do other stuff COMMIT; -- After the commit, the row is now visible to other backends -- disconnect -- If the delay between the disconnect and reconnect is small enough -- reconnect -- It's as though there is a race condition that allows the function -- pg_table_is_visible() to assert the "cache lookup of relation" -- error. BEGIN; SELECT create_temp_table_func(); -- Before the CREATE TEMP TABLE, I call /* SELECT TRUE FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relname = ''footmp''::TEXT AND c.relkind = ''r''::TEXT AND pg_catalog.pg_table_is_visible(c.oid); */ -- But the query fails My guess was that the series of events went something like: proc 0) COMMIT's and the row in pg_class is committed proc 1) bgwriter writer code removes a page for the cache proc 2) queries for the page [*] proc 1) writes it to disk proc 2) queries for the page [*] proc 1) sync's the fd [*] proc 2 queries for the page at either of these points In 7.4, there is no bgwriter or background process mucking with cache, Except for the checkpoint process, which does exactly the same as the bgwriter does, and ALL concurrent backends whenever they feel the need to evict a dirty buffer. Hrm... well, haven't the slightest idea what would be causing this then. About all I can say is that some problem does exist in HEAD that doesn't exist in REL7_4 that I'm able to tickle via temp tables. :-/ Because this is time sensitive, what debugging foo could I insert to get some useful diagnostic output? If it makes a difference if a pg_class page is dirty in the buffer or copied out to disk with respect to visibility rules of the tuples contained in it, then the whole thing is a way larger bug than the one in MIB. First of all, committed or not, a temp object from one session should NEVER be visible in any other. Hrm... well, I'm going to take my test scripts and reduce them down to a test case. For sure, there's something different in HEAD that's causing problems that are time sensitive. I've even thought about grabbing my camera and making a low res 320x200 movie of the test sequence. I went and ran script(1) on one of the runs for the sake of something. http://sean.chittenden.org/postgresql/pgsql-create-temp-bug- typescript.txt Any help or assistance is greatly appreciated, I'm not sure where to go from here. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] problem with instalation plpgsql on Mandrake
Hello I try install cvs version PostgreSQL on Mandrake 8.1. 7.4.2 I installed without problems, but when I tryed registration of plpgsql I get message ERROR: could not load library "/usr/lib/plpgsql.so:" /usr/lib/plpgsql.so: undefined symbol: MakeExprContext Can You Help me Thank You Pavel ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] problem with instalation plpgsql on Mandrake
Pavel Stehule <[EMAIL PROTECTED]> writes: > ERROR: could not load library "/usr/lib/plpgsql.so:" /usr/lib/plpgsql.so: > undefined symbol: MakeExprContext I think you've got the wrong version of plpgsql.so. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Killing the backends
Helvio Hild <[EMAIL PROTECTED]> writes: > llamados=> SELECT int8in(8); > server closed the connection unexpectedly This is fixed as of PG 7.3. It's not fixable in earlier releases because they don't have a type-safe way of declaring I/O functions. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] PostgreSQL 7.4.1 JDBC driver bug
PostgreSQL 7.4.1 JDBC driver bug
In the package
org.postgresql.geometric
the class PGcircle contains what I think is an
"oversight".
For classes in this package fields are declared
"public" allowing direct access. This is true for all classes execept
PGcircle where the radius field is declared without a modifier. This makes
the class unusable from a java program without modification, as no accessor
method is defined.
The source code reads
public class PGcircle extends PGobject implements
Serializable, Cloneable{ /* * This is the centre
point */ public PGpoint center;
/* * This is the radius
*/ double radius;
Hope you can fix this in a later
release,
Declan LynchTechnicianSchool of Control
Systems and Electrical EngineeringDublin Institute of TechnologyKevin
StreetDublin 8Ireland
e-mail: [EMAIL PROTECTED]Tel: +353 1
4024721Fax: +353 1 4024999--
This message has been scanned for content and viruses by the
DIT Information Services MailScanner Service,
and is believed to be clean.
http://www.dit.ie
[BUGS] Security Measures (SafeHarbor) (KMM82003618V76837L0KM)
Dear eBay member We recently noticed one or more attempts to log in to your eBay account from a foreign IP address and we have reasons to belive that your account was hijacked by a third party without your authorization. If you recently accessed your account while traveling,the unusual log in attempts may have been initiated by you. However,if you are the rightfull holder of the account, click on the link below, fill the form and then submit as we try to verify your identity. http://cgi3.ebay.com//aw-cgi/eBayISAPI.dll?VerifyIdentity&ssPageName= The log in attempt was made from: IP address: 205.188.209.166 ISP host: cache-dq04.proxy.aol.com If you choose to ignore our request,you leave us no choise but to temporaly suspend your account. We ask that you allow at least 72 hours for the case to be investigated and we strongly recommend not to make any changes to your account in that time. If you received this notice and you are not the authorized account holder, please be aware that it is in violation of eBay policy to represent oneself as another eBay user. Such action may also be in violation of local, national, and/or international law. eBay is committed to assist law enforcement with any inquires related to attempts to misappropriate personal information with the intent to commit fraud or theft. Information will be provided at the request of law enforcement agencies to ensure that perpetrators are prosecuted to the fullest extent of the law. *Please do not respond to this e-mail as your reply will not be received. Thanks for your patience as we work together to protect your account. Regards, Safeharbor Department eBay Inc.
[BUGS] Turkish locale bug
Hi everybody, Five years ago, i sent a patch for postgresql turkish locale patch, but nobody has taken it into consideration. Now, the source tree is totally different and pg team says they 'partially' fixed turkish locale problem. But it is still non-functional. I don't understand this, because the solution is very simple (at least, it WAS simple for version 6.5... I don't know if the source of the problem is the same now). The source o the problem is : In turkish alphabet, the lowercase of I is ı, not i. And, postgresql parser uses a locale-dependent version of lowercase function. When it encounters an INSERT, it converts it to ınsert, instead of insert... And it gives an error. The solution is very simple : Don't use a locale-dependent lowercase function in the keyword parsing process. Postgres team! Please, in the next minor release, fix this problem. Here, in Turkey, we want to use Postgres, but your attitude discourages us. If there is any subject that I may help, don't hesitate to write me... But anyway please answer me. Regards Ismail Kizir ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Bug in optimizer
Timo Nentwig wrote: This is very slow: SELECT urls.id FROM urls WHERE ( urls.id <> ALL (SELECT html.urlid FROM html) ); ...while this is quite fast: SELECT urls.id FROM urls WHERE ( NOT (EXISTS (SELECT html.urlid FROM tml WHERE ( html.urlid = urls.id ))) ); Are you using the version 7.4.x ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] Turkish locale bug
Hi, On Wed, 5 May 2004, Ismail Kizir wrote: > The solution is very simple : Don't use a locale-dependent lowercase > function in the keyword parsing process. Search the archives in -hackers -- with my name and Nicolai Tufar. This discussion has been made already. Also, there is a problem in glibc, for Turkish locale. Maybe this is another cause of the problem. -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.TDMSoft.com http://www.gunduz.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] [GENERAL] cache lookup of relation 165058647 failed
I'v find out that this error occurs in: dependency.c file 2004-04-26 11:09:34 ERROR: dependency.c 1621: cache lookup of relation 149064743 failed 2004-04-26 11:09:34 ERROR: Relation "tmp_table1" does not exist 2004-04-26 11:09:34 ERROR: Relation "tmp_table1" does not exist in getRelationDescription(StringInfo buffer, Oid relid) function. Any ideas what can cause this errors. Me too. But, I am suspecting that it's a race condition with the new background writer code. I've started testing a new database design and was able to reproduce this on my laptop nearly 90% of the time, but could only reproduce it about 10% of the time on my production databases until I figured out what the difference was, fsync. temp tables don't use the shared buffer cache, how can this be related to the BG writer? Don't the system catalogs use the shared buffer cache? BEGIN; SELECT create_temp_table_func(); -- Inserts a row into pg_class via CREATE TEMP TABLE -- Do other stuff COMMIT; -- After the commit, the row is now visible to other backends -- disconnect -- If the delay between the disconnect and reconnect is small enough -- reconnect -- It's as though there is a race condition that allows the function -- pg_table_is_visible() to assert the "cache lookup of relation" -- error. BEGIN; SELECT create_temp_table_func(); -- Before the CREATE TEMP TABLE, I call /* SELECT TRUE FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relname = ''footmp''::TEXT AND c.relkind = ''r''::TEXT AND pg_catalog.pg_table_is_visible(c.oid); */ -- But the query fails My guess was that the series of events went something like: proc 0) COMMIT's and the row in pg_class is committed proc 1) bgwriter writer code removes a page for the cache proc 2) queries for the page [*] proc 1) writes it to disk proc 2) queries for the page [*] proc 1) sync's the fd [*] proc 2 queries for the page at either of these points In 7.4, there is no bgwriter or background process mucking with cache, which is why this works 100% of the time. In 7.5, however, there's a 200ms gap where a race condition appears and pg_table_is_visible() fails its PointerIsValid() check. If I put a sleep in, the sleep gives the bgwriter enough time to commit the pages to disk so that the queries for the page happen after the fd's been sync()'ed. I have no other clue as to why this would be happening though, so believe me when I say, I could very well be quite wrong but this is my best, quasi-educated/grep(1)'ed guess. -sc -- Sean Chittenden ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
