Thread: Parse error

Parse error

From
アムス
Date:
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


Re: Parse error

From
"scott.marlowe"
Date:
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.


Re: Parse error

From
John Burski
Date:
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




Welcom & a problem

From
Egyud Csaba
Date:
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.



Re: Welcom & a problem

From
pginfo
Date:
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




Re: Welcom & a problem

From
Együd Csaba
Date:
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?
>



Re: Welcom & a problem

From
Tom Lane
Date:
=?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

Re: Welcom & a problem

From
Egyud Csaba
Date:
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.


Re: Welcom & a problem

From
Tom Lane
Date:
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

Re: Welcom & a problem

From
"scott.marlowe"
Date:
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.


Re: Welcom & a problem

From
Egyud Csaba
Date:
> 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.


Re: Welcom & a problem

From
"scott.marlowe"
Date:
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.


Re: Welcom & a problem

From
Egyud Csaba
Date:
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.