Обсуждение: Parse error
When I run a php program connected to postgresql, I have the following error: "Parse error: parse error, unexpected T_STRING " The actual code for this part that caused the error is like this: $sql = "SELECT * FROM appconf ORDER BY sort_order"; <=== This line causes the error. $result = @pg_exec($sql); Do you know what is the unexpected T_STRING error is? THank you for your help. Abraham Lee AMS
On Sat, 16 Nov 2002, [iso-2022-jp] $B%"%`%9(B wrote: > When I run a php program connected to postgresql, I have the following > error: > > "Parse error: parse error, unexpected T_STRING " > > The actual code for this part that caused the error is like this: > > $sql = "SELECT * FROM appconf ORDER BY sort_order"; <=== This line causes > the error. > $result = @pg_exec($sql); > > Do you know what is the unexpected T_STRING error is? Most of the time this is an untermintaed string in a prevoius line. If you have a color coded editor, these things are easier to spot. If not, you can turn on php color highlighting in your webserver for .phps files and then just ln -s file.php file.phps and look at the file.phps and see the color coding.
You might check for a typographical error in a preceding line. I *think" that the "unexpected T_STRING" error means that the parser ran across a new constant string that it didn't expect to see. アムス wrote: >When I run a php program connected to postgresql, I have the following >error: > >"Parse error: parse error, unexpected T_STRING " > >The actual code for this part that caused the error is like this: > >$sql = "SELECT * FROM appconf ORDER BY sort_order"; <=== This line causes >the error. >$result = @pg_exec($sql); > >Do you know what is the unexpected T_STRING error is? > >THank you for your help. > >Abraham Lee >AMS > > >---------------------------(end of broadcast)--------------------------- >TIP 3: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to majordomo@postgresql.org so that your >message can get through to the mailing list cleanly > >. > > > -- John Burski @home S.I.M.U. (Well, sometimes I am) ... and still searching for new cheese
Hi everybody! My name is Csaba, I'm from Hungary. I'm a new member of this list. I 've gone through the archives but I haven't found too much information on my problem. Is there anybody who had ever met such a problem? (The environment: HP LC2000 NetServer, dual Pentium III 1GHz, 1GB RAM, 2x36GB HP 10000 rpm SCSI HDD) This is a hardly used industrial purpose web server. The task is to sychronize the Postgres db to an Win2k based Oracle db. Because I can't see the Oracle db from the Linux side, I tried to synchronize the data from the Win2k side via psqlodbc driver. The replicator program is started every minutes, and generates a long query string to send over to the Postgres . It contains all the rows to be inserted. In normal circumstances the number of rows is appr. 8100, but it may be two or three times more when the previous replications had failed. It isn't too much for such a system, is it? After one year thay called me to do something because the synchron time increased to 2(!) days. I can't imagine the reason of it. Has anybody any idea? If I'm on the wrong place and sholud ask this question on another list, please tell me. Thank you for your help. Best reguards Csaba --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.393 / Virus Database: 223 - Release Date: 2002.09.30.
Hi, It will be good if we have a litle more info about the replicator. As begin try to execute the replicator program in 5 or 10 min. Are you using any transactions by data inserting? How long take it to collect the data from oracle( it is extrem fast by normal work)? How long take it to insert this data in pg? regards, ivan. Egyud Csaba wrote: > Hi everybody! > > My name is Csaba, I'm from Hungary. I'm a new member of this list. > I 've gone through the archives but I haven't found too much information on > my problem. > > Is there anybody who had ever met such a problem? > (The environment: HP LC2000 NetServer, dual Pentium III 1GHz, 1GB RAM, > 2x36GB HP 10000 rpm SCSI HDD) > This is a hardly used industrial purpose web server. The task is to > sychronize the Postgres db to an Win2k based Oracle db. Because I can't see > the Oracle db from the Linux side, I tried to synchronize the data from the > Win2k side via psqlodbc driver. The replicator program is started every > minutes, and generates a long query string to send over to the Postgres . It > contains all the rows to be inserted. In normal circumstances the number of > rows is appr. 8100, but it may be two or three times more when the previous > replications had failed. It isn't too much for such a system, is it? > After one year thay called me to do something because the synchron time > increased to 2(!) days. I can't imagine the reason of it. > > Has anybody any idea? > If I'm on the wrong place and sholud ask this question on another list, > please tell me. > > Thank you for your help. > > Best reguards > Csaba > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.393 / Virus Database: 223 - Release Date: 2002.09.30. > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
Hi Ivan, it is very kind of you to reply so quickly. Are you working 24/7? To tell the truth I've made a mistake. The number of new records per minute is only 180 - and not 8100. Sorry. Well, the replicator is ( actually was, because it had been stopped ) started every one minute. At the begining (last november) it took the replicator a couple of seconds to complete its task. As I can remember the odbc queries are always embedded in a separate transaction. So I don't use any additional transactions. Maybe I make a mistake. But I'm sure that the collection of the data from the Oracle is very fast. The speed of the communication is also ok, because the synchronized data can be quickly queried via the web (intranet, 100Mbs). The problem must lie somewhere in the pg or in the odbc driver. The rest of the time must be lost somewhere there. I also use a few indexes on the tables and they have to be updated 180 times every minute. Could it be too huge a load for the server? reguards, Csaba > As begin try to execute the replicator program in 5 or 10 min. > Are you using any transactions by data inserting? > How long take it to collect the data from oracle( it is extrem fast by normal > work)? > How long take it to insert this data in pg? >
=?iso-8859-1?Q?Egy=FCd_Csaba?= <csegyud@freemail.hu> writes:
> I also use a few indexes on the tables and they have to be updated 180 times
> every minute. Could it be too huge a load for the server?
No ... but I wonder whether this database is getting vacuumed regularly?
Depending on your data patterns, it might also be that you need to
reindex every so often.
Also, what PG version is this?
regards, tom lane
Hi, I do appologize you to being silent so long but I had no time to read my mails. Thank you all to pay attention to my silly problems. Tom Lane wrote: > I wonder whether this database is getting vacuumed regularly? > Depending on your data patterns, it might also be that you need to reindex every so often. You are absolutely right. I already vacuumed and reindexed my db, and it seems to be all right. To tell the truth, I couldn't try it yet on the live environment, but it was working on my test sever well. I read somwhere, that the number of the shared buffers should also be increased. I've browsed through the archive and found a valuable article of Bruce Momjian on hardware performance issues and he writes that the shared_buffers can be set in the postgresql.conf file. Simply there isn't any file whith this name on my server. I use PG v7.0.3. Is that possible that this conf file has been introduced in the later releases? There are two files in the /var/lib/pgsql/data/ directory: postmaster.opts and postmaster.opts.default. The postmaster.opts is overwritten during the postmaster's start process, so I lose all of my changes on it. The postmaster.opts.default file is OK after the start of the postmaster, but I don't know how to check weather the new options are working. Thank you and reguards, Csaba --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.393 / Virus Database: 223 - Release Date: 2002.09.30.
Egyud Csaba <csegyud@freemail.hu> writes:
> Simply there isn't any file whith this name on my server. I use PG v7.0.3.
You are two major versions behind (three major versions, as of next
week). Please update.
regards, tom lane
On Thu, 21 Nov 2002, Egyud Csaba wrote: > Hi, > I do appologize you to being silent so long but I had no time to read my > mails. Thank you all to pay attention to my silly problems. > > Tom Lane wrote: > > I wonder whether this database is getting vacuumed regularly? > > Depending on your data patterns, it might also be that you need to reindex > every so often. > > You are absolutely right. > I already vacuumed and reindexed my db, and it seems to be all right. To > tell the truth, I couldn't try it yet on the live environment, but it was > working on my test sever well. > > I read somwhere, that the number of the shared buffers should also be > increased. > I've browsed through the archive and found a valuable article of Bruce > Momjian on hardware performance issues and he writes that the shared_buffers > can be set in the postgresql.conf file. > Simply there isn't any file whith this name on my server. I use PG v7.0.3. > Is that possible that this conf file has been introduced in the later > releases? Yes, I think it showed up in 7.1.x. You should really upgrade to 7.2.3 or wait a week or two and try migrating to 7.3. They are both MUCH faster than 7.0 was. > There are two files in the /var/lib/pgsql/data/ directory: postmaster.opts > and postmaster.opts.default. > The postmaster.opts is overwritten during the postmaster's start process, so > I lose all of my changes on it. The postmaster.opts.default file is OK after > the start of the postmaster, but I don't know how to check weather the new > options are working. ps -ewx|grep postmaster will show you that on a linux/gnu box. Not sure how to do it on other platforms. Normally, to make the shared buffers vary large you'll need to increase the shmmax and shmall settings for your kernel (again, I'm speaking Linux here) but you can usually get away with <4000 shared buffers on a stock redhat box (4096 buffers being 32 megs, which is the max default shared mem setting on most linux machines.) blocks, by the way, are usually 8192 bytes each, unless you've recompiled your postgresql with larger block sizes, which isn't very commonly done.
> Yes, I think it showed up in 7.1.x. You should really upgrade to 7.2.3 > or wait a week or two and try migrating to 7.3. They are both MUCH faster > than 7.0 was. OK, I see. What do you think, is it a dificult job or not? As far as I can imagine it I will have to dump all data from the db, uninstall 7.0, install the 7.2 or 7.3 and then restore the whole db. Certainly I will have to recreate the users and the grants. Which is the most painless way. Perhaps exists a patch, which doesn't need to reinstall the whole stuff. Or where can I get an upgrade manual which explains the migration process step by step? thanks, cs. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.393 / Virus Database: 223 - Release Date: 2002.09.30.
On Thu, 21 Nov 2002, Egyud Csaba wrote: > > Yes, I think it showed up in 7.1.x. You should really upgrade to 7.2.3 > > or wait a week or two and try migrating to 7.3. They are both MUCH faster > > than 7.0 was. > OK, I see. What do you think, is it a dificult job or not? > As far as I can imagine it I will have to dump all data from the db, > uninstall 7.0, install the 7.2 or 7.3 and then restore the whole db. > Certainly I will have to recreate the users and the grants. > Which is the most painless way. Perhaps exists a patch, which doesn't need > to reinstall the whole stuff. > Or where can I get an upgrade manual which explains the migration process > step by step? The user accounts (in the database) and grants and all should migrate smoothly. for instructions on upgrading have a look here: http://www.postgresql.org/idocs/index.php?install-upgrading.html I recommend doing a "practice upgrade" on a test machine first, just to make sure everything works ok. If you don't have you unix boxes running under something like NIS where all the accounts are shared, then you might want to create the Unix system user accounts on the test box first, then it should work ok.
Thank you very much! Csaba ----- Original Message ----- From: "scott.marlowe" <scott.marlowe@ihs.com> To: "Egyud Csaba" <csegyud@freemail.hu> Cc: "pgsql-general" <pgsql-general@postgresql.org> Sent: Thursday, November 21, 2002 1:20 PM Subject: Re: [GENERAL] Welcom & a problem > On Thu, 21 Nov 2002, Egyud Csaba wrote: > > > > Yes, I think it showed up in 7.1.x. You should really upgrade to 7.2.3 > > > or wait a week or two and try migrating to 7.3. They are both MUCH faster > > > than 7.0 was. > > OK, I see. What do you think, is it a dificult job or not? > > As far as I can imagine it I will have to dump all data from the db, > > uninstall 7.0, install the 7.2 or 7.3 and then restore the whole db. > > Certainly I will have to recreate the users and the grants. > > Which is the most painless way. Perhaps exists a patch, which doesn't need > > to reinstall the whole stuff. > > Or where can I get an upgrade manual which explains the migration process > > step by step? > > The user accounts (in the database) and grants and all should migrate > smoothly. for instructions on upgrading have a look here: > > http://www.postgresql.org/idocs/index.php?install-upgrading.html > > I recommend doing a "practice upgrade" on a test machine first, just to > make sure everything works ok. If you don't have you unix boxes running > under something like NIS where all the accounts are shared, then you > might want to create the Unix system user accounts on the test box first, > then it should work ok. > > > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.393 / Virus Database: 223 - Release Date: 2002.09.30.