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 change for DefineIndex,

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 I'm not pushing for

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 goes that use of DROP I

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 detail of ALTER TABLE

[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 is

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 wrote: > Michael Paquier 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

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

Michael Paquier 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 more such files, but the do

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 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 with some custom parame

[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 used

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 fixin

[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 partially

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 schrieb: > > > > >Bruce Momjian writes: > > >> Should I just patch pg_upgrade to remove the "indisvalid", skip > > >> "indisvalid" indexes, and backpa

Re: [HACKERS] Ignore invalid indexes in pg_dump.

"anara...@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 IndexIsValid() macro in

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 schrieb: > > > > >"anara...@anarazel.de" writes: > > >> Tom Lane schrieb: > > >>> Yeah, if you can just ignore !indisvalid indexes that should work > >

Re: [HACKERS] Ignore invalid indexes in pg_dump.

On Thu, Mar 28, 2013 at 10:47:55PM +0100, anara...@anarazel.de wrote: > > > Tom Lane schrieb: > > >"anara...@anarazel.de" writes: > >> Tom Lane 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

Re: [HACKERS] Ignore invalid indexes in pg_dump.

Tom Lane schrieb: >"anara...@anarazel.de" writes: >> Tom Lane 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.

"anara...@anarazel.de" writes: > Tom Lane 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 > indexes. No? No, he doesn

Re: [HACKERS] Ignore invalid indexes in pg_dump.

On Thu, Mar 28, 2013 at 10:31:51PM +0100, anara...@anarazel.de wrote: > > > Tom Lane schrieb: > > >Bruce Momjian 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 ma

Re: [HACKERS] Ignore invalid indexes in pg_dump.

Tom Lane schrieb: >Bruce Momjian 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 che

Re: [HACKERS] Ignore invalid indexes in pg_dump.

Bruce Momjian 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"? Yeah,

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

On Wed, Mar 27, 2013 at 6:47 AM, Tom Lane wrote: > Michael Paquier 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 th

Re: [HACKERS] Ignore invalid indexes in pg_dump

Michael Paquier 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 making two new version di

Re: [HACKERS] Ignore invalid indexes in pg_dump

On Thu, Mar 21, 2013 at 12:58 AM, Tom Lane 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 won't *be* any un

Re: [HACKERS] Ignore invalid indexes in pg_dump

Josh Kupershmidt writes: > On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs 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 is included by pg_dump, it will li

Re: [HACKERS] Ignore invalid indexes in pg_dump

On Wed, Mar 20, 2013 at 2:00 AM, Simon Riggs wrote: > On 20 March 2013 02:51, Michael Paquier 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 be

Re: [HACKERS] Ignore invalid indexes in pg_dump

On 20 March 2013 02:51, Michael Paquier 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 restore. > So why not removin

[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 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 l

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

Alvaro Herrera 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 away from that idea.

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 mke2f

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

Brian Pitts 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. > Attache

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

On Tue, Aug 9, 2011 at 1:52 PM, 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 o

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 o

[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 whi

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

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

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

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

On Tue, 17 Mar 2009, Alvaro Herrera wrote: Tom Lane wrote: Greg Stark writes: On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera 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 you think it

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 writes: > > > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > > > wrote: > > >> This email on the web: > > >> http://archives.postgresql.org/message-id/$MESSAGE_ID > > > > > fail :) > > > > It's a bad i

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

Tom Lane wrote: > Greg Stark writes: > > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > > 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 you think it's a bad idea? I had

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

Greg Stark writes: > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > 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 pgsql-hackers mailing list (pgsql-hackers@postgr

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

Greg Stark wrote: > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > 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 of variable it se

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

On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera 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: http://www.postgresql.org/mailpr

[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: http://www.postgresql.org/mail

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

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_regres

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

[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 "

[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 broadcast)--

[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.

[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 PROTECTED

[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 ...

testing a fix to a problem ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[HACKERS] Ignore this ...

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