Re: [BUGS] Installation fails for postgresql-8.0.0-beta4 on Windo
FYI: I've been working off-list with Mehul to solve this, and we've pinpointed the reason. The affected machine had the "INTERACTIVE USERS" pseudo-group in "Power Users". Another group we have to check for in the next version of the installer, and I'll update the FAQ with this. (Previously we checked for Users, Authenticated Users and Everyone). //Magnus > -Original Message- > From: Mehul Doshi-A20614 [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 02, 2004 9:45 AM > To: Magnus Hagander; [EMAIL PROTECTED] > Subject: RE: [BUGS] Installation fails for > postgresql-8.0.0-beta4 on Windo > > Hi, > > Magnus, thanks for replying. We believe that we have followed > the given instructions all the way. > I have taken snapshots of entire installation and compiled > into a document (zipped ~ 500kb)which I wish to send across. > These contain the snapshots of the "postgres" user created > and it's properties. > > However since the issue might not be relevant to all, I would > appreciate if I can send it to one person rather than to the > whole list. Magnus can I send it to you? > > Thanks once again for your response. Awaiting a reply soon. > > Thanks & Regards, > Mehul > > > -Original Message- > From: Magnus Hagander [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 01, 2004 3:51 PM > To: Mehul Doshi-A20614; [EMAIL PROTECTED] > Subject: RE: [BUGS] Installation fails for > postgresql-8.0.0-beta4 on Windo > > > Yes. I have done this at least 50 times with no issues. Using > a local service account. > > Have you followed the instructions in questino 3.3 on > http://pginstaller.projects.postgresql.org/FAQ_windows.html ? > > My guess is that you have some rule somewhere (be it local or > using Group Policy) that adds Users or Authenticated Users or > similar to the Power Users or Administrators group, perhaps > with indirection. Or some other evil along that line. > > //Magnus > > > > -Original Message- > > > > Hi, > > > > I and my colleagues are clearly able to install the beta 5 > > version on Windows 2000. But when the same procedure is > > followed for Windows XP Professional, it fails as is detailed > > my previous posts. We have tried it on 4-5 different systems > > and everywhere the result is the same. > > > > Can somebody who has installed on Windows XP Professional > > system which is in a domain please reply as to what steps > > change to get this working. > > > > Thanks & Regards, > > Mehul > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Mehul > > Doshi-A20614 > > Sent: Monday, November 29, 2004 1:52 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [BUGS] Installation fails for > > postgresql-8.0.0-beta4 on Windo > > > > > > Hi, > > > > A further clue that can help to resolve this bug: > > > > I tried to install it on Windows 2000 & it works fine. So I > > think the issue might be only for Windows XP Professional systems. > > > > Regards, > > Mehul > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Mehul > > Doshi-A20614 > > Sent: Thursday, November 25, 2004 2:31 PM > > To: [EMAIL PROTECTED] > > Subject: [BUGS] Installation fails for postgresql-8.0.0-beta4 > > on WindowsXP SP1 > > > > > > > > Hi, > > > > I am trying to install the 8.0 beta4 version for Windows onto > > my system and facing an error which I can't fix. > > > > System: Windows XP, Sevice Pack 1 > > > > I am an admin on my system, but a regular user on a domain. I > > have created a non-admin user named "postgres" which is a > > member of the "Users" group (Restricted Users). > > > > I have run the entire installation in exactly the same way as > > is given http://pginstaller.projects.postgresql.org/ > > > > However, this is the error message that I get. > > > > Error Pop-up message: > > "Failed to run initdb: 1! Please see the logfile in > > "C:\Program Files\PostgreSQL\8.0.0-beta4\tmp\initdb.log" > > Note! You must read/copy this logifle before you click OK, or > > it will be automatically removed." > > > > > > Please find the log (initdb.log) below > > -- > > -T > he files belonging to this database system will be owned by > user > "postgres". This user must also own the server process. > > > > The database cluster will be initialized with locale C. > > > > fixing permissions on existing directory C:/Program > > Files/PostgreSQL/8.0.0-beta4/data ... ok creating directory > > C:/Program Files/PostgreSQL/8.0.0-beta4/data/global ... ok > > creating directory C:/Program > > Files/PostgreSQL/8.0.0-beta4/data/pg_xlog ... ok creating > > directory C:/Program > > Files/PostgreSQL/8.0.0-beta4/data/pg_xlog/archive_status ... > > ok creating directory C:/Program > > Files/PostgreSQL/8.0.0-beta4/data/pg_clog ... ok creating
Re: [BUGS] "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
Frank van Vugt <[EMAIL PROTECTED]> writes: > Meanwhile, one of the application developers here bumped into a way to > reproduce what looks like the same memory alloc problem (exactly the same > point in exactly the same trigger) using our application software > only, Oh good. Can you construct a self-contained test case then? > Here are both the query-set and the corresponding backtrace. The query set's not very interesting without a database to try it against :-( > I then got a firm set of results, all of which were looking like this: > Hardware access (read/write) watchpoint 1: SerializableSnapshotData.xcnt > Value = 1 > Hardware access (read/write) watchpoint 2: LatestSnapshotData.xcnt > Value = 1 > All were located at sinval.c:888 This is the expected case. The failure in CopySnapshot has got to indicate that somebody set one or the other field to some bizarrely large value, though. I take it you didn't run the watchpointed backend far enough to get the memory-alloc error? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
> > Meanwhile, one of the application developers here bumped into a way to > > reproduce what looks like the same memory alloc problem (exactly the same > > point in exactly the same trigger) using our application software > > only, > > Oh good. Can you construct a self-contained test case then? Will try to do just that when the rest won't work. > > All were located at sinval.c:888 > > This is the expected case. The failure in CopySnapshot has got to > indicate that somebody set one or the other field to some bizarrely > large value, though. I take it you didn't run the watchpointed backend > far enough to get the memory-alloc error? Oh, but I did. All the breaks are at sinval.c:888 and at some point the memory-alloc simply occurs. Do you mean you want a backtrace of the last break at line 888 just before the error ? -- Best, Frank. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
Frank van Vugt <[EMAIL PROTECTED]> writes: >> This is the expected case. The failure in CopySnapshot has got to >> indicate that somebody set one or the other field to some bizarrely >> large value, though. I take it you didn't run the watchpointed backend >> far enough to get the memory-alloc error? > Oh, but I did. [ scratches head ... ] AFAICS, the CopySnapshot that gets the error must be trying to copy one or the other of those snapshots. Maybe you should look at the address passed to CopySnapshot and see what it's really pointing at, and where it came from. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Foreign keys referencing parent table fails on insert
Stephan Szabo wrote: On Thu, 2 Dec 2004, postgresbugs wrote: On Wed, 1 Dec 2004, Stephan Szabo wrote: On Wed, 1 Dec 2004, postgresbugs wrote: > Foreign keys referencing parent table fails on insert if the key is in the table that inherits the parent table. Unfortunately, primary keys, unique constraints and foreign keys do not inherit to children in a meaningful fashion. It's one of the big deficiencies right now. Too bad. Table inheritance is pretty meaningless without these abilities. Anyone working on them? In the meantime, I will go back to views and updating the underlying tables. There's noone actively working on it at the moment that I know of (and if there is, hopefully they'll see this and correct me) although I believe there was some noise in the last dev cycle of people thinking about the unique (and pkey) side of it. Thanks. I would think that if the primary and unique keys worked properly the foreign key problem would just fall out naturally. I would volunteer for this except I do all my programing in JAVA these days and my C and C++ are too rusty to be useful. I hope someone picks this up. It would go a long way in doing away with the problems of views and inserts and updates.
Re: [BUGS] [Fwd: Bug#283856: postgresql: mistakes in src/backend/po/fr.po]
Oliver Elphick wrote: > I think this has been fixed in 8.0beta5, but you may want to apply > the patch to the 7.4 tree. I can't access developer.postgresql.org > to check the cvs; that server seems to be down at the moment. I've checked in the fix for 7.4. 8.0 had already been corrected. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] utf-8 flag always off in plperl function arguments
Hello: Since 5.6 or so, perl has stored an internal flag on every string to mark whether it's UTF-8 or not. For data of unknown encoding, such as data read from files, the default is latin1, but it can be changed with use encoding 'utf8'. Now, I have a postgresql database in charset UNICODE. So, postgres knows the data is UTF-8. However, when passing arguments to plperl functions, no matter what the charset, postgres ALWAYS sets the UTF-8 flag to off. This means that the only way to handle the string properly in perl, when it matters that perl knows it's UTF-8, is to use utf8::upgrade -- on every argument, in every function, every time. This is rather kludgy, considering there already exists a way to fix it by calling the libperl API properly. It would be nice if it could be fixed in 8 final (it's exactly the same in 8 beta and 7.4.6). Regards, Dave ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] utf-8 flag always off in plperl function arguments
David Kamholz <[EMAIL PROTECTED]> writes: > This is rather kludgy, considering there already > exists a way to fix it by calling the libperl API properly. If you know how to do it, how about offering a patch? regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
> [ scratches head ... ] AFAICS, the CopySnapshot that gets the error > must be trying to copy one or the other of those snapshots. Maybe you > should look at the address passed to CopySnapshot and see what it's > really pointing at, and where it came from. Ok, stepping through the transaction didn't reveal any change in the CopySnapshot address, except for the last one when the error occurs, which is when the deferred trigger is executing an update statement. I guess the only thing left for me is to try and create a script that will reproduce the problem ;( Please allow me to describe the sequence of events of the one thing that comes to mind when I take another good look at the functions/triggers and try to think about what could be causing this: - db - a deferred trigger is defined on insert/update/delete of purchaseorder_line (pol) - this trigger is meant to update the corresponding purchaseorder(s) - begin transaction - select purchaseorder_line (pol) X for update (here it is determined whether or not to spawn the line) - call function spawn_pol() on pol X (inside this function marked as volatile) - select pol X for update (in this case for the second time, it's called from other places too) - insert new pol Y - update old pol X (with regards to the spawned amount) - update pol Y (with regards to a number of other fields) - commit transaction - this will fire the earlier deferred trigger on pol - update purchaseorder (po) to which pols X and Y belong, using aggregates (it is this update statement where the error occurs) The only thing I can think of is that the handling of pol X and creation of pol Y from within spawn_pol() is somehow messing things up, but.. If this doesn't ring any alarm bells, then I'll start working on a script first thing next Monday. -- Best, Frank. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
Frank van Vugt <[EMAIL PROTECTED]> writes: > The only thing I can think of is that the handling of pol X and creation of > pol Y from within spawn_pol() is somehow messing things up, but.. Certainly the mere firing of a deferred trigger isn't the problem; we do that all the time. What struck me about the traceback you showed is that it involved an attempt by the planner to constant-fold an SQL-language function that was used in the trigger function's query (and was presumably marked IMMUTABLE and had constant arguments in the query). Because the trigger function is plpgsql, this could happen only the first time the trigger is fired in a particular session (unless you are using EXECUTE to invoke the update command?). If the problem is related to the planner constant-folding environment, then the first-time-only limitation would help make it hard to reproduce. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] "invalid memory alloc request size " in deferred trigger causes transaction to fail, but the backend keeps running
> > The only thing I can think of is that the handling of pol X and creation > > of pol Y from within spawn_pol() is somehow messing things up, but.. > Certainly the mere firing of a deferred trigger isn't the problem; we do > that all the time. Me too ;) I was more trying to emphase the multiple select for update from both in- as well as outside the functions, but you'd probably have caught that already if it could have been the culprit. > What struck me about the traceback > Because the trigger function is plpgsql, this could happen only the > first time the trigger is fired in a particular session I've tried to run all immutable functions used at least once before running the query-set, this made no difference, same error on the same location. > (unless you are using EXECUTE to invoke the update command?) No, no, it's a plain call. -- Best, Frank. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
