[BUGS] BUG #8511: some of object dont drop

2013-10-08 Thread shahtejas2811 
The following bug has been logged on the website:

Bug reference:  8511
Logged by:  Tejas
Email address:  shahtejas2...@gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system:   Linux
Description:

cache lookup failed for relation 421062806 



-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8511: some of object dont drop

2013-10-08 Thread John R Pierce 

On 10/8/2013 1:02 AM, shahtejas2...@gmail.com wrote:

The following bug has been logged on the website:

Bug reference:  8511
Logged by:  Tejas
Email address:  shahtejas2...@gmail.com
PostgreSQL version: Unsupported/Unknown
Operating system:   Linux
Description:

cache lookup failed for relation 421062806





as far as I know, that error only happens if there is memory or file 
corruption, which generally points at a hardware or operating system 
problem.


that said, there's hardly any useful information in this bug report.
please read 
http://www.postgresql.org/docs/current/static/bug-reporting.html


oh, direct further correspondence to the bug list, 
pgsql-bugs@postgresql.org and not me personally




--
john r pierce  37N 122W
somewhere on the middle of the left coast



--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8511: some of object dont drop

2013-10-08 Thread Pavan Deolasee 
On Tue, Oct 8, 2013 at 1:32 PM,  wrote:

> The following bug has been logged on the website:
>
> Bug reference:  8511
> Logged by:  Tejas
> Email address:  shahtejas2...@gmail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system:   Linux
> Description:
>
> cache lookup failed for relation 421062806
>
>
I am afraid you need to provide a lot more information for anyone to help
you. Postgres version you are using and the failing test case at the
minimum.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs?

2013-10-08 Thread Bruce Momjian 
On Mon, Oct  7, 2013 at 08:07:42AM -0700, fburg...@radiantblue.com wrote:
> Bruce, Proposed Steps. Do they look feasible?
> 
> 1.) pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/
> testdb.backup" testdb
> 2.) CREATE DATABASE newdb TEMPLATE=template_postgis;
> 3.) perl ../postgis-postgres/postgis-2.1.1/utils/postgis_restore.pl 
> "/somepath/
> testdb.backup" | psql -h localhost -p 5432 -U postgres newdb 2> errors.txt  <-
> this step may run 5-6 days, since our backup runs that long, right?
> 4.) At this point we will have two 6.1TB databases, so it looks like a
> prerequisite is to have available double the db size in disk space, right?
> 5.) then if no critical errors, there will be errors since we have our testdb
> schema in the public folder
>   5a.) ALTER DATABASE testdb RENAME TO olddb;
>   5b.) ALTER DATABASE newdb RENAME TO testdb;
> 6.) At this point hopefully we should be upgraded from postgis 1.5.3 to 
> postgis
> 2.1.1, with PostgreSQL 9.1.6
> 7.) then can we just use pg_upgrade with the hard links option, instead of
> copying files to the new cluster option to upgrade to PostgreSQL 9.3?

Sorry, I have no idea how to upgrade PostGIS.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known bugs?

2013-10-08 Thread fburgess 
We shouldn't have a problem with using pg_upgrade with the hard link option to upgrade from postgreSQL 9.1.6 after I get the spatial component upgraded to postgis 2.1, then straight to postgreSQL 9.3, Right? thanks


 Original Message 
Subject: Re: [BUGS] Installing/Upgrading PostgreSQL 9.1.6 to 9.3 known
bugs?
From: Bruce Momjian 
Date: Tue, October 08, 2013 6:17 am
To: fburg...@radiantblue.com
Cc: pgsql-bugs@postgresql.org

On Mon, Oct  7, 2013 at 08:07:42AM -0700, fburg...@radiantblue.com wrote:
> Bruce, Proposed Steps. Do they look feasible?
> 
> 1.) pg_dump -h localhost -p 5432 -U postgres -Fc -b -v -f "/somepath/
> testdb.backup" testdb
> 2.) CREATE DATABASE newdb TEMPLATE=template_postgis;
> 3.) perl ../postgis-postgres/postgis-2.1.1/utils/postgis_restore.pl "/somepath/
> testdb.backup" | psql -h localhost -p 5432 -U postgres newdb 2> errors.txt  <-
> this step may run 5-6 days, since our backup runs that long, right?
> 4.) At this point we will have two 6.1TB databases, so it looks like a
> prerequisite is to have available double the db size in disk space, right?
> 5.) then if no critical errors, there will be errors since we have our testdb
> schema in the public folder
>   5a.) ALTER DATABASE testdb RENAME TO olddb;
>   5b.) ALTER DATABASE newdb RENAME TO testdb;
> 6.) At this point hopefully we should be upgraded from postgis 1.5.3 to postgis
> 2.1.1, with PostgreSQL 9.1.6
> 7.) then can we just use pg_upgrade with the hard links option, instead of
> copying files to the new cluster option to upgrade to PostgreSQL 9.3?

Sorry, I have no idea how to upgrade PostGIS.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8467: Slightly confusing pgcrypto example in docs

2013-10-08 Thread Bruce Momjian 
On Wed, Oct  2, 2013 at 12:00:44PM -0400, Bruce Momjian wrote:
> Based on your report, I have developed the attached doc patch which
> clarifies when MD5 hash is being referenced, and when MD5 crypt is.  I
> have also added your other suggestions.

Patch applied, and backpatched to 9.3.X.  Thanks for the suggestions.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] BUG #8512: Can't use columns I can't read in the where clause of a select

2013-10-08 Thread kurt 
The following bug has been logged on the website:

Bug reference:  8512
Logged by:  Kurt Roeckx
Email address:  k...@roeckx.be
PostgreSQL version: 9.0.6
Operating system:   Linux
Description:

Hi,


When I read the documentation for GRANT, I see:
SELECT


Allows SELECT from any column, or the specific columns listed, of the
specified table, view, or sequence. Also allows the use of COPY TO. This
privilege is also needed to reference existing column values in UPDATE or
DELETE.


I read that as "SELECT field1 from table where field2 = 1" should work if I
have grant select(field1), but not on field2.  I'm getting a "permission
denied".  If I remove the where clause it of course works.


I'm not sure if the behaviour is expected or not.  Maybe I'm reading the
documentation wrong, or maybe the documentation is just wrong.  Could
someone please clarify?




Kurt




-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #8512: Can't use columns I can't read in the where clause of a select

2013-10-08 Thread Stephen Frost 
* k...@roeckx.be (k...@roeckx.be) wrote:
> Allows SELECT from any column, or the specific columns listed, of the
> specified table, view, or sequence. Also allows the use of COPY TO. This
> privilege is also needed to reference existing column values in UPDATE or
> DELETE.
> 
> 
> I read that as "SELECT field1 from table where field2 = 1" should work if I
> have grant select(field1), but not on field2.  I'm getting a "permission
> denied".  If I remove the where clause it of course works.

You have to have SELECT rights on a column to be able to use it in a
conditional (eg: with WHERE).

> I'm not sure if the behaviour is expected or not.  Maybe I'm reading the
> documentation wrong, or maybe the documentation is just wrong.  Could
> someone please clarify?

It's expected.  The documentation could perhaps be improved, but the
second sentence ("This privilege is also needed..") is intended to cover
the case where the column is being referred to *anywhere* in the query,
basically, and that applies to SELECT as much as UPDATE or DELETE.

Thanks,

Stephen


signature.asc
Description: Digital signature

[BUGS] Re: BUG #8512: Can't use columns I can't read in the where clause of a select

2013-10-08 Thread David Johnston 
Stephen Frost wrote
> * 

> kurt@

>  (

> kurt@

> ) wrote:
>> Allows SELECT from any column, or the specific columns listed, of the
>> specified table, view, or sequence. Also allows the use of COPY TO. This
>> privilege is also needed to reference existing column values in UPDATE or
>> DELETE.
>> 
>> 
>> I read that as "SELECT field1 from table where field2 = 1" should work if
>> I
>> have grant select(field1), but not on field2.  I'm getting a "permission
>> denied".  If I remove the where clause it of course works.
> 
> You have to have SELECT rights on a column to be able to use it in a
> conditional (eg: with WHERE).
> 
>> I'm not sure if the behaviour is expected or not.  Maybe I'm reading the
>> documentation wrong, or maybe the documentation is just wrong.  Could
>> someone please clarify?
> 
> It's expected.  The documentation could perhaps be improved, but the
> second sentence ("This privilege is also needed..") is intended to cover
> the case where the column is being referred to *anywhere* in the query,
> basically, and that applies to SELECT as much as UPDATE or DELETE.

"SELECT": read the current value
"UPDATE": cause the current value to be changed (does not require knowing
the existing value)
"DELETE": cause the current value (indirectly via row removal) to be removed
(does not require knowing the existing value)

A where clause requires that the user can know the current value in the
field

Within a SELECT statement there is no permissions distinction between the
different sub-clauses (e.g., ORDER BY, GROUP BY, WHERE, select-list) since
in any of these cases it is the current value of a column that is needed. 
So "SELECT" is read as being a top-level (as are UPDATE and DELETE) - and as
Stephen said because WHERE can be part of UPDATE and DELETE the additional
comment is made that WHERE in those contexts require "SELECT-like"
privileges if the column is used there.  But not if the column only exists
as a target-column.

David J.




--
View this message in context: 
http://postgresql.1045698.n5.nabble.com/BUG-8512-Can-t-use-columns-I-can-t-read-in-the-where-clause-of-a-select-tp5773752p5773757.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] win8

2013-10-08 Thread Mátyás Milos 
Dear Support,

I would like to install the newest postgresql to win 8 but something wrong
with that... At the end I got a message about some problem and I don't know
why. The problem is the postgresql can not connect to the host ( 127.0.0.1
). How can I fix it?

Thanks!