Dear All,I am totally new to the PostgreSQL, and pgAdmin. I really need your help. I just installed the PostgreSQL8.1 and pgAdmin3 on a Debian system, using the apt-get install command. Apparently, the initial database and the user "postgres" have also been automatically created during the
On 3/28/06, lmyho [EMAIL PROTECTED] wrote:
Dear All,
Which is good. But I've got big trouble to login to this initial db by
using this auto-created username postgres through pgAdmin:((( The first
try failed due to Ident authentication failed, so I follow the suggestion
on the pop-up
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I think what's happened here is that VACUUM FULL moved the only tuple
off page 1 of the relation, then truncated off page 1, and now
heap_update_redo is panicking
Hi lmyho,
lmyho [2006-03-28 0:17 -0800]:
I am totally new to the PostgreSQL, and pgAdmin. I really need
your help.
I just installed the PostgreSQL8.1 and pgAdmin3 on a Debian system,
using the apt-get install command. Apparently, the initial
database and the user postgres have
Tatsuo Ishii [EMAIL PROTECTED] writes:
I don't mind having encoding conversions be named within schemas,
but I propose that any given encoding pair be allowed to have only
one default conversion, period, and that when we are looking for
a default conversion we find it by a
Honda Shigehiro has diagnosed the longstanding problems with his
Tru64/Alpha buildfarm member (bear). See below.
First, it appears that there is a problem with the system getaddrinfo(),
which configure reports as usable, but turns out not to be. Our current
configure test checks the return
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
The subsequent replay of the deletion or truncation
will get rid of any unwanted data again.
Trouble is, it is not a watertight assumption that there *will be* a
subsequent truncation, even if it is a
Philip Yarra [EMAIL PROTECTED] writes:
Someone else might be able to see a better way to write this query, but I
think it would be good if \d could show this information, when you really
want to know which tablespace an object is on.
If \d doesn't say anything then the table is in the
Hi Simon,
Thanks for your input. All good points. I actually did some work using Java stored
procedures on DB2 a while back but I had managed to forget (or repress :-) ) all about the
FENCED/NOT FENCED stuff. The current discussion definitely puts it in a different
perspective. I think PL/Java
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm sure we need more than one default conversion for encoding A and
B. For example, different vendors provide different conversion maps
for SJIS and UTF-8. M$ has its own and Apple has another one, etc. The
differences are not huge but some customers
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Honda Shigehiro has diagnosed the longstanding problems with his
Tru64/Alpha buildfarm member (bear). See below.
First, it appears that there is a problem with the system getaddrinfo(),
which configure reports as usable,
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I'm not sure that I believe the getaddrinfo doesn't work diagnosis
anyway, seeing that bear gets through make check okay. Wouldn't that
fail too if there were a problem there?
Now that I look further into it, this machine was working
Tatsuo Ishii [EMAIL PROTECTED] writes:
I'm sure we need more than one default conversion for encoding A and
B. For example, different vendors provide different conversion maps
for SJIS and UTF-8. M$ has its own and Apple has another one, etc. The
differences are not huge but some
On Tue, Mar 28, 2006 at 10:07:35AM -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
The subsequent replay of the deletion or truncation
will get rid of any unwanted data again.
Trouble is, it is not a watertight assumption
Tatsuo Ishii [EMAIL PROTECTED] writes:
Well, being able to switch to a different conversion is fine, but I don't
think that's a good argument for tying it to the schema search path.
If it does work, then it's ok. However still I'm not sure why current
method is evil.
Because with the current
Jim C. Nasby [EMAIL PROTECTED] writes:
On Tue, Mar 28, 2006 at 10:07:35AM -0500, Tom Lane wrote:
Well, in fact we'll have correctly recreated the page, so I'm not
thinking that it's necessary or desirable to check this.
Would the suggestion made in
On Wed, Mar 29, 2006 at 01:09:08AM +0900, Tatsuo Ishii wrote:
BTW, what does the standard say about conversion vs. schema? Doesn't
conversion belong to schema? If so, then schema specific default
conversion seems more standard-friendly way.
The standard says nothing about conversions. They're
Thomas Hallgren [EMAIL PROTECTED] writes:
This FENCED/NOT FENCED terminology would be a good way to
differentiate between the two approaches. Any chance of that syntax
making it into the PostgreSQL grammar, should the need arise?
Of what value would it be to have it in the grammar? The
If it does work, then it's ok. However still I'm not sure why current
method is evil.
Because with the current definition, any change in search_path really
ought to lead to repeating the lookup for the default conversion proc.
That's a bad idea from a performance point of view and I don't
Tatsuo Ishii [EMAIL PROTECTED] writes:
Because with the current definition, any change in search_path really
ought to lead to repeating the lookup for the default conversion proc.
That's a bad idea from a performance point of view and I don't think
it's a particularly good idea from the
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
This FENCED/NOT FENCED terminology would be a good way to
differentiate between the two approaches. Any chance of that syntax
making it into the PostgreSQL grammar, should the need arise?
Of what value would it be to have it in
On Tue, 2006-03-28 at 17:48 +0200, Thomas Hallgren wrote:
Simon Riggs wrote:
Just some thoughts from afar: DB2 supports in-process and out-of-process
external function calls (UDFs) that it refers to as UNFENCED and FENCED
procedures. For Java only, IBM have moved to supporting *only*
On Tue, 2006-03-28 at 10:07 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Mon, 2006-03-27 at 22:03 -0500, Tom Lane wrote:
The subsequent replay of the deletion or truncation
will get rid of any unwanted data again.
Trouble is, it is not a watertight assumption that
On 28-Mar-06, at 10:48 AM, Thomas Hallgren wrote:
Hi Simon,
Thanks for your input. All good points. I actually did some work
using Java stored procedures on DB2 a while back but I had managed
to forget (or repress :-) ) all about the FENCED/NOT FENCED stuff.
The current discussion
On 28-Mar-06, at 12:11 PM, Thomas Hallgren wrote:
Tom Lane wrote:
Thomas Hallgren [EMAIL PROTECTED] writes:
This FENCED/NOT FENCED terminology would be a good way to
differentiate between the two approaches. Any chance of that syntax
making it into the PostgreSQL grammar, should the need
Hello!
PostgreSQL 8.1.1 on
x86_64-pc-linux-gnu
I've been running a server with autovacuum enabled
for quite a while now (months) without problems. But recently the server slowed
down and after investigation I found the following repeated error messsage
in the log:
LOG: autovacuum:
Dave Cramer wrote:
What exactly is a FENCED solution ? If it is simply a remote
connection to a single JVM then pl-j already does that.
Last time I tried to use pl-j (in order to build a mutual test
platform), I didn't manage to make it compile due to missing artifacts
and it wasn't ported
The last time I talked to him Laszlo said he is working on it again.
Dave
On 28-Mar-06, at 2:21 PM, Thomas Hallgren wrote:
Dave Cramer wrote:
What exactly is a FENCED solution ? If it is simply a remote
connection to a single JVM then pl-j already does that.
Last time I tried to use pl-j
I wrote:
* log_heap_update decides that it can set XLOG_HEAP_INIT_PAGE instead
of storing the full destination page, if the destination contains only
the single tuple being moved. This is fine, except it also resets the
buffer indicator for the *source* page, which is wrong --- that page
may
Dave Cramer wrote:
I'm not too keen on the term FENCED, since it, in the PL/Java case
will lead to poorer isolation. Multiple threads running in the same
JVM will be able to share data and a JVM crash will affect all
connected sessions.
When was the last time you saw a JVM crash ? These
Greetings,
After helping a user on irc, I was wondering if there would be any
objection
to my making a patch that would:
1) expose DEFAULT_PGSOCKET_DIR via a libpq call
2) add this information to the psql --version output (or some other
switch, I'm agnostic).
for those weird times when some
Larry Rosenman [EMAIL PROTECTED] writes:
1) expose DEFAULT_PGSOCKET_DIR via a libpq call
2) add this information to the psql --version output (or some other
switch, I'm agnostic).
pg_config would seem to be the appropriate place, not libpq nor psql.
regards, tom lane
On Tuesday 28 March 2006 14:07, Larry Rosenman wrote:
Greetings,
After helping a user on irc, I was wondering if there would be any
objection
to my making a patch that would:
1) expose DEFAULT_PGSOCKET_DIR via a libpq call
2) add this information to the psql --version output (or some
Tom Lane wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
1) expose DEFAULT_PGSOCKET_DIR via a libpq call
2) add this information to the psql --version output (or some other
switch, I'm agnostic).
pg_config would seem to be the appropriate place, not libpq nor psql.
The issue is when you
Darcy Buskermolen wrote:
On Tuesday 28 March 2006 14:07, Larry Rosenman wrote:
Greetings,
After helping a user on irc, I was wondering if there would be
any objection to my making a patch that would:
1) expose DEFAULT_PGSOCKET_DIR via a libpq call
2) add this information to the psql
On Wed, 29 Mar 2006 01:36 am, Tom Lane wrote:
Philip Yarra [EMAIL PROTECTED] writes:
Someone else might be able to see a better way to write this query, but I
think it would be good if \d could show this information, when you really
want to know which tablespace an object is on.
If \d
You could try to change the ident method to trust (in pg_hba.conf). This
should allow you to login.
Then, set the password of the postgres user (alter user postgres with password
'blabla1212' ; ). Then you could change the ident method back to md5 .
Hi Adrian,
Thank you for help!! I've
Hi, my teacher want's me to find out and explain how PgSQL stores data
fisically! I've done searches but could not find it. Please help me!
___
Yahoo! doce lar. Faça do Yahoo! sua homepage.
On Tue, Mar 28, 2006 at 08:40:27AM -0300, Bruno Cassol wrote:
Hi, my teacher want's me to find out and explain how PgSQL stores data
fisically! I've done searches but could not find it. Please help me!
http://www.postgresql.org/docs/8.1/interactive/storage.html
--
Jim C. Nasby, Sr.
Thomas Hallgren wrote:
Martijn,
I tried a Socket approach. Using the new IO stuff that arrived with Java
1.4 (SocketChannel etc.), the performance is really good. Especially on
Linux where an SMP machine show a 1 to 1.5 ratio between one process
doing ping-pong between two threads and two
Tom Lane [EMAIL PROTECTED] wrote
What we should be seeing, and don't see, is an indication of a backup
block attached to this WAL record. Furthermore, I don't see any
indication of a backup block attached to *any* of the WAL records in
Alex's printout. The only conclusion I can draw is
Larry Rosenman ler@lerctr.org writes:
Tom Lane wrote:
pg_config would seem to be the appropriate place, not libpq nor psql.
The issue is what psql (and any libpq using program) is going to use to find
the UNIX socket.
No, the issue is where the server put the socket. libpq is the wrong
Tom Lane wrote:
Larry Rosenman ler@lerctr.org writes:
Tom Lane wrote:
pg_config would seem to be the appropriate place, not libpq nor
psql.
The issue is what psql (and any libpq using program) is going to use
to find the UNIX socket.
No, the issue is where the server put the socket.
Larry Rosenman ler@lerctr.org writes:
The other issue is borked installs where the server and libpq disagree.
What I'm looking for
is to expose what libpq has for it's default as well as what the server is
using. There is currently
no way to determine what libpq has for it's default. What
Tom Lane wrote:
Larry Rosenman ler@lerctr.org writes:
The other issue is borked installs where the server and libpq
disagree. What I'm looking for is to expose what libpq has for it's
default as well as what the server is using. There is currently no
way to determine what libpq has for
Larry Rosenman ler@lerctr.org writes:
That's making the assumption that you know which libpq. I was hoping to
have a psql commandline
Switch to dump the info, but with your objection(s), I'll just crawl back
under my rock.
It's not that I don't feel your pain ... but if you don't know what
Tom Lane wrote:
Larry Rosenman ler@lerctr.org writes:
That's making the assumption that you know which libpq. I was hoping
to have a psql commandline Switch to dump the info, but with your
objection(s), I'll just crawl back under my rock.
It's not that I don't feel your pain ... but if you
Larry Rosenman ler@lerctr.org writes:
What's the harm of a (pseudo code):
const char *PQgetunixsocketdir(void)
{
return(DEFAULT_PGSOCKET_DIR)
}
In libpq, and a psql command line switch to call it.
By the time you get done adding the infrastructure and documentation for
those two
Jeremy Drake wrote:
When I encounter such behavior, my tool of choice tends to be
strace(1) rather than strings(1). That way, you know what exactly
the thing it wants that it is not finding is...
That assumes that the user has strace(1) installed. Yes, I've run into
systems
that don't
Tom Lane wrote:
Larry Rosenman ler@lerctr.org writes:
What's the harm of a (pseudo code):
const char *PQgetunixsocketdir(void)
{
return(DEFAULT_PGSOCKET_DIR)
}
In libpq, and a psql command line switch to call it.
By the time you get done adding the infrastructure and
On Tue, 28 Mar 2006, Tom Lane wrote:
Larry Rosenman ler@lerctr.org writes:
The other issue is borked installs where the server and libpq disagree.
What I'm looking for
is to expose what libpq has for it's default as well as what the server is
using. There is currently
no way to
Hi
We are trying to fetch records
from Postgre Tables.
We are successfully able to build
connectivity. We are Using Postgre ODBC Driver (Unicode).
But when I query the tables of
Postgre it is unable to map the datatype varchar of source Table.
We got following Reply from Oracle
Support.
52 matches
Mail list logo
