[HACKERS] Dry-run mode for pg_archivecleanup
Hi guys,
I have added the '-n' option to pg_archivecleanup which performs a
dry-run and outputs the names of the files to be removed to stdout
(making possible to pass the list via pipe to another process).
Please find attached the small patch. I submit it to the CommitFest.
Thanks,
Gabriele
--
Gabriele Bartolini - 2ndQuadrant Italia
PostgreSQL Training, Services and Support
gabriele.bartol...@2ndquadrant.it | www.2ndQuadrant.it
*** a/contrib/pg_archivecleanup/pg_archivecleanup.c
--- b/contrib/pg_archivecleanup/pg_archivecleanup.c
***
*** 36,41 const char *progname;
--- 36,42
/* Options and defaults */
bool debug = false; /* are we debugging? */
+ bool dryrun = false; /* are we performing a dry-run
operation? */
char *archiveLocation;/* where to find the archive? */
char *restartWALFileName; /* the file from which we can restart restore */
***
*** 123,128 CleanupPriorWALFiles(void)
--- 124,136
fprintf(stderr, %s: removing file
\%s\\n,
progname, WALFilePath);
+ if (dryrun)
+ {
+ /* Prints the name of the file and
+* skips the actual removal of the file
*/
+ fprintf(stdout, %s\n, WALFilePath);
+ continue;
+ }
rc = unlink(WALFilePath);
if (rc != 0)
{
***
*** 205,210 usage(void)
--- 213,219
printf( %s [OPTION]... ARCHIVELOCATION OLDESTKEPTWALFILE\n,
progname);
printf(\nOptions:\n);
printf( -d generates debug output (verbose mode)\n);
+ printf( -n shows the names of the files that would
have been removed (dry-run)\n);
printf( --help show this help, then exit\n);
printf( --version output version information, then exit\n);
printf(\n
***
*** 241,253 main(int argc, char **argv)
}
}
! while ((c = getopt(argc, argv, d)) != -1)
{
switch (c)
{
case 'd': /* Debug mode */
debug = true;
break;
default:
fprintf(stderr, Try \%s --help\ for more
information.\n, progname);
exit(2);
--- 250,265
}
}
! while ((c = getopt(argc, argv, dn)) != -1)
{
switch (c)
{
case 'd': /* Debug mode */
debug = true;
break;
+ case 'n': /* Dry-Run mode */
+ dryrun = true;
+ break;
default:
fprintf(stderr, Try \%s --help\ for more
information.\n, progname);
exit(2);
*** a/doc/src/sgml/pgarchivecleanup.sgml
--- b/doc/src/sgml/pgarchivecleanup.sgml
***
*** 98,103 pg_archivecleanup: removing file
archive/00010037000E
--- 98,112
/listitem
/varlistentry
+ varlistentry
+ termoption-n/option/term
+ listitem
+para
+ Print the names of the files that would have been removed on
filenamestdout/ (performs a dry run).
+/para
+ /listitem
+ /varlistentry
+
/variablelist
/para
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Dry-run mode for pg_archivecleanup
On Sun, Dec 11, 2011 at 15:52, Gabriele Bartolini gabriele.bartol...@2ndquadrant.it wrote: Hi guys, I have added the '-n' option to pg_archivecleanup which performs a dry-run and outputs the names of the files to be removed to stdout (making possible to pass the list via pipe to another process). Please find attached the small patch. I submit it to the CommitFest. Sounds like a useful feature. But you added it to the wrong commitfest ;) I've moved it to the proper one (2012-01). -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [REVIEW] Patch for cursor calling with named parameters
On 2011-12-06 17:58, Kevin Grittner wrote: Kevin Grittnerkgri...@wicourts.gov wrote: Yeb Havingayebhavi...@gmail.com wrote: I personally tend to believe it doesn't even need to be an error. There is no technical reason not to allow it. All the user needs to do is make sure that the combination of named parameters and the positional ones together are complete and not overlapping. If there are no objections, I suggest that Yeb implement the mixed notation for cursor parameters. Hearing no objections -- Yeb, are you OK with doing this, and do you feel this is doable for this CF? Attach is v6 of the patch, allowing mixed mode and with new test cases in the regression tests. One difference with calling functions remains: it is allowed to place positional arguments after named parameters. Including that would add code, but nothing would be gained. regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers
Hi, Andres Freund and...@anarazel.de writes: Hm. I just noticed a relatively big hole in the patch: The handling of deletion of dependent objects currently is nonexistant because they don't go through ProcessUtility... That's the reason why we're talking about “command triggers” rather than “DDL triggers”. We don't intend to fire the triggers at each DDL operation happening on the server, but for each command. This restriction still allows us to provide a very useful feature when checked against the main use cases we target here. Those are auditing, and replication (the replay will also CASCADEs), and a generic enough SUDO facility (because the trigger function can well be SECURITY DEFINER). We could also add a 'cascading bool' parameter to the trigger function API and have that always false in 9.2, then choose what to fill the other parameters with in a later release. The obvious risk would be to decide that we need another API, then we didn't make a good move after all. My current feeling and vote is thus to leave that alone and document the restriction. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers
On sön, 2011-12-11 at 04:26 +0100, Andres Freund wrote: Building a CreateStmt seems to work well enough so far. The only problem with that approach so far that I found is that: CREATE TABLE collate_test2 ( a int, b text COLLATE POSIX ); CREATE TABLE collate_test1 ( a int, b text COLLATE C NOT NULL ); CREATE TABLE test_u AS SELECT a, b FROM collate_test1 UNION ALL SELECT a, b FROM collate_test2; -- fail failed with: ERROR: no collation was derived for column b with collatable type text HINT: Use the COLLATE clause to set the collation explicitly. works now. Could you explain why the above should fail? After all the UNION is valid outside the CREATE TABLE and you can even sort on b. That would be strange, because earlier in the test file there is also SELECT a, b FROM collate_test1 UNION ALL SELECT a, b FROM collate_test2 ORDER BY 2; -- fail The union itself is valid, but because it combines two different collations, the collation derivation for the column is unknown, and so it cannot be ordered. And we made the implementation decision to not allow creating columns with unknown collation. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch for type privileges
On lör, 2011-12-10 at 16:16 +0100, Yeb Havinga wrote: * ExecGrant_type() prevents 'grant usage on domain' on a type, but the converse is possible. postgres=# create domain myint as int2; CREATE DOMAIN postgres=# grant usage on type myint to public; GRANT This is the same as how we handle types vs. domains elsewhere. For example, you can use DROP TYPE to drop a domain, but you can't use DROP DOMAIN to drop a type. * Cannot restrict access to array types. After revoking usage from the element type, the error is perhaps a bit misleading. (smallint[] vs smallint) postgres= create table a (a int2[]); ERROR: permission denied for type smallint[] OK, that error message should be improved. * The patch adds the following text explaining the USAGE privilege on types. For types and domains, this privilege allow the use of the type or domain in the definition of tables, functions, and other schema objects. Since other paragraphs in USAGE use the word 'creation' instead of 'definition', I believe here the word 'creation' should be used too. IMHO it would also be good to describe what the USAGE privilege is not, but might be expected since it is such a generic term. USAGE on type: use of the type while creating new dependencies to the type, not usage in the sense of instantiating values of the type. If there are existing dependencies, revoking usage privileges will not return any warning and the dependencies still exist. Also other kinds of exceptions could be noted, such as the exception for array types and casts. The example you gave in the top mail about why restricting access to types can be useful, such as preventing that owners are prevented changing their types because others have 'blocked' them by their usage, is something that could also help readers of the documentation understand why privileges on types are useful for them (or not). Good suggestions. I'll review the text. * The information schema view 'attributes' has this additional condition: AND (pg_has_role(t.typowner, 'USAGE') OR has_type_privilege(t.oid, 'USAGE')); What happens is that attributes in a composite type are shown, or not, if the current user has USAGE rights. The strange thing here, is that the attribute in the type being show or not, doesn't match being able to use it (in the creation of e.g. a table). Yeah, that's a bug. That should be something like AND (pg_has_role(c.relowner, 'USAGE') OR has_type_privilege(c.reltype, 'USAGE')); I'll produce a new patch for these issues in a bit. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_cancel_backend by non-superuser
2011/12/6 Magnus Hagander mag...@hagander.net: On Sun, Oct 2, 2011 at 23:32, Tom Lane t...@sss.pgh.pa.us wrote: Noah Misch n...@leadboat.com writes: On Sun, Oct 02, 2011 at 06:55:51AM -0400, Robert Haas wrote: On Sat, Oct 1, 2011 at 10:11 PM, Euler Taveira de Oliveira eu...@timbira.com wrote: I see. What about passing this decision to DBA? I mean a GUC can_cancel_session = user, dbowner (default is '' -- only superuser). You can select one or both options. This GUC can only be changed by superuser. Or how about making it a grantable database-level privilege? I think either is overkill. You can implement any policy by interposing a SECURITY DEFINER wrapper around pg_cancel_backend(). I'm with Noah on this. If allowing same-user cancels is enough to solve 95% or 99% of the real-world use cases, let's just do that. There's no very good reason to suppose that a GUC or some more ad-hoc privileges will solve a large enough fraction of the rest of the cases to be worth their maintenance effort. In particular, I think both of the above proposals assume way too much about the DBA's specific administrative requirements. +1. Torello, are you up for updating your patch to do this, for now? If not, I'll be happy to create an updated patch that does just this, but since you got started on it... Sorry for the long delay. I will try to adjust the patch and submit for the next Commit Fest if this is ok for you. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Support for foreign keys with arrays
On Sat, Dec 10, 2011 at 09:47:53AM +0100, Gabriele Bartolini wrote: Il 20/11/11 14:05, Noah Misch ha scritto: What about making ON UPDATE CASCADE an error? That way, we can say that ARRAY action always applies to array elements, and plainaction always applies to entire rows. SET DEFAULT should now be fine to allow. It's ARRAY SET DEFAULT, in your new terminology, that wouldn't make sense. I have tried to gather your ideas with Gianni's and come to a compromise, which I hope you can both agree on. The reason why I would be inclined to leave CASCADE act on rows (rather than array elements as Gianni suggests) is for backward compatibility (people that are already using referential integrity based on array values). For the same reason, I am not sure whether we should raise an error on update, but will leave this for later. Your conclusion is reasonable, but I don't understand this argument for it. The patch does not change the meaning of any SQL that works today. So, here is a summary: --- - - | ON| ON| Action | DELETE | UPDATE | --- - - CASCADE| Row | Error | SET NULL | Row | Row | SET DEFAULT| Row | Row | ARRAY CASCADE | Element | Element | ARRAY SET NULL | Element | Element | NO ACTION |-|-| RESTRICT |-|-| --- - - If that's fine with you guys, Marco and I will refactor the development based on these assumptions. Looks fine. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Support for foreign keys with arrays
On Thu, Nov 17, 2011 at 12:08:32AM -0500, Tom Lane wrote: The least we could do is invent some non-spec syntax that makes the intention clear, rather than having the system assume that an error case was intended to mean something else. Maybe pids INTEGER[] ARRAY REFERENCES pt, +1. Perhaps this for the table_constraint syntax: FOREIGN KEY (ARRAY foo, bar, ARRAY pids) REFERENCES pt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do regression tests now leave regress_test_role_super around?
On Fri, Dec 9, 2011 at 10:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: As of commit fc6d1006bda783cc002c61a5f072905849dbde4b, the regression tests leave an unused role sitting around, because that commit removed DROP ROLE regress_test_role_super; from foreign_data.sql. Was that intentional? No. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Arithmetic operators for macaddr type
Hello folks, I just bumped into a situation where I wanted to do a little macaddr arithmetic in postgres. I note that the inet type has support for bitwise AND, OR and NOT, as well as subtraction, but macaddr has none of the above. These operations are easy to perform in C, but relatively a pain to do in SQL, especially as there doesn't seem to be a direct way to get a macaddr into a plain numeric form. I can't see any reason why postgres shouldn't support these operations on macaddr. I'd like to add them as fully realised operators in core. Would that be acceptable? Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Arithmetic operators for macaddr type
2011/12/12 Brendan Jurd dire...@gmail.com: Hello folks, I just bumped into a situation where I wanted to do a little macaddr arithmetic in postgres. I note that the inet type has support for bitwise AND, OR and NOT, as well as subtraction, but macaddr has none of the above. These operations are easy to perform in C, but relatively a pain to do in SQL, especially as there doesn't seem to be a direct way to get a macaddr into a plain numeric form. I can't see any reason why postgres shouldn't support these operations on macaddr. I'd like to add them as fully realised operators in core. Would that be acceptable? +1 Pavel Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
