Try select * from "Dx";
If you want to keep case (as opposed to the normal
lower-casing) you'll need to double quote the name.
On Fri, 23 Feb 2001 [EMAIL PROTECTED] wrote:
>
>
> I am trying to convert a MS SQL database to postgres. I have done it
> this way:
>
> 1) use Access -> link to MS
mike wrote:
> > Hi !
> >
> > Does anyone knows what means, after an INSERT for exemple the message :
> >
> > INSERT 19331808 1
> >
> > What the meaning of the two numbers ?
> >
> > I had a problem with a DB because I reached the max transaction ID.
> >
> > So, how could i know what is the maxim
On Fri, Feb 23, 2001 at 01:09:37PM +0200, Hannu Krosing wrote:
> Dmitry Morozovsky wrote:
>
> > DM> I just done the experiment with increasing HZ to 1000 on my own machine
> > DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
> > DM> of increasing HZ is surely more overh
On Thu, 22 Feb 2001 20:28, hubert depesz lubaczewski wrote:
> since in 7.1beta4 there is no postgres.h i changed this to:
I did a cvsup update about 12 hours ago and look:-
22:05:23 chris@berty:/usr/src/cvs/pgsql $ find . -name postgres.h
./src/include/postgres.h
22:16:22 chris@berty:/usr/src/c
Hi,
I cannot use any kind of odbc because my customers have his local m$
access db's locally then export them on .txt with tab or | separated, then
put on my server trought ftp.
and is working ok except that the customers are on spanish databases then
a data like:
--DATE-NAME-LANG
Hello
I am using postgreSQL 7.0.2. Is it necessary to lock the database before
backup the database (using pg_dump), if not necessary, will the database corrupt when
someone is
accessing the database during pg_dump processing?
Thanks in advance!
Maggie
I am trying to convert a MS SQL database to postgres. I have done it
this way:
1) use Access -> link to MS SQL
2) install postgress ODBC driver
3) use Access -> copy -> ODBC compliant database.
4) set up the database in postgress
5) do the copy from access.
the file Dx for the table Dx is cre
Tom Lane wrote:
>
> > platform) i686-pc-linux-gnu, compiled by GCC egcs-2.91.60(turbolinux 4.2)
> > min delay) 10msec according to your test program.
> > -B) 64 (all other settings are default)
>
> Thanks. Could I trouble you to run it again with a larger -B, say
> 1024 or 2048? What I've foun
> -Original Message-
> From: Tom Lane
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is this unmodified pgbench or has it Hiroshi tweaked behaviour of
> > connecting each client to its own database, so that locking and such
> > does not shade the possible benefits (was it about 15% ?)
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 23 February 2001 21:07
> To: Dave Page
> Cc: [EMAIL PROTECTED]; 'PostgreSQL Admin News'
> Subject: Re: [ADMIN] select * from pgadmin_users; causes error
>
>
> Dave Page <[EMAIL PROTECTED]> writes:
> > Basically i
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 23 February 2001 15:23
> To: [EMAIL PROTECTED]
> Cc: 'PostgreSQL Admin News'; Dave Page
> Subject: Re: [ADMIN] select * from pgadmin_users; causes error
>
>
> John Hatfield <[EMAIL PROTECTED]> writes:
> > It look
> I didn't much like that approach to altering the test, since it also
> means that all the clients are working with separate tables and hence
> not able to share read I/O; that doesn't seem like it's the same
> benchmark at all. What would make more sense to me is to increase the
> number of row
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: 23 February 2001 22:29
> To: Dave Page
> Cc: [EMAIL PROTECTED]; 'PostgreSQL Admin News'
> Subject: Re: [ADMIN] select * from pgadmin_users; causes error
>
>
> Dave Page <[EMAIL PROTECTED]> writes:
> > Basically i
> Okay, plan B then: let's ask people to redo their benchmarks with
> -s bigger than one. Now, how much bigger?
>
> To the extent that you think this is a model of a real bank, it should
> be obvious that the number of concurrent transactions cannot exceed the
> number of tellers; there should n
Dave Page <[EMAIL PROTECTED]> writes:
> Basically it isn't so much as the user ID that created
> the views that is an issue, it's that fact that pgAdmin
>> then didn't issue a
>> 'GRANT ALL ON pgadmin_users TO PUBLIC'.
>>
>> The particular case being complained of here would not be
>> fixed by
Dave Page <[EMAIL PROTECTED]> writes:
> Basically it isn't so much as the user ID that created
> the views that is an issue, it's that fact that pgAdmin then didn't issue a
> 'GRANT ALL ON pgadmin_users TO PUBLIC'.
The particular case being complained of here would not be fixed by that.
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> Hmm, you mean you set up a separate test database for each pgbench
> >> "client", but all under the same postmaster?
>
> > Yes. Different database is to make the conflict as less as possible.
> > The conflict among backends is a
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I changed pgbench so that different connection connects
> > to the different database and got the following results.
>
> Hmm, you mean you set up a separate test database for
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > In your test cases I always see "where bid = 1" at "update branches"
> > i.e.
> > update branches set bbalance = bbalance + ... where bid = 1
>
> > ISTM there's no multiple COMMIT in your senario-s due to
> > their lock conflicts
Hi Tom,
I reran the tests setting PGHOST=localhost. Same errors. I do not know
about broken Unix domain sockets. How can I check/fix that?
Cheers,
Paul
Tom Lane wrote:
>
> Paul Huppe <[EMAIL PROTECTED]> writes:
> > It was acutally Peter Eisentraut who asked me to post to the list. He
> >
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I've been suspicious if pgbench is an (unique)
> > appropiriate test case for evaluaing commit_delay.
>
> Of course it isn't. Never trust only one benchmark.
>
> I've asked the Great Bridge folks to run their TPC-C benchmark with
Tom Lane wrote:
>
> I wrote:
> > Thus, our past arguments about whether a few microseconds of delay
> > before commit are a good idea seem moot; we do not have any portable way
> > of implementing that, and a ten millisecond delay for commit is clearly
> > Not Good.
>
> I've now finished running
Paul Huppe <[EMAIL PROTECTED]> writes:
> It was acutally Peter Eisentraut who asked me to post to the list. He
> wanted to see the .diff file because he tought that I had a problem with
> broken Unix domain sockets.
Hm, I should think that broken sockets would lead to total non function,
rather
> sequential test create_function_1... ./run_check.sh: sql/create_function_1.sql:
>cannot open
> diff: expected/create_function_1.out: No such file or directory
Now that I look ... did you run 'make all' before 'make runtest'
in the regress-test directory?
regards,
Hi Tom,
It was acutally Peter Eisentraut who asked me to post to the list. He
wanted to see the .diff file because he tought that I had a problem with
broken Unix domain sockets.
Platform: Sun SPARCserver 10
OS: Solaris 8
Compiler: gcc 2.95.2
Configuration Options: none, used defaults
Paul
To
Paul Huppe <[EMAIL PROTECTED]> writes:
> I am installing v7.0.3 and just finished compiling the source. I ran
> the regression tests and I am getting quite a few errors. I have
> attached the output from the tests.
You did not need to send the list 350K of not-very-interesting test
diffs in ord
John Hatfield <[EMAIL PROTECTED]> writes:
> It looks as though the views are created the first time you login to
> pgAdmin. So when I logged first as an ordinary user not as the postgres
> (database superuser), the views were created with this user as the owner.
> A trap for beginners!!
Indee
Hi,
I am installing v7.0.3 and just finished compiling the source. I ran
the regression tests and I am getting quite a few errors. I have
attached the output from the tests.
Thanks,
Paul.
*** expected/create_type.outWed Jan 5 12:31:08 2000
--- results/create_type.out Fri Feb 23 08:1
On Fri, 23 Feb 2001, Hannu Krosing wrote:
HK> > DM> I just done the experiment with increasing HZ to 1000 on my own machine
HK> > DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
HK> > DM> of increasing HZ is surely more overhead to scheduler system. Anyway, it's
HK> >
Dmitry Morozovsky wrote:
> On Sun, 18 Feb 2001, Dmitry Morozovsky wrote:
>
> DM> I just done the experiment with increasing HZ to 1000 on my own machine
> DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
> DM> of increasing HZ is surely more overhead to scheduler syste
30 matches
Mail list logo
