Thread: Re: Cannot INDEX an Access97 ODBC
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 > >
<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
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
"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
> 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
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/