Re: [BUGS] Dropped index on table preventing rule creation

[Tom Lane]

Robert Haas  writes:
> On Sep 10, 2011, at 11:26 PM, Tom Lane  wrote:
>> (IOW, rather than "fix" this I'd prefer to rip out the code altogether.
>> But maybe we should wait a couple more years for that.)

> IIRC, it's not dead code. I think you can still generate such a dump if you 
> use CREATE OR REPLACE VIEW to manufacture a pair of mutually recursive views.

Oh, yeah, I'd forgotten about that.  In general that's pg_dump's
strategy for breaking a circular dependency loop that involves a view.

> Now we should probably disallow that, but we currently don't.

Losing that particular case isn't problematic, but I'm not sure that
that's the only possible circularity involving a view.  One idea that
comes to mind is

create table foo (list-of-columns);

create function foofunc () returns setof foo as ...;

create rule  as select * from foofunc();

This only saves somebody from citing the list of column types twice,
so maybe we could blow off this case too; but who's to say there are
not more-useful cases that would create circularities?

regards, tom lane

-- 
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] Dropped index on table preventing rule creation

[Robert Haas]

On Sep 10, 2011, at 11:26 PM, Tom Lane  wrote:
> Thom Brown  writes:
>> I don't use rules, but in a bit of experimentation on Git master, I
>> discovered the following behaviour:
> 
>> CREATE TABLE test1 (id serial primary key, things text);
>> CREATE TABLE test2 (id serial primary key, things text);
>> ALTER TABLE test1 DROP CONSTRAINT test1_pkey;
>> ALTER TABLE test2 DROP CONSTRAINT test2_pkey;
>> CREATE RULE "_RETURN" AS ON SELECT TO test1 DO INSTEAD select * from test2;
> 
>> This produces the error message: could not convert table "test1" to a
>> view because it has indexes
> 
> IIRC, this is because the check is just checking relhasindex.  You
> should be able to recover and create the rule if you VACUUM the table.
> 
> We could no doubt add more code to make that more transparent, but I
> don't see the point.  The entire exercise of converting a table to a
> view is only meant to support loading of pg_dump output from versions
> that are probably ten years obsolete at this point.  We don't even
> document that you can do the above, do we?
> 
> (IOW, rather than "fix" this I'd prefer to rip out the code altogether.
> But maybe we should wait a couple more years for that.)

IIRC, it's not dead code. I think you can still generate such a dump if you use 
CREATE OR REPLACE VIEW to manufacture a pair of mutually recursive views.

Now we should probably disallow that, but we currently don't.

...Robert
-- 
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] segfault using pg_options_to_table(), v9.0.4

[Tom Lane]

Frank van Vugt  writes:
> postgres=# select pg_options_to_table(ARRAY['article']);
> --3262-2011-09-13 14:28:18 CESTLOG:  server process (PID 7427) was terminated 
> by signal 11: Segmentation fault

Looks like deflist_to_tuplestore fails to handle the case where an
option has no value.  Will fix, thanks.

regards, tom lane

-- 
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] [GENERAL] Problem with the 9.1 one-click installer Windows7 64bit

[Merlin Moncure]

On Tue, Sep 13, 2011 at 1:44 AM, Thomas Kellerer  wrote:
> Merlin Moncure, 12.09.2011 21:28:
>>>
>>> With the second attempt, the installer again hang during initdb. Checking
>>> the state using ProcessExplorer I could see that the installer script was
>>> waiting for icacls.exe to set permissions for the user currently running
>>> the
>>> installer. It was running [icacls.exe "thomas"] instead of [icacls.exe
>>> "mydomain\thomas"] - although I have to admit that I don't know if that
>>> would make a difference.
>>>
>>> So I killed the iacls.exe and the script proceeded, just to hang at the
>>> next
>>> call to icacls.exe when it tried to set the privileges on the directory
>>> for
>>> the postgres user despite the fact that that user already was the owner
>>> and
>>> had full control over it. So I killed icacls.exe again and then the
>>> script
>>> finally finished without problems. The service was registered and
>>> successully started.
>>>
>>> UAC is turned off on my computer.
>>>
>>
>> hm, why is icacls hanging? does it do that if you run it from the command
>> line?
>>
>
> I re-ran the installer and copied the actual commandline the installer was
> using.
>
> It turned out that it tries the following:
> (Note that the selected data directory is c:\Daten\db\pgdata91)
>
>   icacls  C:\ /grant "tkellerer":RX
>
> (Changing the permission for the whole harddisk!!)
>
> Then when I kill that process, the installer starts a new one with
>
>  icacls  "C:\Daten" /grant "tkellerer":RX
>
> Then I kill that one again, a new one is started with:
>
>  icacls  C:\ /grant "postgres":RX
>
> Then after killing that one, a new one is started with:
>
>  icacls  "C:\Daten" /grant "postgres":RX
>
> So it didn't actually hang, but changing the permissions for the entire
> harddisk (170GB taken) and the complete c:\Daten (~20GB) directory twice
> would have taken ages.
>
> Seems there is something fishy about the way the iacls.exe commandline is
> assembled.

uh oh -- no bueno.   forwarding this to -bugs.

merlin

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

[BUGS] segfault using pg_options_to_table(), v9.0.4

[Frank van Vugt]

Hi,

Reading up on the release notes of v9.1 I noticed an 'add documentation for 
pg_options_to_table()'. Since I didn't know of this function yet and the entry 
implied that it would be there in earlier versions, I was tempted to try in 
our current version:

postgres=# select version();
version 
   
---
 PostgreSQL 9.0.4 on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 
4.3.3, 64-bit
(1 row)

the following:

postgres=# select pg_options_to_table('article');
ERROR:  array value must start with "{" or dimension information
LINE 1: select pg_options_to_table('article');
   ^

=> ok, so let's make it an array:

postgres=# select pg_options_to_table(ARRAY['article']);

=> which led to a segfault, from the logs:

--3262-2011-09-13 14:28:18 CESTLOG:  server process (PID 7427) was terminated 
by signal 11: Segmentation fault
--3262-2011-09-13 14:28:18 CESTLOG:  terminating any other active server 
processes


I know, should have read the docs first to see that it expects something else 
as an argument, but still ;)





-- 
Best,




Frank.

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