Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

On Sun, Feb 05, 2017 at 01:48:09PM -0500, Tom Lane wrote: > Noah Misch writes: > > On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote: > >> Is there any likely use-case for providing separate control flags for the > >> two permission checks? That would require an API

Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

Noah Misch writes: > On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote: >> Is there any likely use-case for providing separate control flags for the >> two permission checks? That would require an API change for DefineIndex, >> making this considerably more invasive, so

Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

On Sun, Feb 05, 2017 at 12:46:41PM -0500, Tom Lane wrote: > Noah Misch writes: > > DefineIndex() has a check_rights argument that determines whether to > > perform a > > namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets > > that flag. The theory

Re: [HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

Noah Misch writes: > DefineIndex() has a check_rights argument that determines whether to perform a > namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets > that flag. The theory goes that use of DROP INDEX and CREATE INDEX is a mere > implementation

[HACKERS] Ignore tablespace ACLs when ignoring schema ACLs

DefineIndex() has a check_rights argument that determines whether to perform a namespace ACL check. When ALTER TABLE ALTER TYPE rebuilds an index, it sets that flag. The theory goes that use of DROP INDEX and CREATE INDEX is a mere implementation detail of ALTER TABLE ALTER TYPE; the operation

[HACKERS] Ignore src/tools/msvc/config.pl in code tree for MSVC compilation

Hi all, MSVC build uses two configuration perl files when running: config_default.pl and config.pl. The former is mandatory and is present in the code tree, while the latter can be used to override settings with some custom parameters. As far as I understand from the docs, config.pl should be

Re: [HACKERS] Ignore src/tools/msvc/config.pl in code tree for MSVC compilation

On Mon, May 12, 2014 at 3:08 PM, Michael Paquier michael.paqu...@gmail.com wrote: Hi all, MSVC build uses two configuration perl files when running: config_default.pl and config.pl. The former is mandatory and is present in the code tree, while the latter can be used to override settings

Re: [HACKERS] Ignore src/tools/msvc/config.pl in code tree for MSVC compilation

Michael Paquier michael.paqu...@gmail.com writes: Actually I am sending an updated patch as buildenv.pl enters in the same category as config.pl. This seems sane to me; it's in the same category as src/Makefile.custom, which we have a .gitignore entry for. I wondered whether there were any

Re: [HACKERS] Ignore src/tools/msvc/config.pl in code tree for MSVC compilation

On Tue, May 13, 2014 at 3:16 AM, Tom Lane t...@sss.pgh.pa.us wrote: Michael Paquier michael.paqu...@gmail.com writes: Actually I am sending an updated patch as buildenv.pl enters in the same category as config.pl. This seems sane to me; it's in the same category as src/Makefile.custom, which

Re: [HACKERS] Ignore files in src/interfaces/libpq generated by windows builds

On 05/08/2014 08:48 AM, Michael Paquier wrote: Hi all, While doing some builds with mingw and 9.4, I noticed that a couple of files generated by build are not ignored in the source tree. Those two files are system.c and win32setlocale.c in src/interfaces/libpq. Please find attached a patch

[HACKERS] Ignore files in src/interfaces/libpq generated by windows builds

Hi all, While doing some builds with mingw and 9.4, I noticed that a couple of files generated by build are not ignored in the source tree. Those two files are system.c and win32setlocale.c in src/interfaces/libpq. Please find attached a patch fixing that. Note that this is recent and is

Re: [HACKERS] Ignore invalid indexes in pg_dump.

On Tue, Mar 26, 2013 at 09:43:54PM +, Tom Lane wrote: Ignore invalid indexes in pg_dump. Dumping invalid indexes can cause problems at restore time, for example if the reason the index creation failed was because it tried to enforce a uniqueness condition not satisfied by the table's

Re: [HACKERS] Ignore invalid indexes in pg_dump.

Bruce Momjian br...@momjian.us writes: Should I just patch pg_upgrade to remove the indisvalid, skip indisvalid indexes, and backpatch it? Users should be using the version of pg_upgrade to match new pg_dump. Is there any case where they don't match? Do I still need to check for indisready?

Re: [HACKERS] Ignore invalid indexes in pg_dump.

Tom Lane t...@sss.pgh.pa.us schrieb: Bruce Momjian br...@momjian.us writes: Should I just patch pg_upgrade to remove the indisvalid, skip indisvalid indexes, and backpatch it? Users should be using the version of pg_upgrade to match new pg_dump. Is there any case where they don't match?

Re: [HACKERS] Ignore invalid indexes in pg_dump.

On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote: Tom Lane t...@sss.pgh.pa.us schrieb: Bruce Momjian br...@momjian.us writes: Should I just patch pg_upgrade to remove the indisvalid, skip indisvalid indexes, and backpatch it? Users should be using the version of

Re: [HACKERS] Ignore invalid indexes in pg_dump.

anara...@anarazel.de and...@anarazel.de writes: Tom Lane t...@sss.pgh.pa.us schrieb: Yeah, if you can just ignore !indisvalid indexes that should work fine. I see no need to look at indisready if you're doing that. You need to look at inisready in 9.2 since thats used for about to be dropped

Re: [HACKERS] Ignore invalid indexes in pg_dump.

Tom Lane t...@sss.pgh.pa.us schrieb: anara...@anarazel.de and...@anarazel.de writes: Tom Lane t...@sss.pgh.pa.us schrieb: Yeah, if you can just ignore !indisvalid indexes that should work fine. I see no need to look at indisready if you're doing that. You need to look at inisready in 9.2

Re: [HACKERS] Ignore invalid indexes in pg_dump.

On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote: Tom Lane t...@sss.pgh.pa.us schrieb: anara...@anarazel.de and...@anarazel.de writes: Tom Lane t...@sss.pgh.pa.us schrieb: Yeah, if you can just ignore !indisvalid indexes that should work fine. I see no need to look

Re: [HACKERS] Ignore invalid indexes in pg_dump.

On 2013-03-28 17:54:08 -0400, Bruce Momjian wrote: On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote: Tom Lane t...@sss.pgh.pa.us schrieb: anara...@anarazel.de and...@anarazel.de writes: Tom Lane t...@sss.pgh.pa.us schrieb: Yeah, if you can just ignore

Re: [HACKERS] Ignore invalid indexes in pg_dump.

anara...@anarazel.de and...@anarazel.de writes: 9.2 represents inisdead as live !ready, doesn't it? So just looking at indislive will include about to be dropped or partially dropped indexes? Ooooh ... you're right, in 9.2 (only) we need to check both indisvalid and indisready (cf

Re: [HACKERS] Ignore invalid indexes in pg_dump.

On 2013-03-28 17:35:08 -0400, Bruce Momjian wrote: On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote: Tom Lane t...@sss.pgh.pa.us schrieb: Bruce Momjian br...@momjian.us writes: Should I just patch pg_upgrade to remove the indisvalid, skip indisvalid indexes,

Re: [HACKERS] Ignore invalid indexes in pg_dump

Michael Paquier michael.paqu...@gmail.com writes: On top of checking indisvalid, I think that some additional checks on indislive and indisready are also necessary. Those are not necessary, as an index that is marked indisvalid should certainly also have those flags set. If it didn't require

Re: [HACKERS] Ignore invalid indexes in pg_dump

On Wed, Mar 27, 2013 at 6:47 AM, Tom Lane t...@sss.pgh.pa.us wrote: Michael Paquier michael.paqu...@gmail.com writes: On top of checking indisvalid, I think that some additional checks on indislive and indisready are also necessary. Those are not necessary, as an index that is marked

Re: [HACKERS] Ignore invalid indexes in pg_dump

On 20 March 2013 02:51, Michael Paquier michael.paqu...@gmail.com wrote: If failures happen with CREATE INDEX CONCURRENTLY, the system will be let with invalid indexes. I don't think that the user would like to see invalid indexes of an existing system being recreated as valid after a

Re: [HACKERS] Ignore invalid indexes in pg_dump

On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs si...@2ndquadrant.com wrote: On 20 March 2013 02:51, Michael Paquier michael.paqu...@gmail.com wrote: If failures happen with CREATE INDEX CONCURRENTLY, the system will be let with invalid indexes. I don't think that the user would like to see

Re: [HACKERS] Ignore invalid indexes in pg_dump

Josh Kupershmidt schmi...@gmail.com writes: On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs si...@2ndquadrant.com wrote: Invalid also means currently-in-progress, so it would be better to keep them in. For invalid indexes which are left hanging around in the database, if the index definition

Re: [HACKERS] Ignore invalid indexes in pg_dump

On Thu, Mar 21, 2013 at 12:58 AM, Tom Lane t...@sss.pgh.pa.us wrote: I had been on the fence about what to do here, but I find Josh's arguments persuasive, particularly the second one. Why shouldn't we consider an in-progress index to be an uncommitted DDL change? (Now admittedly, there

[HACKERS] Ignore invalid indexes in pg_dump

Hi, If failures happen with CREATE INDEX CONCURRENTLY, the system will be let with invalid indexes. I don't think that the user would like to see invalid indexes of an existing system being recreated as valid after a restore. So why not removing from a dump invalid indexes with something like the

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011: I think I agree with Peter here that it's not a very good idea, and I don't see a big upside. With tablespaces it seems to make a little bit more sense,

[HACKERS] Ignore lost+found when checking if a directory is empty

When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA directory, initdb will refuse to run because it sees the lost+found directory that mke2fs created and assumes the PGDATA directory is already in use for something other than PostgreSQL. Attached is a patch against master

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote: When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA directory, initdb will refuse to run because it sees the lost+found directory that mke2fs created and assumes the PGDATA directory is already in use for something

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

On Tue, Aug 9, 2011 at 1:52 PM, Brian Pitts b...@uga.edu wrote: When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA directory, initdb will refuse to run because it sees the lost+found directory that mke2fs created and assumes the PGDATA directory is already in use for

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote: Attached is a patch against master which will cause a directory that contains only lost+found to still be treated as empty. Please add this to the September commitfest at: https://commitfest.postgresql.org/ Regards, Jeff Davis --

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

Brian Pitts b...@uga.edu writes: When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA directory, initdb will refuse to run because it sees the lost+found directory that mke2fs created and assumes the PGDATA directory is already in use for something other than PostgreSQL.

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011: On Tue, 2011-08-09 at 14:52 -0400, Brian Pitts wrote: When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA directory, initdb will refuse to run because it sees the lost+found directory that mke2fs

Re: [HACKERS] Ignore lost+found when checking if a directory is empty

Alvaro Herrera alvhe...@commandprompt.com writes: Excerpts from Jeff Davis's message of mar ago 09 16:03:26 -0400 2011: I think I agree with Peter here that it's not a very good idea, and I don't see a big upside. With tablespaces it seems to make a little bit more sense, but I'd still lean

[HACKERS] Ignore -- testing message-id on footer

Hi, Please ignore this message. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. - Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Ignore -- testing message-id on footer

On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: - This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID fail :) -- greg - Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Ignore -- testing message-id on footer

Greg Stark wrote: On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: - This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID fail :) Yeah, majordomo does not consider MESSAGE_ID a standard substitution variable. It's some other kind

Re: [HACKERS] Ignore -- testing message-id on footer

Greg Stark st...@enterprisedb.com writes: On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID fail :) It's a bad idea anyway. regards, tom lane - Sent via

Re: [HACKERS] Ignore -- testing message-id on footer

Tom Lane wrote: Greg Stark st...@enterprisedb.com writes: On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID fail :) It's a bad idea anyway. I find it useless, but why do

Re: [HACKERS] Ignore -- testing message-id on footer

On Tue, 2009-03-17 at 12:37 -0400, Alvaro Herrera wrote: Tom Lane wrote: Greg Stark st...@enterprisedb.com writes: On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID

Re: [HACKERS] Ignore -- testing message-id on footer

On Tue, 17 Mar 2009, Alvaro Herrera wrote: Tom Lane wrote: Greg Stark st...@enterprisedb.com writes: On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID fail :) It's a bad idea

Re: [HACKERS] Ignore -- testing message-id on footer

Marc G. Fournier wrote: Why a patch? Why not just: configset DEFAULT message_footer ENDAAB - -- Sent via $LIST mailing list ($l...@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/$LIST -- Archives URL:

Re: [HACKERS] Ignore -- testing message-id on footer

Try that, should be fixed ... On Tue, 17 Mar 2009, Alvaro Herrera wrote: Marc G. Fournier wrote: Why a patch? Why not just: configset DEFAULT message_footer ENDAAB - -- Sent via $LIST mailing list ($l...@postgresql.org) To make changes to your subscription:

Re: [HACKERS] ignore $PostgreSQL lines in regression tests?

* Tom Lane ([EMAIL PROTECTED]) wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Recently while adding $PostgreSQL markers to a bunch of .c and .h files I ran into trouble with the ecpg regression tests and had to revert the change for a handful of files. However, it occurred to me that we

[HACKERS] ignore $PostgreSQL lines in regression tests?

Recently while adding $PostgreSQL markers to a bunch of .c and .h files I ran into trouble with the ecpg regression tests and had to revert the change for a handful of files. However, it occurred to me that we could have pg_regress tell diff to ignore such lines, by passing it the arguments

Re: [HACKERS] ignore $PostgreSQL lines in regression tests?

Andrew Dunstan [EMAIL PROTECTED] writes: Recently while adding $PostgreSQL markers to a bunch of .c and .h files I ran into trouble with the ecpg regression tests and had to revert the change for a handful of files. However, it occurred to me that we could have pg_regress tell diff to

Re: [HACKERS] ignore $PostgreSQL lines in regression tests?

Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Recently while adding $PostgreSQL markers to a bunch of .c and .h files I ran into trouble with the ecpg regression tests and had to revert the change for a handful of files. However, it occurred to me that we could have pg_regress

[HACKERS] Ignore, just a test ...

Upgraded the News Server, and need to make sure gateways are working ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of

[HACKERS] ignore this test

---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

[HACKERS] ignore yet another test ...

---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[HACKERS] Ignore prior post -- Where is src/interfaces/perl5 in beta 5?

On Sun, 10 Nov 2002 16:29:03 -0600 GB Clark [EMAIL PROTECTED] wrote: Hello, Well the subject says it all. It was there in the last beta I was testing which was beta 1. Am I being dense here, or is it really missing? Thanks, GB It was me being dense! It has been removed. Sorry for

[HACKERS] ignore

fixing a problem with the aliases, just want to make sure it goes through propelry ... ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL

[HACKERS] ignore me

foobar ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

[HACKERS] Ignore this ...

Just a test ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster