Thread

Re: Cannot INDEX an Access97 ODBC

lampe@durawebs.com — 2000-06-09T11:13:52Z

Thanks for the response:

The column exists in the table structure and can be accessed/queried via
psql with SELECT statements or via ODBC  SELECT statements form Access97.
The data intergrity (content) for the table and columns is fine and intact.
 The psql CREATE INDEX statement can't see the imported column
(name/attribute)... wierd?

Dlampe
lampe@durawebs.com

----- Original Message -----
From: Bryan White <bryan@arcamax.com>
To: <lampe@durawebs.com>; <pgsql-general@postgresql.org>
Sent: Friday, June 09, 2000 3:39 PM
Subject: Re: [GENERAL] Cannot INDEX an Access97 ODBC export?


>
> > Error return is that it is not able to find the attribute
> "any_column_name" in the table.
>
> This maybe obvious but have you looked at the table layout to see if the
> column exists.  You may have a problem with spaces in the name or upper
case
> letters in the name.  In either case you must quote the name (table or
> column).  Un quoted names are converted to all lower case.
>
> In psql do: \d tablename
> or from the shell do: pg_dump -s -t tablename
>
>

Re: Cannot INDEX an Access97 ODBC

Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-09T17:49:53Z

<lampe@durawebs.com> writes:
>  The psql CREATE INDEX statement can't see the imported column
> (name/attribute)... wierd?

I still think that Bryan's got the right idea --- Access probably
created the column name with some embedded blanks and/or upper-case
characters, which'd mean that you have to quote the column name in
order to refer to it.

It would be useful to see the output of
	 pg_dump -s -t tablename databasename
for this table.

			regards, tom lane

Ah, yet another cause for not binding the right port....

Steve Wolfe <steve@iboats.com> — 2000-06-09T18:14:10Z

   I've run across yet another cause that can make Postgres not be able to
bind to the port it desires (or any other port, for that matter).  I don't
recall it being discussed before, so I'll throw it out.

   When postgres binds to any port, it likes to write a file in /tmp, along
the lines of ".s.PGSQL.5432".  If /tmp is not writeable by the postgres
process, it will not be able to bind to any port.  However, it doesn't give
you an intelligent error message like "Can't create file", it simply says
that it can't bind the port, and of course, asks if another postgres
process is already running.

   For those interested, I found that out after having a sudden power loss
wipe out several filesystems, and I had a late night reformatting and
restoring from the backups, which I (thankfully!) had made that morning.
When I remounted the /tmp permission, I forgot to set the permissions.
Even more interesting was watching the two UPS' that I bought spark, flash,
pop, and die. : )

steve

Re: Ah, yet another cause for not binding the right port....

Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-09T22:27:14Z

"Steve Wolfe" <steve@iboats.com> writes:
>    When postgres binds to any port, it likes to write a file in /tmp, along
> the lines of ".s.PGSQL.5432".  If /tmp is not writeable by the postgres
> process, it will not be able to bind to any port.  However, it doesn't give
> you an intelligent error message like "Can't create file", it simply says
> that it can't bind the port,

I tried this and got what I thought was a fairly reasonable error
message:

FATAL: StreamServerPort: bind() failed: Permission denied
        Is another postmaster already running on that port?
        If not, remove socket node (/tmp/.s.PGSQL.5432) and retry.
postmaster: cannot create UNIX stream port

"Permission denied" is what the kernel told us, and I don't think it's
likely to be a good idea to second-guess why the kernel told us that.
But the reference to /tmp/.s.PGSQL.5432 together with that error ought
to be sufficient clue I would think...

			regards, tom lane

Re: Ah, yet another cause for not binding the right port....

Steve Wolfe <steve@iboats.com> — 2000-06-09T22:44:39Z

> I tried this and got what I thought was a fairly reasonable error
> message:
>
> FATAL: StreamServerPort: bind() failed: Permission denied
>         Is another postmaster already running on that port?
>         If not, remove socket node (/tmp/.s.PGSQL.5432) and retry.
> postmaster: cannot create UNIX stream port
>
> "Permission denied" is what the kernel told us, and I don't think it's
> likely to be a good idea to second-guess why the kernel told us that.
> But the reference to /tmp/.s.PGSQL.5432 together with that error ought
> to be sufficient clue I would think...

   Yes, that is what clued me off...  now I'm not exactly a kernel hacker,
so be patient with me... : )

  Postgres was the only program not able to bind a port - everything else
(web, mail, IRC, etc.) was able to run just dandy.  From poking around in a
few config files, it looks like you get to choose whether you want to use
the file in /tmp or not.   I imagine that the developpers must have had a
compelling reason to go with the former - would you care to explain just a
little of all of that to me?

steve

Re: Ah, yet another cause for not binding the right port....

Martijn van Oosterhout <kleptog@cupid.suninternet.com> — 2000-06-10T14:04:13Z

Steve Wolfe wrote:
>    When postgres binds to any port, it likes to write a file in /tmp, along
> the lines of ".s.PGSQL.5432".  If /tmp is not writeable by the postgres

Just in case you missed it, that file in /tmp is not a real file, but
a "socket" (Unix domain).

> process, it will not be able to bind to any port.  However, it doesn't give
> you an intelligent error message like "Can't create file", it simply says
> that it can't bind the port, and of course, asks if another postgres
> process is already running.

If the node is there, it can't "bind" to the "port". Ofcourse, you
just delete it to mix it :)
-- 
Martijn van Oosterhout <kleptog@cupid.suninternet.com>
http://cupid.suninternet.com/~kleptog/