Re: [HACKERS] PostgreSQL in Windows console and Ctrl-C
From: Christian Ullrich ch...@chrullrich.net OK, here is the first draft against current master. It builds on Windows with VS 2012 and on FreeBSD 10 with clang 3.3. I ran the regression tests on Windows, they all pass. The changed behavior is limited to Windows, where it now silently ignores Ctrl-C and Ctrl-Break when started via pg_ctl start. I don't think there is currently any support for switch-type long options, so rather than invent my own, I squeezed the two lines I added into postmaster.c where they fit best; unfortunately, the result is quite ugly. I'll be happy to refine that if someone can give me a hint on how to do it. Overall, the patch seems good as it is based on the discussion. I found a few problems: (1) The patch doesn't apply to HEAD. Could you rebase your patch? patching file src/bin/pg_ctl/pg_ctl.c Hunk #1 FAILED at 453. 1 out of 1 hunk FAILED -- saving rejects to file src/bin/pg_ctl/pg_ctl.c.rej (2) Although I haven't tried, doesn't pg_ctl start fail on non-Windows platforms because of the following check? !if (opt == '-') ! ereport(ERROR, ! (errcode(ERRCODE_SYNTAX_ERROR), !errmsg(--%s requires a value, ! optarg))); And, in the postgres reference page, http://www.postgresql.org/docs/devel/static/app-postgres.html there's a paragraph: The -- options will not work on FreeBSD or OpenBSD. Use -c instead. This is a bug in the affected operating systems; a future release of PostgreSQL will provide a workaround if this is not fixed. Would --background work on FreeBSD and OpenBSD (i.e. would pg_ctl start succeed)? I don't have access to those platforms. (3) --background will also be used by restart subcommand, won't it? + in a console window. It is used automatically by + commandpg_ctl/command when called with the + optionstart/option subcommand. Regards MauMau -- 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] crash with assertions and WAL_DEBUG
On 06/15/2014 12:26 AM, Alvaro Herrera wrote: Andres Freund wrote: On 2014-06-14 16:57:33 -0400, Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: I noticed that HEAD crashes at startup with assertions disabled and WAL_DEBUG turned on: I'm beginning to think we're going to have to give up on that no-pallocs-in-critical-sections Assert. It was useful to catch unnecessarily-dangerous allocations in mainline cases, but getting rid of every last corner-case palloc is looking to be, if not impossible, at least a lot more trouble than it is worth. I think we at least need to remove it from 9.4. We shouldn't release with an assertion that still regularly triggers in more or less 'harmless' situations. Yeah, removing it in 9.4 is likely a good idea -- we have an open item about it in connection with LWLOCK_DEBUG, and now this. Who knows what other debugging features will cause trouble. Agreed, I'll remove it from REL9_4_STABLE. I think it might be worthwile to keep it in master to help maintain the rule against allocations in critical sections. And perhaps as a reminder that e.g. the checkpointer is doing bad things... I also agree with keeping it in 9.5. Yeah. Now, to fix the case at hand, the quickest fix would be to allocate the messages in ErrorContext, which is already exempt from assertion. That's pretty hacky, though. Tom's suggestion to somehow mark specific pallocs as OK seems cleaner. It's a bit difficult to attach the mark to the palloc calls, as neither the WAL_DEBUG or LWLOCK_STATS code is calling palloc directly, but marking specific MemoryContexts as sanctioned ought to work. I'll take a stab at that. - Heikki -- 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] Window function optimisation, allow pushdowns of items matching PARTITION BY clauses
On 21 June 2014 01:38, Vik Fearing vik.fear...@dalibo.com wrote: I've had a chance to look at this and here is my review. On 04/14/2014 01:19 PM, David Rowley wrote: I've included the updated patch with some regression tests. The first thing I noticed is there is no documentation, but I don't think we document such things outside of the release notes, so that's probably normal. This prompted me to have a look to see if there's anything written in the documents about the reasons why we might not push quals down, but I didn't manage to find anything to that affect. The final test I added tests that an unused window which would, if used, cause the pushdown not to take place still stops the pushdownf from happening... I know you both talked about this case in the other thread, but I've done nothing for it as Tom mentioned that this should likely be fixed elsewhere, if it's even worth worrying about at all. I'm not quite sure if I needed to bother including this test for it, but I did anyway, it can be removed if it is deemed unneeded. I don't think this test has any business being in this patch. Removal of unused things should be a separate patch and once that's done your patch should work as expected. This regression test you have here almost demands that that other removal patch shouldn't happen. Agreed, I've removed that test now. Per Thomas' comments, I added a couple of tests that ensure that the order of the columns in the partition by clause don't change the behaviour. Looking at the implementation of the actual code makes this test seems a bit unneeded as really but I thought that the test should not assume anything about the implementation so from that point of view the extra test seems like a good idea. Every possible permutation of everything is overkill, but I think having a test that makes sure the pushdown happens when the partition in question isn't first in the list is a good thing. In the updated patch I've removed some a few extra tests that were just testing the same clauses in the PARTITION BY but in a different order. For now I can't think of much else to do for the patch, but I'd really appreciate it Thomas if you could run it through the paces if you can find any time for it, or maybe just give my regression tests a once over to see if you can think of any other cases that should be covered. I'm not Thomas, but... This patch is very simple. There's nothing wrong with that, of course, but I wonder how hard it would be to push more stuff down. For example, you have this case which works perfectly by not pushing down: SELECT * FROM ( SELECT partid, winagg() OVER (PARTITION BY partid+0) FROM t) wa WHERE partid = 1; But then you have this case which doesn't push down: SELECT * FROM ( SELECT partid, winagg() OVER (PARTITION BY partid+0) FROM t) wa WHERE partid+0 = 1; I don't know what's involved in fixing that, or if we do that sort of thing elsewhere, but it's something to consider. I had a look at this and at first I thought it was just as simple as removing the if (tle-resjunk) continue; from check_output_expressions, but after removing that I see that it's a bit more complex. In qual_is_pushdown_safe it pulls (using pull_var_clause) the Vars from the outer WHERE clause and not the whole expression, it then checks, in your case if partid (not partid+0) is safe to push down, and sees that it's not, due to this patches code marking it as not because partid is not in the PARTITION BY clause. I really don't think it's the business of this patch to make changes around here. Perhaps it would be worth looking into in more detail in the future. Although, you can probably get what you want by just writing the query as: SELECT * FROM ( SELECT partid+0 as partid, count(*) OVER (PARTITION BY partid+0) FROM t) wa WHERE partid = 1; Or if you really need the unmodified partid, then you could add another column to the target list and just not do select * in the outer query. Multi-column pushdowns work as expected. I have an issue with some of the code comments: In subquery_is_pushdown_safe you reduced the number of points from three to two. The comments used to say Check point 1 and Check point 2 but the third was kind of tested throughout the rest of the code so didn't have a dedicated comment. Now that there are only two checks, the Check point 1 without a 2 seems a little bit odd. The attached patch provides a suggestion for improvement. The same kind of weirdness is found in check_output_expressions but I don't really have any suggestions to fix it so I just left it. The attached patch also fixes some typos. That seems like a good change, oh and well spotted on the typo. I've applied your patch into my local copy of the code here. Thanks I'm marking this Waiting on Author pending discussion on pushing down entire
Re: [HACKERS] proposal: new long psql parameter --on-error-stop
eFrom: Pavel Stehule pavel.steh...@gmail.com here is a prototype: The patch applied and built with success. There are a few minor things: (1) help_variables() lacks description of some variables such as SINGLELINE and SINGLESTEP. I think this help should list all available variables, because users may want to know the existence of those missing variables. Based on this, modify these lines: remove some from the first line and the entire second line. + printf(_(List of some variables (options) for use from command line.\n)); + printf(_(Complete list you find in psql section in the PostgreSQL documentation.\n\n)); (2) The indent is different from other lines. Leave just two spaces at the beginning of the line. + printf(_( --help-variables list of available configuration variables (options), then exit\n)); (3) This change is unnecessary. See src/bin/pg_dumpall.c for similar switches. - while ((c = getopt_long(argc, argv, aAc:d:eEf:F:h:HlL:no:p:P:qR:sStT:U:v:VwWxXz?01, or+ while ((c = getopt_long(argc, argv, aAc:d:eEf:F:h:HlL:no:p:P:qR:sStT:U:v:VwWxXz?001, Regards MauMau -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] review: tab completion for set search_path TO
Hello, this patch https://commitfest.postgresql.org/action/patch_view?id=1443 is trivial with zero risk. Patch is applicable without any issues, compilation was without any issues too. Only one open question is there - should by system schemas visible for autocompleation or not. There was not 100% agreement in related discussion. I am inclined to think so preferable variant is without system schemas - they are used implicitly and has no sense use it on first position. But on second hand this detail is not significant and it is hard to get some objective arguments for one or second variant. Next, this behave can be simply changed without any impacts if we don't choose well now - so I would to mark this patch as ready for commit. Regards Pavel
Re: [HACKERS] Minmax indexes
I'm sorry if I missed something, but ISTM this is beginning to look a lot like GiST. This was pointed out by Robert Haas last year. On Wed, Jun 18, 2014 at 12:09:42PM -0300, Claudio Freire wrote: So, you have: An aggregate to generate a compressed set from several values Which GiST does by calling 'compress' on each value, and the 'unions' the results together. A function which adds a new value to the compressed set and returns the new compressed set Again, 'compress' + 'union' A function which tests if a value is in a compressed set Which GiST does using 'compress' +'consistant' A function which tests if a compressed set overlaps another compressed set of equal type Which GiST calls 'consistant' So I'm wondering why you can't just reuse the btree_gist functions we already have in contrib. It seems to me that these MinMax indexes are in fact a variation on GiST that indexes the pages of a table based upon the 'union' of all the elements in a page. By reusing the GiST operator class you get support for many datatypes for free. If you can define different compressed sets, you can use this to generate both min/max indexes as well as bloom filter indexes. Whether we'd want to have both is perhaps questionable, but having the ability to is probably desirable. You could implement bloom filter in GiST too. It's been discussed before but I can't find any implementation. Probably because the filter needs to be parameterised and if you store the bloom filter for each element it gets expensive very quickly. However, hooked into a minmax structure which only indexes whole pages it could be quite efficient. One problem with such a generalized implementation would be, that I'm not sure in-place modification of the compressed set on-disk can be assumed to be safe on all cases. Surely, for strictly-enlarging sets it would, but while min/max and bloom filters both fit the bill, it's not clear that one can assume this for all structures. I think GiST has already solved this problem. Have a nice day, -- Martijn van Oosterhout klep...@svana.org http://svana.org/kleptog/ He who writes carelessly confesses thereby at the very outset that he does not attach much importance to his own thoughts. -- Arthur Schopenhauer signature.asc Description: Digital signature
Re: [HACKERS] idle_in_transaction_timeout
Andrew Dunstan and...@dunslane.net wrote: On 06/19/2014 06:33 PM, Josh Berkus wrote: ISTM our realistic options are for seconds or msec as the unit. If it's msec, we'd be limited to INT_MAX msec or around 600 hours at the top end, which seems like enough to me but maybe somebody thinks differently? Seconds are probably OK but I'm worried about somebody complaining that that's not enough resolution, especially as machines get faster. I can picture a 500ms timeout more readily than I can picture a 1000hr timeout. As long as we can specify the units, and don't have to say 1000 to mean 1 second, I agree. I would normally expect this to be set in terms of minutes rather than millisecs. OK, so I think we want to see a patch based on v1 (FATAL approach) with a change of the name to idle_in_transaction_session_timeout and the units changed to milliseconds. I don't see why the remoteversion test shouldn't be changed to use 90500 now, too. I'll flip this to Waiting on Author for those changes. -- Kevin Grittner EDB: 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] review: Built-in binning functions
review: https://commitfest.postgresql.org/action/patch_view?id=1484 Hello I did review of this patch, that add three functions varwidth_bucket for types: anyelement, double and bigint * This patch respects PostgreSQL coding rules * it can applied without any issues * there are no new compile warnings * patch contains documentation and tests * all tests was passed * there was no any objection in related discussion. Functionality is clean and based on current functionality of width_bucket. My comments: * I miss in documentation description of implementation - its is based on binary searching, and when second parameter is unsorted array, then it returns some nonsense without any warning. * Description for anyelement is buggy twice times varwidth_bucket(5.35::numeric, ARRAY[1, 3, 4, 6]::numeric) probably should be varwidth_bucket(5.35::numeric, ARRAY[1, 3, 4, 6]::numeric[]) BUT it is converted to double precision, function with polymorphic parameters is not used. So it not respects a widh_buckets model: postgres=# \dfS width_bucket List of functions Schema │ Name │ Result data type │ Argument data types │ Type ┼──┼──┼───┼ pg_catalog │ width_bucket │ integer │ double precision, double precision, double precision, integer │ normal pg_catalog │ width_bucket │ integer │ numeric, numeric, numeric, integer│ normal (2 rows) There should be a interface for numeric type too. I am sure so important part of code for polymorphic type can be shared. Regards Pavel
[HACKERS] SQL access to database attributes
Hello I am looking createdb_alterdb_grammar_refactoring.v1.patch http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com Is any reason or is acceptable incompatible change CONNECTION_LIMIT instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough for breaking compatibility? Surely this patch cannot be backported what is proposed there. Regards Pavel
Re: [HACKERS] SQL access to database attributes
Second question related to second patch: Must be new syntax ALLOW_CONNECTIONS? Should not be (ENABLE | DISABLE) CONNECTION ? This doesn't need any new keyword. Regards Pavel 2014-06-21 22:11 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com: Hello I am looking createdb_alterdb_grammar_refactoring.v1.patch http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com Is any reason or is acceptable incompatible change CONNECTION_LIMIT instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough for breaking compatibility? Surely this patch cannot be backported what is proposed there. Regards Pavel
Re: [HACKERS] SQL access to database attributes
On 06/21/2014 10:11 PM, Pavel Stehule wrote: Hello I am looking createdb_alterdb_grammar_refactoring.v1.patch http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com Thank you for looking at this. Is any reason or is acceptable incompatible change CONNECTION_LIMIT instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough for breaking compatibility? How is compatibility broken? The grammar still accepts the old way, I just changed the documentation to promote the new way. Surely this patch cannot be backported what is proposed there. There are reasons I can think of not to backport this first patch, but breaking compatibility isn't one of them. -- Vik -- 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] SQL access to database attributes
On 06/21/2014 10:21 PM, Pavel Stehule wrote: Second question related to second patch: Must be new syntax ALLOW_CONNECTIONS? It doesn't *have* to be called that, but that's what the corresponding column in pg_database is called so why add confusion? (Actually, it's called datallowconn but that would be a silly name on the SQL level.) Should not be (ENABLE | DISABLE) CONNECTION ? I don't think it should be, no. This doesn't need any new keyword. None of this requires any new keywords. That's the whole point of the refactoring patch. -- Vik -- 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] idle_in_transaction_timeout
On 06/21/2014 08:23 PM, Kevin Grittner wrote:
OK, so I think we want to see a patch based on v1 (FATAL approach)
with a change of the name to idle_in_transaction_session_timeout
and the units changed to milliseconds. I don't see why the
remoteversion test shouldn't be changed to use 90500 now, too.
The attached patch, rebased to current master, addresses all of these
issues.
I'll flip this to Waiting on Author for those changes.
And back to Needs Review.
--
Vik
*** a/contrib/postgres_fdw/connection.c
--- b/contrib/postgres_fdw/connection.c
***
*** 343,348 configure_remote_session(PGconn *conn)
--- 343,355
do_sql_command(conn, SET extra_float_digits = 3);
else
do_sql_command(conn, SET extra_float_digits = 2);
+
+ /*
+ * Ensure the remote server doesn't kill us off if we remain idle in a
+ * transaction for too long.
+ */
+ if (remoteversion = 90500)
+ do_sql_command(conn, SET idle_in_transaction_session_timeout = 0);
}
/*
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
***
*** 5545,5550 COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
--- 5545,5573
/listitem
/varlistentry
+ varlistentry id=guc-idle-in-transaction-session-timeout xreflabel=idle_in_transaction_session_timeout
+ termvarnameidle_in_transaction_session_timeout/varname (typeinteger/type)
+ indexterm
+primaryvarnameidle_in_transaction_session_timeout/ configuration parameter/primary
+ /indexterm
+ /term
+ listitem
+para
+Terminate any session with an open transaction that has been idle for
+longer than the specified duration in milliseconds. This allows any locks to
+be released and the connection slot to be reused.
+/para
+para
+Sessions in the state idle in transaction (aborted) occupy a connection
+slot but because they hold no locks, they are not considered by this
+parameter.
+/para
+para
+The default value of 0 means that such sessions will not be terminated.
+/para
+ /listitem
+ /varlistentry
+
varlistentry id=guc-vacuum-freeze-table-age xreflabel=vacuum_freeze_table_age
termvarnamevacuum_freeze_table_age/varname (typeinteger/type)
indexterm
*** a/doc/src/sgml/mvcc.sgml
--- b/doc/src/sgml/mvcc.sgml
***
*** 676,682 ERROR: could not serialize access due to read/write dependencies among transact
listitem
para
Don't leave connections dangling quoteidle in transaction/quote
!longer than necessary.
/para
/listitem
listitem
--- 676,684
listitem
para
Don't leave connections dangling quoteidle in transaction/quote
!longer than necessary. The configuration parameter
!xref linkend=guc-idle-in-transaction-session-timeout may be used to
!automatically disconnect lingering sessions.
/para
/listitem
listitem
*** a/src/backend/storage/lmgr/proc.c
--- b/src/backend/storage/lmgr/proc.c
***
*** 57,62
--- 57,63
int DeadlockTimeout = 1000;
int StatementTimeout = 0;
int LockTimeout = 0;
+ int IdleInTransactionSessionTimeout = 0;
bool log_lock_waits = false;
/* Pointer to this process's PGPROC and PGXACT structs, if any */
*** a/src/backend/tcop/postgres.c
--- b/src/backend/tcop/postgres.c
***
*** 3943,3948 PostgresMain(int argc, char *argv[],
--- 3943,3953
{
set_ps_display(idle in transaction, false);
pgstat_report_activity(STATE_IDLEINTRANSACTION, NULL);
+
+ /* Start the idle-in-transaction timer */
+ if (IdleInTransactionSessionTimeout 0)
+ enable_timeout_after(IDLE_IN_TRANSACTION_SESSION_TIMEOUT,
+ IdleInTransactionSessionTimeout);
}
else
{
***
*** 3976,3982 PostgresMain(int argc, char *argv[],
DoingCommandRead = false;
/*
! * (5) check for any other interesting events that happened while we
* slept.
*/
if (got_SIGHUP)
--- 3981,3993
DoingCommandRead = false;
/*
! * (5) turn off the idle-in-transaction timeout
! */
! if (IdleInTransactionSessionTimeout 0)
! disable_timeout(IDLE_IN_TRANSACTION_SESSION_TIMEOUT, false);
!
! /*
! * (6) check for any other interesting events that happened while we
* slept.
*/
if (got_SIGHUP)
***
*** 3986,3992 PostgresMain(int argc, char *argv[],
}
/*
! * (6) process the command. But ignore it if we're skipping till
* Sync.
*/
if (ignore_till_sync firstchar != EOF)
--- 3997,4003
}
/*
! * (7) process the command. But ignore it if we're skipping till
* Sync.
*/
if (ignore_till_sync firstchar != EOF)
*** a/src/backend/utils/errcodes.txt
--- b/src/backend/utils/errcodes.txt
***
***
Re: [HACKERS] proposal: new long psql parameter --on-error-stop
Hello
2014-06-21 15:51 GMT+02:00 MauMau maumau...@gmail.com:
eFrom: Pavel Stehule pavel.steh...@gmail.com
here is a prototype:
The patch applied and built with success. There are a few minor things:
(1)
help_variables() lacks description of some variables such as SINGLELINE
and SINGLESTEP. I think this help should list all available variables,
because users may want to know the existence of those missing variables.
Based on this, modify these lines: remove some from the first line and
the entire second line.
+ printf(_(List of some variables (options) for use from command
line.\n));
+ printf(_(Complete list you find in psql section in the PostgreSQL
documentation.\n\n));
I fixed it
(2)
The indent is different from other lines. Leave just two spaces at the
beginning of the line.
+ printf(_( --help-variables list of available configuration
variables (options), then exit\n));
I am not sure in this point. It is aligned left with all long options:
-?, --help show this help, then exit
--help-variables list of available configuration variables
(options), then exit
Input and output options:
-a, --echo-all echo all input from script
-e, --echo-queries echo commands sent to server
-E, --echo-hiddendisplay queries that internal commands generate
I am thinking so current implementation has sense.
(3)
This change is unnecessary. See src/bin/pg_dumpall.c for similar switches.
- while ((c = getopt_long(argc, argv, aAc:d:eEf:F:h:HlL:no:p:P:qR:
sStT:U:v:VwWxXz?01,
or+ while ((c = getopt_long(argc, argv, aAc:d:eEf:F:h:HlL:no:p:P:qR:
sStT:U:v:VwWxXz?001,
fixed
Regards
MauMau
updated patch is in attachment
Regards
Pavel
commit 826bd11fb4e9ac4b26cfe2e3702535f6b9527c12
Author: Pavel Stehule pavel.steh...@gmail.com
Date: Sun Jun 22 00:08:24 2014 +0200
initial
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 3aa3c16..aa11808 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -78,12 +78,13 @@ usage(void)
printf(_( -f, --file=FILENAME execute commands from file, then exit\n));
printf(_( -l, --list list available databases, then exit\n));
printf(_( -v, --set=, --variable=NAME=VALUE\n
- set psql variable NAME to VALUE\n));
+ set psql variable NAME to VALUE e.g.: -v ON_ERROR_STOP=1\n));
printf(_( -V, --versionoutput version information, then exit\n));
printf(_( -X, --no-psqlrc do not read startup file (~/.psqlrc)\n));
printf(_( -1 (\one\), --single-transaction\n
execute as a single transaction (if non-interactive)\n));
printf(_( -?, --help show this help, then exit\n));
+ printf(_( --help-variables list of available configuration variables (options), then exit\n));
printf(_(\nInput and output options:\n));
printf(_( -a, --echo-all echo all input from script\n));
@@ -279,6 +280,80 @@ slashUsage(unsigned short int pager)
}
+/*
+ * show list of available variables (options) from command line
+ */
+void
+help_variables(void)
+{
+ printf(_(List of variables (options) for use from command line.\n));
+
+ printf(_(psql variables:\n));
+ printf(_(Usage:\n));
+ printf(_( psql --set=NAME=VALUE\n or \\set NAME VALUE in interactive mode\n\n));
+
+ printf(_( AUTOCOMMIT when is on, successful SQL command is automatically commited\n));
+ printf(_( COMP_KEYWORD_CASE determines which letter case to use when completing an SQL key word\n));
+ printf(_( DBNAME the name of currently connected database\n));
+ printf(_( ECHO all lines from input can be written to standard output\n));
+ printf(_( ECHO_HIDDENdisplay queries for internal commands (same as -E option)\n));
+ printf(_( ENCODING the current client character set encoding\n));
+ printf(_( FETCH_COUNThow many rows should be for one page (default 0 unlimited)\n));
+ printf(_( HISTCONTROLwhen is set, control history list [ignorespace, ignoredups, ignoreboth]\n));
+ printf(_( HISTFILE file name that be used for store history list\n));
+ printf(_( HISTSIZE the number of commands to store in the command history\n));
+ printf(_( HOST the currently connected database server\n));
+ printf(_( IGNOREEOF if unset, sending an EOF to interactive session terminates application\n));
+ printf(_( LASTOIDthe value of last affected OID\n));
+ printf(_( ON_ERROR_ROLLBACK when is on, raise ROLLBACK on error automatically\n));
+ printf(_( ON_ERROR_STOP when is set, then batch execution stop immediately after error\n));
+ printf(_( PORT the database server port to which is currently used\n));
+ printf(_( PROPMPT1, PROPMT2, PROPMPT3 specify a look of psql prompt\n));
+ printf(_( QUIET when is
Re: [HACKERS] SQL access to database attributes
2014-06-21 23:14 GMT+02:00 Vik Fearing vik.fear...@dalibo.com: On 06/21/2014 10:11 PM, Pavel Stehule wrote: Hello I am looking createdb_alterdb_grammar_refactoring.v1.patch http://www.postgresql.org/message-id/53868e57.3030...@dalibo.com Thank you for looking at this. Is any reason or is acceptable incompatible change CONNECTION_LIMIT instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough for breaking compatibility? How is compatibility broken? The grammar still accepts the old way, I just changed the documentation to promote the new way. Surely this patch cannot be backported what is proposed there. There are reasons I can think of not to backport this first patch, but breaking compatibility isn't one of them. I am sorry, tomorrow I have to read it again Pavel -- Vik
Re: [HACKERS] proposal: new long psql parameter --on-error-stop
On Sun, June 22, 2014 00:10, Pavel Stehule wrote: [help-variables-01.patch ] +1. This patch is a very useful improvement, IMHO. I edited the text somewhat; and removed some obvious typos. thanks, Erik Rijkers--- src/bin/psql/help.c.orig 2014-06-22 00:31:55.450860460 +0200 +++ src/bin/psql/help.c 2014-06-22 01:28:23.546375133 +0200 @@ -292,36 +292,36 @@ printf(_(Usage:\n)); printf(_( psql --set=NAME=VALUE\n or \\set NAME VALUE in interactive mode\n\n)); - printf(_( AUTOCOMMIT when is on, successful SQL command is automatically commited\n)); + printf(_( AUTOCOMMIT successful SQL commands are automatically committed\n)); printf(_( COMP_KEYWORD_CASE determines which letter case to use when completing an SQL key word\n)); - printf(_( DBNAME the name of currently connected database\n)); - printf(_( ECHO all lines from input can be written to standard output\n)); - printf(_( ECHO_HIDDENdisplay queries for internal commands (same as -E option)\n)); - printf(_( ENCODING the current client character set encoding\n)); - printf(_( FETCH_COUNThow many rows should be for one page (default 0 unlimited)\n)); - printf(_( HISTCONTROLwhen is set, control history list [ignorespace, ignoredups, ignoreboth]\n)); - printf(_( HISTFILE file name that be used for store history list\n)); + printf(_( DBNAME name of currently connected database\n)); + printf(_( ECHO write all input lines to standard output\n)); + printf(_( ECHO_HIDDENdisplay internal queries (same as -E option)\n)); + printf(_( ENCODING current client character set encoding\n)); + printf(_( FETCH_COUNTthis many rows at a time (use less memory) (default 0 unlimited)\n)); + printf(_( HISTCONTROLwhen set, controls history list [ignorespace, ignoredups, ignoreboth]\n)); + printf(_( HISTFILE file name used to store the history list\n)); printf(_( HISTSIZE the number of commands to store in the command history\n)); printf(_( HOST the currently connected database server\n)); printf(_( IGNOREEOF if unset, sending an EOF to interactive session terminates application\n)); printf(_( LASTOIDthe value of last affected OID\n)); - printf(_( ON_ERROR_ROLLBACK when is on, raise ROLLBACK on error automatically\n)); - printf(_( ON_ERROR_STOP when is set, then batch execution stop immediately after error\n)); - printf(_( PORT the database server port to which is currently used\n)); - printf(_( PROPMPT1, PROPMT2, PROPMPT3 specify a look of psql prompt\n)); - printf(_( QUIET when is set, run quietly (same as -q option)\n)); - printf(_( SIGLELINE end of line terminates SQL command mode (same as -S option)\n)); + printf(_( ON_ERROR_ROLLBACK when on, ROLLBACK on error\n)); + printf(_( ON_ERROR_STOP stop batch execution after error\n)); + printf(_( PORT the database server port\n)); + printf(_( PROMPT1, PROMPT2, PROMPT3 specify the psql prompt\n)); + printf(_( QUIET run quietly (same as -q option)\n)); + printf(_( SINGLELINE end of line terminates SQL command mode (same as -S option)\n)); printf(_( SINGLESTEP confirm each query mode (same as -s option)\n)); - printf(_( USER the database user that are currently connected\n)); + printf(_( USER the database user currently connected\n)); printf(_( VERBOSITY control verbosity of error reports [default, verbose, terse]\n)); printf(_(\nPrinting options:\n)); printf(_(Usage:\n)); printf(_( psql --pset=NAME[=VALUE]\n or \\pset NAME [VALUE] in interactive mode\n\n)); - printf(_( border number of border style\n)); - printf(_( fieldsep specify field separator for unaligned output\n)); - printf(_( fieldsep_zero field separator in unaligned mode will be zero\n)); + printf(_( border border style (number)\n)); + printf(_( fieldsep field separator for unaligned output (default '|')\n)); + printf(_( fieldsep_zero set field separator in unaligned mode to zero\n)); printf(_( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n)); printf(_( linestyle sets the border line drawing style [ascii, old-ascii, unicode]\n)); printf(_( null sets the string to be printed in place of a null value\n)); @@ -333,7 +333,7 @@ printf(_(\nEnvironment options:\n)); printf(_(Usage:\n)); - printf(_( NAME=VALUE, [NAME=VALUE] psql ...\n or \\setenv NAME [VALUE] in interactive mode\n\n)); + printf(_( NAME=VALUE [NAME=VALUE] psql ...\n or \\setenv NAME [VALUE] in interactive mode\n\n)); printf(_( COLUMNSnumber of columns for wrapped format\n)); printf(_( PAGER used pager\n)); @@ -341,9 +341,10 @@ printf(_( PGHOST
Re: [HACKERS] proposal: new long psql parameter --on-error-stop
From: Pavel Stehule pavel.steh...@gmail.com I am not sure in this point. It is aligned left with all long options: -?, --help show this help, then exit --help-variables list of available configuration variables (options), then exit pg_dumpall aligns all options left with each other, whether they are short or long. -x, --no-privileges do not dump privileges (grant/revoke) --binary-upgrade for use by upgrade utilities only --column-inserts dump data as INSERT commands with column names Regards MauMau -- 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] idle_in_transaction_timeout
At 2014-06-21 23:54:58 +0200, vik.fear...@dalibo.com wrote: I'll flip this to Waiting on Author for those changes. And back to Needs Review. I've marked it Ready for Committer after a quick read-through. -- Abhijit -- 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] proposal: new long psql parameter --on-error-stop
2014-06-22 2:26 GMT+02:00 MauMau maumau...@gmail.com:
From: Pavel Stehule pavel.steh...@gmail.com
I am not sure in this point. It is aligned left with all long options:
-?, --help show this help, then exit
--help-variables list of available configuration variables
(options), then exit
pg_dumpall aligns all options left with each other, whether they are short
or long.
-x, --no-privileges do not dump privileges (grant/revoke)
--binary-upgrade for use by upgrade utilities only
--column-inserts dump data as INSERT commands with column
names
ok
I fixed it
Regards
Pavel
Regards
MauMau
commit e07af2c24cb8ae85ef6b3ec53baf3444bfa27ad3
Author: Pavel Stehule pavel.steh...@gmail.com
Date: Sun Jun 22 00:08:24 2014 +0200
show a list of psql internal, psql formatting and system variables used by psql
diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
index 3aa3c16..59030eb 100644
--- a/src/bin/psql/help.c
+++ b/src/bin/psql/help.c
@@ -78,12 +78,13 @@ usage(void)
printf(_( -f, --file=FILENAME execute commands from file, then exit\n));
printf(_( -l, --list list available databases, then exit\n));
printf(_( -v, --set=, --variable=NAME=VALUE\n
- set psql variable NAME to VALUE\n));
+ set psql variable NAME to VALUE e.g.: -v ON_ERROR_STOP=1\n));
printf(_( -V, --versionoutput version information, then exit\n));
printf(_( -X, --no-psqlrc do not read startup file (~/.psqlrc)\n));
printf(_( -1 (\one\), --single-transaction\n
execute as a single transaction (if non-interactive)\n));
printf(_( -?, --help show this help, then exit\n));
+ printf(_( --help-variables list of available configuration variables (options), then exit\n));
printf(_(\nInput and output options:\n));
printf(_( -a, --echo-all echo all input from script\n));
@@ -279,6 +280,80 @@ slashUsage(unsigned short int pager)
}
+/*
+ * show list of available variables (options) from command line
+ */
+void
+help_variables(void)
+{
+ printf(_(List of variables (options) for use from command line.\n));
+
+ printf(_(psql variables:\n));
+ printf(_(Usage:\n));
+ printf(_( psql --set=NAME=VALUE\n or \\set NAME VALUE in interactive mode\n\n));
+
+ printf(_( AUTOCOMMIT when is on, successful SQL command is automatically commited\n));
+ printf(_( COMP_KEYWORD_CASE determines which letter case to use when completing an SQL key word\n));
+ printf(_( DBNAME the name of currently connected database\n));
+ printf(_( ECHO all lines from input can be written to standard output\n));
+ printf(_( ECHO_HIDDENdisplay queries for internal commands (same as -E option)\n));
+ printf(_( ENCODING the current client character set encoding\n));
+ printf(_( FETCH_COUNThow many rows should be for one page (default 0 unlimited)\n));
+ printf(_( HISTCONTROLwhen is set, control history list [ignorespace, ignoredups, ignoreboth]\n));
+ printf(_( HISTFILE file name that be used for store history list\n));
+ printf(_( HISTSIZE the number of commands to store in the command history\n));
+ printf(_( HOST the currently connected database server\n));
+ printf(_( IGNOREEOF if unset, sending an EOF to interactive session terminates application\n));
+ printf(_( LASTOIDthe value of last affected OID\n));
+ printf(_( ON_ERROR_ROLLBACK when is on, raise ROLLBACK on error automatically\n));
+ printf(_( ON_ERROR_STOP when is set, then batch execution stop immediately after error\n));
+ printf(_( PORT the database server port to which is currently used\n));
+ printf(_( PROPMPT1, PROPMT2, PROPMPT3 specify a look of psql prompt\n));
+ printf(_( QUIET when is set, run quietly (same as -q option)\n));
+ printf(_( SIGLELINE end of line terminates SQL command mode (same as -S option)\n));
+ printf(_( SINGLESTEP confirm each query mode (same as -s option)\n));
+ printf(_( USER the database user that are currently connected\n));
+ printf(_( VERBOSITY control verbosity of error reports [default, verbose, terse]\n));
+
+ printf(_(\nPrinting options:\n));
+ printf(_(Usage:\n));
+ printf(_( psql --pset=NAME[=VALUE]\n or \\pset NAME [VALUE] in interactive mode\n\n));
+
+ printf(_( border number of border style\n));
+ printf(_( fieldsep specify field separator for unaligned output\n));
+ printf(_( fieldsep_zero field separator in unaligned mode will be zero\n));
+ printf(_( format set output format [unaligned, aligned, wrapped, html, latex, ..]\n));
+ printf(_( linestyle sets the border line drawing style [ascii, old-ascii, unicode]\n));
+ printf(_( null
Re: [HACKERS] How about a proper TEMPORARY TABLESPACE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/18/2014 08:00 PM, Stephen Frost wrote: PG would need to enforce that it's only used for temporary objects as well, of course.. Or at least, that was my thinking on this. A way to put UNLOGGED objects in such a space and have them recovered if they vanish would also be valuable, IMO. Not necessarily in the same patch, I'd just rather keep it in mind so any chosen design doesn't preclude adding that later. - -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTpmsOAAoJELBXNkqjr+S2SNUH/A1zor2WUbQg3PTyD+6wyxlM v6iMpH9zaeMWYyavIHM9N8a+h7hl9ajKDPMuK0vYLMs83W88LXI4T/t1iJlgZ3Po WhyjjdNonChn5v1NEJncb4KgqmRQxyWY43rzgEgofSJQgjFbo8UAwoD8Xa32ghDu 4dx2ijYqYsx/hC1Gb1u/HbQ9rX+OkTA0DwljdUgPqPorW/mn5RVscz9Qo5p/W+XH tdvpu9CKRi4AFPkshZOij+Mu3My863K1+k7sHUpRcsRGJT/AIO1V0wUQE2PuWTAV 5InU5vw/1C6CsYpH4v++XvpeTOnQ4QrMnllh99UTxV91UXN+jx/ENv1SYhBfYGE= =JGYF -END PGP SIGNATURE- -- 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] How about a proper TEMPORARY TABLESPACE?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/22/2014 01:35 PM, Craig Ringer wrote: A way to put UNLOGGED objects in such a space and have them recovered if they vanish would also be valuable, IMO. By which I mean re-created empty, as if after a crash. - -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTpmuwAAoJELBXNkqjr+S284oIALPSZVCkqv/A6Oriu48n9LOm KI0cnyiv+kJ8Kor8kDIbweM6DdaUaP0msQOj3vRh8t1GGldF1hmEo83IH/t+sx4t 3B2SUPmHQX5QHa27zmzCk8qAhYKYyUy/HOI0u2DxLm5fGtxpzCjyojo4k8+YkSgM b17eDGrAzlxXJF9BiRj4SBITOxekdgml0yF6J0UPWk98N4cTaXXsMv5r/QBlyXOm /3bdZ0rx0extLcuH+x9iUo7aXC4qCgFJ1ZEzp3xSVGVxU7VA3vQl1O1OR7GHRKJb E3SqS6RiHpWqT2JxD1su/a5XblpF/d5/EfXNxSY7etdNBBarHF5Q6xCNDNard8Y= =30iz -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
