Re: [BUGS] BUG #6712: PostgreSQL 9.2 beta2: alter table drop constraint does not work on inherited master table
From: Noah Misch [mailto:n...@leadboat.com] Sent: Monday, July 16, 2012 2:54 AM From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of miroslav.s...@fordfrog.com Sent: Saturday, June 30, 2012 4:28 PM Care to prepare a patch with a test case addition? Yes. I have started working. With Regards, Amit Kapila. -- 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 #6712: PostgreSQL 9.2 beta2: alter table drop constraint does not work on inherited master table
From: Noah Misch [mailto:n...@leadboat.com] Sent: Monday, July 16, 2012 2:54 AM One can construct similar bugs around dropping foreign key and exclusion constraints. Though it may be irrelevant for command semantics, additionally using connoinherit = 't' for contype = 't' (CONSTRAINT_TRIGGER) would more-accurately represent the nature of those constraints. Code Changes I will make changes in following functions to ensure that connoinherit should be appropriately set(pass the value as true). a. index_constraint_create() b. ATAddForeignKeyConstraint() c. CreateTrigger(). Other places I have checked seems to be fine. Test I will create testcases similar to mentioned in bug report for a. unique key case, same as in bug-report b. foreign key case c. exclusion constraint case Care to prepare a patch with a test case addition? Let me know if above is sufficient or shall I include anything more in patch. With Regards, Amit Kapila. -- 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 #6735: PANIC: 42501: could not open control file global/pg_control: Permission denied
On 07/16/2012 07:54 PM, Petros Tsialiamanis wrote: Sorry for the misunderstanding. When I said that I reproduced the error in 9.1 version, I mean that I created the PGDATA with 9.1 postgresql server as 'local system' user and after that I tried to start the postgresql server as 'pss-svc' user and I took the error message which I sent with my previous mail. So there isn't any incompatibility problem with PGDATA. OK, that helps explain that. Thanks for following up with a current version, then. I have a Windows VM on this machine so I'll see if I can reproduce that issue. I need a bit more information to do so. Specifically I need to know how the user 'pss-svc' was created, what its group memberships are and what its rights are (can interact with desktop, login as service, etc). As 'pss-svc' user I can open, read and write to the pg_control file ( I took backup of this file first ). Open, read and write using what command(s) or programs? Is there a UAC prompt? Did you run the CACLS command you were given by John? I have exactly the same problem when I try to start progresql server as Administrator instead of 'pss-svc' user If 'pss-svc' user is a member of Administrators or Local Admins, remove the user from those groups. Pg is quite insistent about not being run as admin. That shouldn't be the cause of these issues, as it's quite explicit about it when that's the case, but it's a good idea anyway. Personally I think Pg should let this up to the user, but that's the way it is for now. -- Craig Ringer -- 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 #6739: PGAdmin 3 Should allow to select multiple tables in the left tree
The following bug has been logged on the website:
Bug reference: 6739
Logged by: Stuart Axon
Email address: stua...@yahoo.com
PostgreSQL version: 9.1.0
Operating system: Linux
Description:
If you go to Database{db}SchemaspublicTables
You can only select one table (to then drop/whatever).
However if you use the list of tables under properties on the right you
*can* select multiple tables.
The inconsistancy is confusing and a little inconvenient (at first I didn't
realise it was possible to perform actions on more than one table).
--
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 #6735: PANIC: 42501: could not open control file global/pg_control: Permission denied
On 14 July 2012 05:56, Craig Ringer ring...@ringerc.id.au wrote: On 07/14/2012 12:18 AM, Petros Tsialiamanis wrote: Thank you very much for your reply. Thanks for coming back and re-testing with a modern PostgreSQL. PostgreSQL 9.1 isn't compatible with databases from 8.3, so you can't actually run Pg 9.1 directly against a datadir from 8.3; that's why I suggested the latest 8.3 point release. However, your startup should be failing with a message telling you this, not with a permissions error then (more importantly) a crash. Sorry for the misunderstanding. When I said that I reproduced the error in 9.1 version, I mean that I created the PGDATA with 9.1 postgresql server as 'local system' user and after that I tried to start the postgresql server as 'pss-svc' user and I took the error message which I sent with my previous mail. So there isn't any incompatibility problem with PGDATA. Is there any antivirus software on this computer? If so, what is it? Does excluding the PostgreSQL data directory, PostgreSQL executable directory, and (if the AV supports it) adding process exclusions for postmaster.exe and postgres.exe have any effect? There isn't any antivirus software on my computer. The 'pss-svc' user is member of the administrators group and has full permissions for PostgreSQL data directory. It clearly doesn't, because PostgreSQL is getting permission denied from the OS when accessing global/pg_control. Maybe you need to apply permissions recursively? As 'pss-svc' user I can open, read and write to the pg_control file ( I took backup of this file first ). I have exactly the same problem when I try to start progresql server as Administrator instead of 'pss-svc' user Remember that on Win7, membership of the Administrators group doesn't grant the ability to perform file operations as administrator directly. It grants the ability to create privileged processes that can then perform those operations using implicit or explicit run as administrator functionality. I can't off the top of my head think of a safe way on Windows to test if a file is writable as a given user without potentially changing its contents. On Linux I'd say run touch /path/name but there's no touch command on Windows. global\pg_control is a binary file so you can't just open it and save it in notepad (DO NOT DO THIS) as it'll corrupt it hopelessly, and Windows doesn't come with a binary-safe editor. I reproduced the crash with PostgreSQL version 9.1.4.12152 with the following output : [snip] LOCATION: _dosmaperr, .\src\port\win32error.c:186 PANIC: 42501: could not open control file global/pg_control: Permission denied LOCATION: ReadControlFile, .\src\backend\access\transam\xlog.c:4687 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ** OK, that's not very nice behaviour - it should be doing a clean exit after it fails to read global/pg_control . Hmm. I'm not sure off the top of my head how to tackle tracking that down without a debugger. I don't really have time at the moment to set up a test environment under Windows and see if I can reproduce it. Ideas anyone? Can someone with a Windows box use pg_ctl to try to start a new Pg instance against a datadir with an unwritable pg_control ? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #6712: PostgreSQL 9.2 beta2: alter table drop constraint does not work on inherited master table
On Mon, Jul 16, 2012 at 04:49:46PM +0530, Amit Kapila wrote: Code Changes I will make changes in following functions to ensure that connoinherit should be appropriately set(pass the value as true). a. index_constraint_create() b. ATAddForeignKeyConstraint() c. CreateTrigger(). Other places I have checked seems to be fine. Looks right. Test I will create testcases similar to mentioned in bug report for a. unique key case, same as in bug-report Good. b. foreign key case c. exclusion constraint case Test coverage for those is optional. Care to prepare a patch with a test case addition? Let me know if above is sufficient or shall I include anything more in patch. I can't think of anything else. As a side question for the list, should we fix this differently in 9.2 to avoid forcing an initdb for the next beta? Perhaps have ATExecDropConstraint() only respect connoinherit for CONSTRAINT_CHECK? -- 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] Re: BUG #6712: PostgreSQL 9.2 beta2: alter table drop constraint does not work on inherited master table
Noah Misch n...@leadboat.com writes: As a side question for the list, should we fix this differently in 9.2 to avoid forcing an initdb for the next beta? I'm confused, why would an initdb be involved? 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] Re: BUG #6712: PostgreSQL 9.2 beta2: alter table drop constraint does not work on inherited master table
On Mon, Jul 16, 2012 at 12:47:37PM -0400, Tom Lane wrote: Noah Misch n...@leadboat.com writes: As a side question for the list, should we fix this differently in 9.2 to avoid forcing an initdb for the next beta? I'm confused, why would an initdb be involved? pg_constraint.connoinherit is presently only correct for CHECK constraints. It will take an initdb to update those values comprehensively. -- 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 #6734: create table (like ...) fails if an index has a comment
daniele.varra...@gmail.com writes: CREATE TABLE foo ( id serial primary key, f1 integer NOT NULL ); CREATE INDEX foo_idx1 ON foo (f1); CREATE INDEX foo_idx2 ON foo (f1) WHERE id 10; COMMENT ON INDEX foo_idx2 IS 'whatever'; create table foo2 (like foo including all); I've applied a fix for this in 9.2 and up. The issue exists since CREATE TABLE LIKE grew the ability to copy comments, in 9.0, but it seems too risky to fix in already-released branches. 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] BUG #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
core stack: root@db4 / $ pstack ~postgres/core core '/opt/postgres/core' of 19868: pg_upgrade --verbose --link --old-datadir=/opt/postgres/db/root/old -- fd7ffeda1148 memcpy () + 6b8 0040b8b6 transfer_single_new_db () + fa 0040b6ea transfer_all_new_dbs () + 116 0040ae62 main () + 106 0040580c () As to the ownership, the bash script I am testing 9.1.4 and 9.2.0 with recursively chowns the directory that owns the old and the new PGDATA directory before running pg_upgrade. Mike Wilson mfwil...@gmail.com On Jul 15, 2012, at 2:45 PM, Tom Lane wrote: Mike Wilson mfwil...@gmail.com writes: I've had some time to examine this closer over the weekend. It appears that pg_upgrade for 9.2b2 segfaults which more than likely has something to do with the resulting converted database appearing to have no rows. Yeah, more than likely :-(. Could we see a stack trace from the segfault? Of possible note in this DB is that the previous DBA renamed the postgres user. Hmm. There is a known bug in beta2 that's triggered by old and new clusters not having the same name for the bootstrap superuser; although I don't recall that the symptoms included a segfault. In any case, I'd suggest making sure the new cluster is initdb'd under the same account that currently owns the old cluster. 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] BUG #6732: Build issue when using gettext on FreeBSD 9
On tor, 2012-07-12 at 15:25 +, ch...@chrullrich.net wrote: The PostgreSQL configure script indiscriminately enables the --as-needed option to the linker if the linker supports it, which GNU ld 2.17.50 in FreeBSD 9 does. It does not, however, use it in its own library checks. The configure script therefore fails to detect libintl as required; the check program links correctly because libintl is pulled in as an indirect dependency via libgssapi. Proposed fix: Use --as-needed during configure as well, or make its use predicated on a working linker version (GNU ld 2.22 or later). Over the weekend I was investigating a separate but related issue on Debian, which goes like this: configure with --with-libedit-preferred, or have libedit but not libreadline installed. Because libedit is linked with libbsd, which provides setproctitle, the check for function setproctitle succeeds. Thus, ps_status.c is compiled using the setproctitle variant. When postgres is linked, however, we don't put libedit on the command line, so the link fails. The workaround/solution I came up with was also to put LDFLAGS=-Wl,--as-needed on the configure command line to run the tests with that flag as well. With that, the setproctitle test fails. To add insult to injury, the setproctitle implementation in libbsd is a stub that doesn't do anything, so we definitely don't want to arrive at a solution that ends up using it. -- 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 #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
Just for my interest I also created a new PG 842 db (initdb) and put some sample data it it and successfully did a pg_upgrade from 842 - 920b2. Whatever the issue is it seems to be related to my actual database as a sample db conversion works. Again, 842-914 conversion works for my db though so possibly it was some change that happened to pg_upgrade since 914 was released that is having poor interaction with my actual db cluster. Also, I wanted to make sure I wasn't using some git checkout of 920 I downloaded the postgresql-9.2.beta2.tgz from the PostgreSQL site dir-browser and re-compiled. Still have the problem unfortunately. Cheers. Mike Wilson mfwil...@gmail.com On Jul 15, 2012, at 2:45 PM, Tom Lane wrote: Mike Wilson mfwil...@gmail.com writes: I've had some time to examine this closer over the weekend. It appears that pg_upgrade for 9.2b2 segfaults which more than likely has something to do with the resulting converted database appearing to have no rows. Yeah, more than likely :-(. Could we see a stack trace from the segfault? Of possible note in this DB is that the previous DBA renamed the postgres user. Hmm. There is a known bug in beta2 that's triggered by old and new clusters not having the same name for the bootstrap superuser; although I don't recall that the symptoms included a segfault. In any case, I'd suggest making sure the new cluster is initdb'd under the same account that currently owns the old cluster. regards, tom lane
[BUGS] Re: BUG #6652: Installer grants postgres user rights for the whole disk, not specified subfolder
Excerpts from Dave Page's message of mar jun 05 14:38:54 -0400 2012: On Sun, May 20, 2012 at 7:05 PM, Alvaro Herrera alvherre(at)commandprompt(dot)com wrote: I have been installing PostgreSQL 9.1.3.2, and I've noted that 'creating database cluster' is too long. I have been waiting for a half of hour, and it hasn't finished. I've noted that installer calls icacls.exe with arguments: D:\ /grant postgres:RX This seems to be reported every once in a while. It looks like the one-clunk installer is to blame. Maybe it's been fixed in some more recent version -- Dave Page would probably know. Just as an FYI, we are working on this. We've been able to reproduce it, and it appears that icacls (a Microsoft utility) will sometimes look at the ACL of every file/directory recursively when it grants the required privileges on higher level directories. The good news is that in none of the test we've done has it ever modified the ACL on the wrong thing - it just takes a long time if there are a lot of items on the filesystem. We've looked at third party alternatives to icacls, and they seem to exhibit similar traits. We're also going to look into other ways around the root problem. The 9.1.4 installer is still exhibiting this behavior; not as bad as the original bug, but still pushing 30 minutes. Has there been any luck with finding a work-around? Thank you, Trey -- Trey Chadick (LabKey Software) tchad(at)labkey(dot)com -- 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 #6733: All Tables Empty After pg_upgrade (PG 9.2.0 beta 2)
Mike Wilson mfwil...@gmail.com writes: Just for my interest I also created a new PG 842 db (initdb) and put some sample data it it and successfully did a pg_upgrade from 842 - 920b2. Whatever the issue is it seems to be related to my actual database as a sample db conversion works. Yeah, I was suspecting that, because there's no obvious problem in the part of pg_upgrade that your stack trace fingers. What we need to do next is get something that one of the PG developers can put under a microscope. What I would suggest first is doing a pg_dumpall -s (ie no data) of your database, and seeing whether loading that into 8.4 produces a database on which pg_upgrade fails. If so, then you could send us that dump (perhaps after some sanitizing of names) and we could have at it. If you aren't able to create a self-contained reproducible case in this way, the only other way forward is for you to debug it yourself or let one of the PG developers have access to your system to poke at it. 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
