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.
-
On Tue, 28 Mar 2006, Tom Lane wrote:
> "Larry Rosenman" 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 determ
Tom Lane wrote:
> "Larry Rosenman" 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 docum
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
"Larry Rosenman" 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 layers o
Tom Lane wrote:
> "Larry Rosenman" 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
"Larry Rosenman" 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
version of
Tom Lane wrote:
> "Larry Rosenman" 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 de
"Larry Rosenman" 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 happene
Tom Lane wrote:
> "Larry Rosenman" 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" 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
place becau
"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 dra
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
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. Engineeri
Bruno,
> Read the docs. It's all in there.
More specifically:
http://www.postgresql.org/docs/8.1/interactive/internals.html
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Have you searched our list
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!
>
Read the docs. It's all in there.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-268
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.
http://br.yahoo.
> 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
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.
>
>
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
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
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 s
"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
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 d
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 ar
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
>
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
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 to
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: p
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 a
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 definit
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 assump
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*
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 i
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 t
> > 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
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 be
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'r
"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
> http://archives.postgresql.org/pg
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
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
> 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 som
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
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, b
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 customer
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
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 d
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, but turns out not to be.
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
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 v
> There are some problems about replacing string values in the SQL string.
Doesn't the Oracle implementation already imply a solution to that?
I don't know. I didn't find any detail documentation about it. I don't know
what Oracle exactly do.
I think we'd be best off to leave EXECUTE alone
> 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 n
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"
On Mon, 2006-03-27 at 18:27 +0200, Thomas Hallgren wrote:
> Tom Lane wrote:
> > It's only that much difference? Given all the other advantages of
> > separating the JVM from the backends, I'd say you should gladly pay
> > that price.
> >
> If I'm right, and the most common scenario is clients usi
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 i
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
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 th
57 matches
Mail list logo