Re: [HACKERS] psql: edit function, show function commands patch
2010/4/1 Bruce Momjian : > > I have added this to the next commit-fest. > thank you Pavel > --- > > Pavel Stehule wrote: >> Hello >> >> this simple patch allow to specify cursor row when some function is >> opened in editor. >> >> \e aaa.txt >> \a aaa.txt 3 ... move cursor on 3nd line of text >> \ef foo >> \ef foo 3 ... move cursor on 3nd line of function body >> \sf foo ... show function body >> \sf+ foo ... show function body - use line numbers >> \sf[+] foo n ... show function body from line n >> >> postgres=# \sf foo >> >> CREATE OR REPLACE FUNCTION public.foo() >> RETURNS integer >> LANGUAGE plpgsql >> AS $function$ >> begin >> return 10/0; >> end; >> $function$ >> >> postgres=# \sf+ foo >> >> CREATE OR REPLACE FUNCTION public.foo() >> RETURNS integer >> LANGUAGE plpgsql >> 1 AS $function$ >> 2 begin >> 3 return 10/0; >> 4 end; >> $function$ >> >> Regards >> Pavel Stehule > > [ Attachment, skipping... ] > >> >> -- >> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-hackers > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.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] Alpha release this week?
On Wed, Mar 31, 2010 at 10:34 PM, Robert Haas wrote: > On Wed, Mar 31, 2010 at 3:29 PM, Dave Page wrote: >> On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas wrote: >>> I can snap a tarball tonight if you want. I'm going to be leaving >>> town tomorrow afternoon, though. >> >> Works for me. I'll stuff it into our shiny new 9.0 build machine tomorrow. > > Marc is going to set up me up with access to a more appropriate > location, but in the meantime, here's alpha5: > > https://commitfest.postgresql.org/release/ > > sha1sum: > > 54c1f3fda64c675ee3882c0f5be3fdc44e6d0323 postgresql-9.0alpha5.tar.bz2 > a3099fc8090f5793c3dd7b9ee5dae7a622b29d87 postgresql-9.0alpha5.tar.gz This stuff is now also at: ftp://developer.postgresql.org/pub/source/9.0alpha5/ ...Robert -- 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: Add JSON support
I ended up reinventing the wheel and writing another JSON library: http://constellationmedia.com/~funsite/static/json-0.0.1.tar.bz2 This is a first release, and it doesn't really have a name besides "json". It's very similar to cJSON, except it is (sans unknown bugs) more reliable, more correct, and cleaner (unless you hate gotos ;-) ). It has a simple test suite. It is not prone to stack overflows, as it doesn't recurse. It is strict, requires input to be UTF-8 (it validates it first) and only outputs UTF-8. Other than treating numbers liberally, my implementation only accepts valid JSON code (it doesn't try to correct anything, even Unicode problems). It is under the MIT license. -- 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] Alias to rollback keyword
Robert Haas wrote: > On Wed, Mar 31, 2010 at 10:34 PM, Bruce Momjian wrote: > > Matthew Altus wrote: > >> Hey, > >> > >> After dealing with a production fault and having to rollback all the time, > >> I > >> kept typing a different word instead of rollback. ?So I created a patch to > >> accept this word as an alias for rollback. ?Obviously it's not part of the > >> sql > >> standard, but could be a nice extension for postgresql. ?See the patch for > >> more details. > > > > Applied. > > You know, I was about to write a rant about this, until I realized > what day it will be soon (or already is, UTC). CVS is GMT-based. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Alias to rollback keyword
On Wed, Mar 31, 2010 at 10:34 PM, Bruce Momjian wrote: > Matthew Altus wrote: >> Hey, >> >> After dealing with a production fault and having to rollback all the time, I >> kept typing a different word instead of rollback. So I created a patch to >> accept this word as an alias for rollback. Obviously it's not part of the >> sql >> standard, but could be a nice extension for postgresql. See the patch for >> more details. > > Applied. You know, I was about to write a rant about this, until I realized what day it will be soon (or already is, UTC). ...Robert -- 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] Alpha release this week?
On Wed, Mar 31, 2010 at 3:29 PM, Dave Page wrote: > On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas wrote: >> I can snap a tarball tonight if you want. I'm going to be leaving >> town tomorrow afternoon, though. > > Works for me. I'll stuff it into our shiny new 9.0 build machine tomorrow. Marc is going to set up me up with access to a more appropriate location, but in the meantime, here's alpha5: https://commitfest.postgresql.org/release/ sha1sum: 54c1f3fda64c675ee3882c0f5be3fdc44e6d0323 postgresql-9.0alpha5.tar.bz2 a3099fc8090f5793c3dd7b9ee5dae7a622b29d87 postgresql-9.0alpha5.tar.gz ...Robert -- 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] Alias to rollback keyword
Matthew Altus wrote: > Hey, > > After dealing with a production fault and having to rollback all the time, I > kept typing a different word instead of rollback. So I created a patch to > accept this word as an alias for rollback. Obviously it's not part of the > sql > standard, but could be a nice extension for postgresql. See the patch for > more details. Applied. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Alias to rollback keyword
On Mar 31, 2010, at 5:42 PM, Matthew Altus wrote: > After dealing with a production fault and having to rollback all the time, I > kept typing a different word instead of rollback. So I created a patch to > accept this word as an alias for rollback. Obviously it's not part of the > sql > standard, but could be a nice extension for postgresql. See the patch for > more details. +100 Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Alias to rollback keyword
Hey,
After dealing with a production fault and having to rollback all the time, I
kept typing a different word instead of rollback. So I created a patch to
accept this word as an alias for rollback. Obviously it's not part of the sql
standard, but could be a nice extension for postgresql. See the patch for
more details.
Cheers
Matt
diff -U5 -r postgresql-8.4.2.orig/src/include/parser/kwlist.h postgresql-8.4.2/src/include/parser/kwlist.h
--- postgresql-8.4.2.orig/src/include/parser/kwlist.h 2009-04-06 18:12:53.0 +0930
+++ postgresql-8.4.2/src/include/parser/kwlist.h 2010-04-01 10:55:46.0 +1030
@@ -55,10 +55,11 @@
PG_KEYWORD("begin", BEGIN_P, UNRESERVED_KEYWORD)
PG_KEYWORD("between", BETWEEN, TYPE_FUNC_NAME_KEYWORD)
PG_KEYWORD("bigint", BIGINT, COL_NAME_KEYWORD)
PG_KEYWORD("binary", BINARY, TYPE_FUNC_NAME_KEYWORD)
PG_KEYWORD("bit", BIT, COL_NAME_KEYWORD)
+PG_KEYWORD("bollocks", ROLLBACK, UNRESERVED_KEYWORD)
PG_KEYWORD("boolean", BOOLEAN_P, COL_NAME_KEYWORD)
PG_KEYWORD("both", BOTH, RESERVED_KEYWORD)
PG_KEYWORD("by", BY, UNRESERVED_KEYWORD)
PG_KEYWORD("cache", CACHE, UNRESERVED_KEYWORD)
PG_KEYWORD("called", CALLED, UNRESERVED_KEYWORD)
--
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] [DOCS] Streaming replication document improvements
On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas wrote: > On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao wrote: >> On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas wrote: >>> On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao wrote: > That's an interesting point, do streaming replication connections > consume superuser_reserved_connections slots? Yes. Since SR connection is superuser connection, setting superuser_reserved_connections appropriately would be useful to prevent non-superuser connections from blocking the connection from the standby. >>> >>> I think this is wacky, especially since we'd someday like to have >>> replication be a separate privilege from superuser. I think we should >>> change this. >> >> You mean that we should change replication connection not to consume >> superuser_reserved_connections slots in 9.0? > > Yes. Preventing superuser connections from consuming superuser_reserved_connections slots seems strange for me. So I'm leaning toward just removing superuser privilege from replication connection again. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] [DOCS] Streaming replication document improvements
On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao wrote: > On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas wrote: >> On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao wrote: That's an interesting point, do streaming replication connections consume superuser_reserved_connections slots? >>> >>> Yes. Since SR connection is superuser connection, setting >>> superuser_reserved_connections appropriately would be useful >>> to prevent non-superuser connections from blocking the connection >>> from the standby. >> >> I think this is wacky, especially since we'd someday like to have >> replication be a separate privilege from superuser. I think we should >> change this. > > You mean that we should change replication connection not to consume > superuser_reserved_connections slots in 9.0? Yes. ...Robert -- 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] [DOCS] Streaming replication document improvements
On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas wrote: > On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao wrote: >>> That's an interesting point, do streaming replication connections >>> consume superuser_reserved_connections slots? >> >> Yes. Since SR connection is superuser connection, setting >> superuser_reserved_connections appropriately would be useful >> to prevent non-superuser connections from blocking the connection >> from the standby. > > I think this is wacky, especially since we'd someday like to have > replication be a separate privilege from superuser. I think we should > change this. You mean that we should change replication connection not to consume superuser_reserved_connections slots in 9.0? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] [DOCS] Streaming replication document improvements
On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao wrote: >> That's an interesting point, do streaming replication connections >> consume superuser_reserved_connections slots? > > Yes. Since SR connection is superuser connection, setting > superuser_reserved_connections appropriately would be useful > to prevent non-superuser connections from blocking the connection > from the standby. I think this is wacky, especially since we'd someday like to have replication be a separate privilege from superuser. I think we should change this. ...Robert -- 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] [DOCS] Streaming replication document improvements
On Thu, Apr 1, 2010 at 5:39 AM, Heikki Linnakangas wrote: > Fujii Masao wrote: >> *** >> *** 829,834 if (!triggered) >> --- 826,834 >> >> Set the maximum number of concurrent connections from the standby >> servers >> (see for details). >> + Since those connections are for superusers, >> + should be >> + set accordingly. >> >> >> > > That's an interesting point, do streaming replication connections > consume superuser_reserved_connections slots? Yes. Since SR connection is superuser connection, setting superuser_reserved_connections appropriately would be useful to prevent non-superuser connections from blocking the connection from the standby. > How should > superuser_reserved_connections be set? Well.. setting the number of superuser connection required for maintenance plus max_wal_senders seems to be reasonable. >> *** a/src/backend/access/transam/recovery.conf.sample >> --- b/src/backend/access/transam/recovery.conf.sample >> *** >> *** 88,94 >> #recovery_target_timeline = '33' # number or 'latest' >> # >> >> #--- >> ! # LOG-STREAMING REPLICATION PARAMETERS >> >> #--- >> # >> # When standby_mode is enabled, the PostgreSQL server will work as >> --- 88,94 >> #recovery_target_timeline = '33' # number or 'latest' >> # >> >> #--- >> ! # STANDBY SERVER PARAMETERS >> >> #--- >> # >> # When standby_mode is enabled, the PostgreSQL server will work as > > Hmm, that makes the HOT STANDBY notice after that section look weird: > >> #--- >> # HOT STANDBY PARAMETERS >> #--- >> # >> # Hot Standby related parameters are listed in postgresql.conf >> # >> #--- > > Do we need that notice? Maybe just move that sentence to the "STANDBY > SERVER PARAMETERS" section. I don't think that the notice is necessary. But I agree to the move. > I just committed a patch to move around the high-availability sections a > bit. That caused conflicts with this patch, so I picked the changes from > the patch and applied them over the new layout, and I also did a lot of > other editing. So, I committed most parts of this patch (except the > above), with a lot of changes to fix the bit-rot, and also other editing > to my liking. I hope I made it better not worse. Thanks a lot! doc/src/sgml/monitoring.sgml > +In streaming replication (see for > details), > +WAL sender process is listed in the ps display on the > primary server. > +The form of its command line display is: > + > + postgres: wal sender process user host > streaming location > + > +The user and host items remain the same for the life of the replication > connection. > +The location indicates how far WAL sender process has sent the WAL. > +On the other hand, WAL receiver process is listed in the ps > display > +on the standby server. The form of its command line display is: > + > + postgres: wal receiver process streaming location > + > +The location indicates how far WAL receiver has received the WAL. > + > + > + The original patch includes the above change for monitoring.sgml, but it's been excluded from the commit. You think that it's not worth applying the change? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
Robert Haas wrote: > After snapshotting my master using hot backup to create a workable > slave instance, I created recovery.conf on the slave and tried to get > it to connect to the master and stream WAL. > > This led to the message "sorry, too many standbys already", which did > not immediately clue me in as to what I needed to do to fix the > problem. Grepping the source code for the error message revealed that > the problem was that MaxWalSenders was zero. A few seconds further > head-scratching revealed that this was the GUC max_wal_senders, which > I duly increased from 0 to 1, after which it worked. > > I think perhaps this error message needs some adjustment. It should > be reasonably possible to guess the name of the GUC that needs > increasing based on the error message, and it currently isn't. Also > I'd vote for making the variable name max_wal_senders rather than > MaxWalSenders, but maybe that's being persnicketty. Glad the error message has been improved. I was bitten by this exact error message and didn't know the cause for a while, and was going to suggest such a fix. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] pgindent excluded files list
Andrew Dunstan wrote: > > I propose that we create a file containing the list of patterns to > exclude from pgindent runs. It would look like this: > > #list of file patterns to exclude from pg_indent runs > /s_lock\.h$ > /ecpg/test/expected/ > /snowball/libstemmer/ > /ecpg/include/(sqlda|sqltypes)\.h$ > /ecpg/include/preproc/struct\.h$ > /pl/plperl/ppport\.h$ > > > Then a pgindent run would look like this: > > find . -name '*.[ch]' -type f -print | \ > egrep -v -f src/tools/pgindent/exclude_files | \ > xargs -n100 pgindent src/tools/pgindent/typedefs.list > > > which is shorter and more efficient and less error prone than the way it's > done in the current instructions (which puts the patterns to be excluded in a > series of egrep pipes). Great, just update the pgindent README. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Parameter name standby_mode
On Wed, Mar 31, 2010 at 9:01 PM, Fujii Masao wrote: > Agreed. But what log message is repeated depends on the situation. > So message without any location might be output. BTW, In my testing, > the following message was repeated. > > LOG: invalid magic number in log file 0, segment 14, offset 9617408 Yeah, that's a pain in the neck. We need to think about a way to avoid any of these messages repeating. Not sure how, off the top of my head. >> Should we make it shut down if it can't immediately read enough WAL to >> get to a consistent state, or just figure it's the user's job to fix >> it? > > I think that it's difficult for the user to fix it. So I agree to shut > down the server in that case, i.e., throw a FATAL when an invalid WAL > record is found and recovery hasn't reached the safe starting point > even if neither primary_conninfo nor restore_command is given. I think that's reasonable. It's not like this should cause any problem for the user: they can add the missing WAL while the server is down just as well as they could if it were up, and Hot Standby isn't going to come up anyway. But I could possibly be persuaded to change my mind on this one, if someone feels strongly otherwise. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM]Re: [HACKERS] Questions about 9.0 release note
Takahiro Itagaki wrote: > > "Robert Haas" wrote: > > > > * (seq_page_cost/(random_page_cost)) > > > * EXCLUDE constraints has no tags to be linked. > > > * "EXCLUDE constraints" is not indexed from the Index page. > > > CREATE TABLE ... CONSTRAINT ... EXCLUDE rather than CREATE TABLE > > CONSTRAINT ... EXCLUDE. > > Here is a patch to fix the documentation. > > For exclusion constraints, I added a tag "SQL-CREATETABLE-exclude" > to of EXCLUDE in CREATE TABLE documentation. Also, > "Exclusion constraints" section is added to the constraints doc. > But the section is very short and just links to the CREATE TABLE doc. > We could move some contents from CREATE TABLE to the constraints doc. [ Apologies, proper patch now attached.] I applied a clarified version of your submitted patch. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com diff -cprN head/doc/src/sgml/ddl.sgml work/doc/src/sgml/ddl.sgml *** head/doc/src/sgml/ddl.sgml 2010-02-25 09:58:18.518068000 +0900 --- work/doc/src/sgml/ddl.sgml 2010-03-31 15:46:11.748532000 +0900 *** CREATE TABLE order_items ( *** 845,850 --- 845,880 . + + +Exclusion constraints + + + exclusion constraint + + + + constraint + exclusion + + + + Exclusion constraints ensure that if any two rows are compared on + the specified columns or expressions using the specified operators, + at least one of these operator comparisons will be false. The syntax is: + + CREATE TABLE circles ( + c circle, + EXCLUDE USING gist (c WITH &&) + ); + + + + + See also CREATE + TABLE ... CONSTRAINT ... EXCLUDE for details. + + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM]Re: [HACKERS] Questions about 9.0 release note
Takahiro Itagaki wrote: > > "Robert Haas" wrote: > > > > * (seq_page_cost/(random_page_cost)) > > > * EXCLUDE constraints has no tags to be linked. > > > * "EXCLUDE constraints" is not indexed from the Index page. > > > CREATE TABLE ... CONSTRAINT ... EXCLUDE rather than CREATE TABLE > > CONSTRAINT ... EXCLUDE. > > Here is a patch to fix the documentation. > > For exclusion constraints, I added a tag "SQL-CREATETABLE-exclude" > to of EXCLUDE in CREATE TABLE documentation. Also, > "Exclusion constraints" section is added to the constraints doc. > But the section is very short and just links to the CREATE TABLE doc. > We could move some contents from CREATE TABLE to the constraints doc. I applied a clarified version of your submitted patch, attached. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com Index: doc/src/sgml/backup.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.144 diff -c -c -r2.144 backup.sgml *** doc/src/sgml/backup.sgml 22 Feb 2010 17:15:10 - 2.144 --- doc/src/sgml/backup.sgml 31 Mar 2010 23:34:20 - *** *** 604,614 directory). It is advisable to test your proposed archive command to ensure that it indeed does not overwrite an existing file, and that it returns ! nonzero status in this case. We have found that cp -i does ! this correctly on some platforms but not others. If the chosen command ! does not itself handle this case correctly, you should add a command ! to test for existence of the archive file. For example, something ! like: archive_command = 'test ! -f .../%f && cp %p .../%f' --- 604,615 directory). It is advisable to test your proposed archive command to ensure that it indeed does not overwrite an existing file, and that it returns ! nonzero status in this case. On many Unix platforms, cp ! -i causes copy to prompt before overwriting a file, and ! < /dev/null causes the prompt (and overwriting) to ! fail. If your platform does not support this behavior, you should ! add a command to test for the existence of the archive file. For ! example, something like: archive_command = 'test ! -f .../%f && cp %p .../%f' -- 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] Parameter name standby_mode
On Thu, Apr 1, 2010 at 6:04 AM, Robert Haas wrote: >> I wouldn't recommend setting up a standby server like that, but it's not >> totally unreasonable. So the standby always has a potential source of >> WAL, pg_xlog. > > OK. OK, too. I turn down the patch. > Is it reasonable to think that we can find a way to make it not print > the duplicate messages over and over again? > > LOG: record with zero length at 0/3006B28 > > Maybe only print that if the location has advanced since the last such > message? Agreed. But what log message is repeated depends on the situation. So message without any location might be output. BTW, In my testing, the following message was repeated. LOG: invalid magic number in log file 0, segment 14, offset 9617408 > Should we make it shut down if it can't immediately read enough WAL to > get to a consistent state, or just figure it's the user's job to fix > it? I think that it's difficult for the user to fix it. So I agree to shut down the server in that case, i.e., throw a FATAL when an invalid WAL record is found and recovery hasn't reached the safe starting point even if neither primary_conninfo nor restore_command is given. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
On Wed, Mar 31, 2010 at 11:24 AM, Thom Brown wrote: > [patch] As a general rule, I really appreciate people being willing to take the time to put proposed changes into patch form, even if they're small, but this three-line patch contains two bugs. :-( Thanks for your many typo corrections, though! ...Robert -- 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] Questions about 9.0 release note
Alvaro Herrera wrote: > > Also, where are we on using full names rather than first names only? I > don't see the point in omitting the last names. Are we trying to > obscure to outsiders who is really working on our code? You are the third person to ask for this and I was holding up that change while Josh Berkus worked on rewording the release notes. I just pinged him and he said he will deal with the merge conflicts so I went ahead and added missing last names. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Questions about 9.0 release note
On Wed, Mar 31, 2010 at 8:23 PM, Bruce Momjian wrote: > Robert Haas wrote: >> On Wed, Mar 31, 2010 at 8:19 PM, Bruce Momjian wrote: >> >> * "EXCLUDE constraints" is not indexed from the Index page. >> >> Should we have for it? Unique Constraints have a section for them: >> >> http://developer.postgresql.org/pgdocs/postgres/ddl-constraints.html#AEN2431 >> > >> > I am unclear if exclude really belongs there because that section >> > contains mostly basic features. >> >> It seems like the charter of that page is to list all of the types of >> constraints that we have, in which case exclusion constraints belong >> there too. > > OK, but I am incapable of writing such a section. Perhaps you could use the one from the patch Itagaki-san already wrote. ...Robert -- 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] Questions about 9.0 release note
Robert Haas wrote: > On Wed, Mar 31, 2010 at 8:19 PM, Bruce Momjian wrote: > >> * "EXCLUDE constraints" is not indexed from the Index page. > >> Should we have for it? Unique Constraints have a section for them: > >> http://developer.postgresql.org/pgdocs/postgres/ddl-constraints.html#AEN2431 > > > > I am unclear if exclude really belongs there because that section > > contains mostly basic features. > > It seems like the charter of that page is to list all of the types of > constraints that we have, in which case exclusion constraints belong > there too. OK, but I am incapable of writing such a section. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Questions about 9.0 release note
On Wed, Mar 31, 2010 at 8:21 PM, Bruce Momjian wrote: > Kevin Grittner wrote: >> Robert Haas wrote: >> >> > I thought it was referring to all pairs of rows, but I see >> > now it's referring to pairs of columns, so it's correct. >> >> If it confused you, I suspect it will confuse others. Offhand, >> I can't see how to improve the language, though. > > I have no idea what text this is referring to. Itagaki-san's proposed doc patch, which you seem to have missed. ...Robert -- 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] Questions about 9.0 release note
Kevin Grittner wrote: > Robert Haas wrote: > > > I thought it was referring to all pairs of rows, but I see > > now it's referring to pairs of columns, so it's correct. > > If it confused you, I suspect it will confuse others. Offhand, > I can't see how to improve the language, though. I have no idea what text this is referring to. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Questions about 9.0 release note
On Wed, Mar 31, 2010 at 8:19 PM, Bruce Momjian wrote: >> * "EXCLUDE constraints" is not indexed from the Index page. >> Should we have for it? Unique Constraints have a section for them: >> http://developer.postgresql.org/pgdocs/postgres/ddl-constraints.html#AEN2431 > > I am unclear if exclude really belongs there because that section > contains mostly basic features. It seems like the charter of that page is to list all of the types of constraints that we have, in which case exclusion constraints belong there too. ...Robert -- 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] Questions about 9.0 release note
Takahiro Itagaki wrote: > Hi, I have some questions about 9.0 release note. > I'd like to work for some of them if required. Comments welcome. > > * Allow per-tablespace sequential and random page cost variables > (seq_page_cost/(random_page_cost)) via ALTER TABLESPACE ... SET/RESET That is a bug, fixed. > Are those parentheses around random_page_cost intentional? > They seems to mean just "(seq_page_cost and random_page_cost)". > > * EXCLUDE constraints has no tags to be linked. > The item in release note is pointing the following page, > http://developer.postgresql.org/pgdocs/postgres/sql-createtable.html#SQL-CREATETABLE-DESCRIPTION > but the actual description about EXCLUDE constraints are in the subentry > of "Parameters" section. Can we add a tag to for EXCLUDE? I was hesitant to add an 'id' link just for the 9.0 docs, but I have now added a link and linked to it. > * "EXCLUDE constraints" is not indexed from the Index page. > Should we have for it? Unique Constraints have a section for them: > http://developer.postgresql.org/pgdocs/postgres/ddl-constraints.html#AEN2431 I am unclear if exclude really belongs there because that section contains mostly basic features. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] psql: edit function, show function commands patch
I have added this to the next commit-fest. --- Pavel Stehule wrote: > Hello > > this simple patch allow to specify cursor row when some function is > opened in editor. > > \e aaa.txt > \a aaa.txt 3 ... move cursor on 3nd line of text > \ef foo > \ef foo 3 ... move cursor on 3nd line of function body > \sf foo ... show function body > \sf+ foo ... show function body - use line numbers > \sf[+] foo n ... show function body from line n > > postgres=# \sf foo > > CREATE OR REPLACE FUNCTION public.foo() > RETURNS integer > LANGUAGE plpgsql > AS $function$ > begin > return 10/0; > end; > $function$ > > postgres=# \sf+ foo > > CREATE OR REPLACE FUNCTION public.foo() > RETURNS integer > LANGUAGE plpgsql >1 AS $function$ >2 begin >3return 10/0; >4 end; > $function$ > > Regards > Pavel Stehule [ Attachment, skipping... ] > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Parameter name standby_mode
On Wed, Mar 31, 2010 at 5:23 PM, Heikki Linnakangas wrote: > Robert Haas wrote: >> Is it reasonable to think that we can find a way to make it not print >> the duplicate messages over and over again? >> >> LOG: record with zero length at 0/3006B28 >> >> Maybe only print that if the location has advanced since the last such >> message? > > Yeah, seems reasonable. > >> Should we make it shut down if it can't immediately read enough WAL to >> get to a consistent state, or just figure it's the user's job to fix >> it? > > I'd say no. In testing, I have done this many times: > > pg_start_backup() > copy data directory to server > create recovery.conf > Start standby server. > pg_stop_backup() > > The standby doesn't reach consistency before it sees the end-of-backup > record written by pg_stop_backup(), but it does replay up to the last > WAL segment, and connect to the master. > > Not sure if that's useful in real life, but there could be situations > where restore_command isn't totally reliable, for example, and it's good > to keep trying. I was only thinking of doing it in the case where there's no primary_conninfo or restore_command. ...Robert -- 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] Parameter name standby_mode
Robert Haas wrote: > Is it reasonable to think that we can find a way to make it not print > the duplicate messages over and over again? > > LOG: record with zero length at 0/3006B28 > > Maybe only print that if the location has advanced since the last such > message? Yeah, seems reasonable. > Should we make it shut down if it can't immediately read enough WAL to > get to a consistent state, or just figure it's the user's job to fix > it? I'd say no. In testing, I have done this many times: pg_start_backup() copy data directory to server create recovery.conf Start standby server. pg_stop_backup() The standby doesn't reach consistency before it sees the end-of-backup record written by pg_stop_backup(), but it does replay up to the last WAL segment, and connect to the master. Not sure if that's useful in real life, but there could be situations where restore_command isn't totally reliable, for example, and it's good to keep trying. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] Parameter name standby_mode
On Wed, Mar 31, 2010 at 4:54 PM, Heikki Linnakangas wrote: > Robert Haas wrote: >> Agreed. I think if the server starts up in standby mode and it is an >> inconsistent state with no source of WAL, then the startup process >> should exit with a suitable error message, which AIUI will result in >> the whole server shutting down. However if there is no source of WAL >> but the server is in a consistent state, then I think we should allow >> it to start up as a read-only standby. >> >> Now, an interesting question is - if the server is in this state, and >> somebody manually drops more WAL into pg_xlog, what happens? And what >> happens in the similar case where primary_conninfo is set but we can't >> connect to the master at the moment, and someone drops a pile of WAL >> on us? > > With the recent changes to the retry logic > (http://archives.postgresql.org/pgsql-committers/2010-03/msg00356.php), > they will be replayed. Even if neither primary_conninfo or > restore_command is given, the server will still keep polling pg_xlog, > and if you copy a WAL file to standby's pg_xlog directory, it will be > replayed and recovery will make progress. > > I wouldn't recommend setting up a standby server like that, but it's not > totally unreasonable. So the standby always has a potential source of > WAL, pg_xlog. OK. Is it reasonable to think that we can find a way to make it not print the duplicate messages over and over again? LOG: record with zero length at 0/3006B28 Maybe only print that if the location has advanced since the last such message? Should we make it shut down if it can't immediately read enough WAL to get to a consistent state, or just figure it's the user's job to fix it? ...Robert -- 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] Parameter name standby_mode
Robert Haas wrote: > Agreed. I think if the server starts up in standby mode and it is an > inconsistent state with no source of WAL, then the startup process > should exit with a suitable error message, which AIUI will result in > the whole server shutting down. However if there is no source of WAL > but the server is in a consistent state, then I think we should allow > it to start up as a read-only standby. > > Now, an interesting question is - if the server is in this state, and > somebody manually drops more WAL into pg_xlog, what happens? And what > happens in the similar case where primary_conninfo is set but we can't > connect to the master at the moment, and someone drops a pile of WAL > on us? With the recent changes to the retry logic (http://archives.postgresql.org/pgsql-committers/2010-03/msg00356.php), they will be replayed. Even if neither primary_conninfo or restore_command is given, the server will still keep polling pg_xlog, and if you copy a WAL file to standby's pg_xlog directory, it will be replayed and recovery will make progress. I wouldn't recommend setting up a standby server like that, but it's not totally unreasonable. So the standby always has a potential source of WAL, pg_xlog. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] Alpha release this week?
On Wed, Mar 31, 2010 at 4:39 PM, Josh Berkus wrote: >> I can snap a tarball tonight if you want. I'm going to be leaving >> town tomorrow afternoon, though. > > Please do. If someone could email me off list where they would like the tarball put, with login credentials, I will put it there. Otherwise I will be creative. ...Robert -- 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] [DOCS] Streaming replication document improvements
Fujii Masao wrote: > *** > *** 829,834 if (!triggered) > --- 826,834 > > Set the maximum number of concurrent connections from the standby > servers > (see for details). > +Since those connections are for superusers, > + should be > +set accordingly. > > > That's an interesting point, do streaming replication connections consume superuser_reserved_connections slots? How should superuser_reserved_connections be set? > *** a/src/backend/access/transam/recovery.conf.sample > --- b/src/backend/access/transam/recovery.conf.sample > *** > *** 88,94 > #recovery_target_timeline = '33'# number or 'latest' > # > #--- > ! # LOG-STREAMING REPLICATION PARAMETERS > #--- > # > # When standby_mode is enabled, the PostgreSQL server will work as > --- 88,94 > #recovery_target_timeline = '33'# number or 'latest' > # > #--- > ! # STANDBY SERVER PARAMETERS > #--- > # > # When standby_mode is enabled, the PostgreSQL server will work as Hmm, that makes the HOT STANDBY notice after that section look weird: > #--- > # HOT STANDBY PARAMETERS > #--- > # > # Hot Standby related parameters are listed in postgresql.conf > # > #--- Do we need that notice? Maybe just move that sentence to the "STANDBY SERVER PARAMETERS" section. I just committed a patch to move around the high-availability sections a bit. That caused conflicts with this patch, so I picked the changes from the patch and applied them over the new layout, and I also did a lot of other editing. So, I committed most parts of this patch (except the above), with a lot of changes to fix the bit-rot, and also other editing to my liking. I hope I made it better not worse. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.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] Alpha release this week?
Robert, > I can snap a tarball tonight if you want. I'm going to be leaving > town tomorrow afternoon, though. Please do. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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] Patch for 9.1: initdb -C option
I have added this to the 9.1 commit-fest: https://commitfest.postgresql.org/action/commitfest_view?id=6 --- David Christensen wrote: > Hackers, > > Enclosed is a patch to add a -C option to initdb to allow you to easily > append configuration directives to the generated postgresql.conf file for use > in programmatic generation. In my case, I'd been creating multiple db > clusters with a script and would have specific overrides that I needed to > make. This patch fell out of the desire to make this a little cleaner. > Please review and comment. > > From the commit message: > > This is a simple mechanism to allow you to provide explicit overrides > to any GUC at initdb time. As a basic example, consider the case > where you are programmatically generating multiple db clusters in > order to test various configurations: > > $ for cluster in 1 2 3 4 5 6; > > do initdb -D data$cluster -C "port = 1234$cluster" -C > 'max_connections = 10' -C shared_buffers=1M; > > done > > A possible future improvement would be to provide some basic > formatting corrections to allow specificications such as -C 'port > 1234', -C port=1234, and -C 'port = 1234' to all be ultimately output > as 'port = 1234' in the final output. This would be consistent with > postmaster's parsing. > > The -C flag was chosen to be a mnemonic for "config". > > Regards, > > David > -- > David Christensen > End Point Corporation > da...@endpoint.com > > > [ Attachment, skipping... ] [ Attachment, skipping... ] > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Alpha release this week?
On Wed, Mar 31, 2010 at 7:52 PM, Robert Haas wrote: > I can snap a tarball tonight if you want. I'm going to be leaving > town tomorrow afternoon, though. Works for me. I'll stuff it into our shiny new 9.0 build machine tomorrow. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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] Alpha release this week?
On Wed, 2010-03-31 at 10:46 -0700, Josh Berkus wrote: > > Not with any amount of testing as we'd normally give any build > before > > releasing it anyway. I can certainly stuff a tarball into the new > > build machine and see what comes out the next morning. > > That would be good enough for Saturday; we're going to test it after > all. Let me know which snapshot day you grab, so we can have the same > snapshot-day for Windows and other platforms. FWIW, I can release RPMs based on the same snapshot in an hour after I get the tarball. -- Devrim GÜNDÜZ PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
[HACKERS] CHAR(10) - Clustering, High Availability and Replication conference
http://www.char10.org/ announced today... PostgreSQL CHAR(10) Conference is in Oxford, UK on 1-3 July 2010, at Oriel College, Oxford University. CHAR(10) stands for Clustering, High Availability, Replication, though includes all forms of Parallel, Distributed and Grid architectures. The Call for Papers is now open. Proposals should be sent to cha...@2ndquadrant.com. Submission deadline is 20 April 2010. Paper selection will be announced in early May. PostgreSQL CHAR(10) is an international conference that aims to stimulate discussion and development of technologies in the areas of: * Clustering technologies * High Availability solutions * Replication techniques * Distributed Cacheing and Querying * Parallel & Massively Parallel processing * Grid Architectures * Remote & Distributed processing * Load balancing * Recovery and Resilience Speakers will be selected by an invited technical panel consisting of representatives from development, academic and users. Speakers will receive free conference attendance and free accommodation. -- Simon Riggs www.2ndQuadrant.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] Alpha release this week?
On Wed, Mar 31, 2010 at 2:33 PM, Dave Page wrote: > On Wed, Mar 31, 2010 at 6:46 PM, Josh Berkus wrote: >> Dave, >> >>> Not with any amount of testing as we'd normally give any build before >>> releasing it anyway. I can certainly stuff a tarball into the new >>> build machine and see what comes out the next morning. >> >> That would be good enough for Saturday; we're going to test it after >> all. Let me know which snapshot day you grab, so we can have the same >> snapshot-day for Windows and other platforms. > > Oh, you're wanting to use an automated snapshot? There used to be some > differences in those tarballs (when compared to real releases) that > will probably cause the build system to fall over. If you can get a > proper alpha 5 tarball created, that would be preferrable. I can snap a tarball tonight if you want. I'm going to be leaving town tomorrow afternoon, though. ...Robert -- 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] Alpha release this week?
On Wed, Mar 31, 2010 at 6:46 PM, Josh Berkus wrote: > Dave, > >> Not with any amount of testing as we'd normally give any build before >> releasing it anyway. I can certainly stuff a tarball into the new >> build machine and see what comes out the next morning. > > That would be good enough for Saturday; we're going to test it after > all. Let me know which snapshot day you grab, so we can have the same > snapshot-day for Windows and other platforms. Oh, you're wanting to use an automated snapshot? There used to be some differences in those tarballs (when compared to real releases) that will probably cause the build system to fall over. If you can get a proper alpha 5 tarball created, that would be preferrable. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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] Questions about 9.0 release note
* Kevin Grittner [100331 13:18]: > If it confused you, I suspect it will confuse others. Offhand, > I can't see how to improve the language, though. How about a simple: s/these/the colomn or expression/ Leaving: ... not all of the column or expression comparisons ... "These" isn't wrong, but if people are being confused about the objects "these" refer to, being explicit can at least avoid that confusion. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] TODO list updates
2010/3/27 Tom Lane : > Robert Haas writes: >> In reading through the TODO list, I noticed a few things that I think >> are done, may be done, or may be partially done. See below. >> Thoughts? ...Robert > >> Implement full support for window framing clauses. >> - Not sure if we made any progress on this or not. > > We made some progress for 9.0, but there's still a lot of unimplemented > territory. TODO updated. -- Hitoshi Harada -- 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] Alpha release this week?
Dave, > Not with any amount of testing as we'd normally give any build before > releasing it anyway. I can certainly stuff a tarball into the new > build machine and see what comes out the next morning. That would be good enough for Saturday; we're going to test it after all. Let me know which snapshot day you grab, so we can have the same snapshot-day for Windows and other platforms. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.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] Questions about 9.0 release note
Robert Haas wrote: > I thought it was referring to all pairs of rows, but I see > now it's referring to pairs of columns, so it's correct. If it confused you, I suspect it will confuse others. Offhand, I can't see how to improve the language, though. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM]Re: [HACKERS] Questions about 9.0 release note
On Wed, Mar 31, 2010 at 1:07 PM, Kevin Grittner wrote: > Robert Haas wrote: > >> This says: >> >> Exclusion constraints ensure that that if any two rows are >> compared on the specified column(s) or expression(s) using the >> specified operator(s), not all of these comparisons will return >> TRUE. >> >> I think that's backwards - the last clause should say "none of >> those comparisons will return TRUE". >> >> Unless I'm confused. > > "not all" seems correct. For example, you could be checking the > room number for equality and a range of time for overlap -- both > must be TRUE to have a problem; otherwise you could only schedule > one thing in the room for all time and one thing at a given time > across all rooms. Oh, I see. I thought it was referring to all pairs of rows, but I see now it's referring to pairs of columns, so it's correct. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM]Re: [HACKERS] Questions about 9.0 release note
Robert Haas wrote: > This says: > > Exclusion constraints ensure that that if any two rows are > compared on the specified column(s) or expression(s) using the > specified operator(s), not all of these comparisons will return > TRUE. > > I think that's backwards - the last clause should say "none of > those comparisons will return TRUE". > > Unless I'm confused. "not all" seems correct. For example, you could be checking the room number for equality and a range of time for overlap -- both must be TRUE to have a problem; otherwise you could only schedule one thing in the room for all time and one thing at a given time across all rooms. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM]Re: [HACKERS] Questions about 9.0 release note
On Wed, Mar 31, 2010 at 2:56 AM, Takahiro Itagaki wrote: > > "Robert Haas" wrote: > >> > * (seq_page_cost/(random_page_cost)) >> > * EXCLUDE constraints has no tags to be linked. >> > * "EXCLUDE constraints" is not indexed from the Index page. > >> CREATE TABLE ... CONSTRAINT ... EXCLUDE rather than CREATE TABLE >> CONSTRAINT ... EXCLUDE. > > Here is a patch to fix the documentation. > > For exclusion constraints, I added a tag "SQL-CREATETABLE-exclude" > to of EXCLUDE in CREATE TABLE documentation. Also, > "Exclusion constraints" section is added to the constraints doc. > But the section is very short and just links to the CREATE TABLE doc. > We could move some contents from CREATE TABLE to the constraints doc. This says: Exclusion constraints ensure that that if any two rows are compared on the specified column(s) or expression(s) using the specified operator(s), not all of these comparisons will return TRUE. I think that's backwards - the last clause should say "none of those comparisons will return TRUE". Unless I'm confused. ...Robert -- 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] Performance Enhancement/Fix for Array Utility Functions
On Wed, Mar 31, 2010 at 8:28 AM, Robert Haas wrote: > > Neat. Please add it here: > > https://commitfest.postgresql.org/action/commitfest_view/open > > ...Robert > Thanks. Added it. https://commitfest.postgresql.org/action/patch_view?id=292 -Mike -- 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: Add JSON support
robertmh...@gmail.com (Robert Haas) writes: > On Tue, Mar 30, 2010 at 8:58 PM, Josh Berkus wrote: >>> I'd think that you could get quite a long ways on this, at least doing >>> something like dbslayer without *necessarily* needing to do terribly >>> much work inside the DB engine. >> >> There's actually an HTTP framework tool for Postgres which already does >> something of the sort. It was introduced at pgCon 2 years ago ... will >> look for. > > While it might be interesting to have/find/write a tool that puts an > HTTP/JSON layer around the DB connection, it's pretty much entirely > unrelated to the proposed project of creating a json type with > PostgreSQL analagous to the xml type we already have, which is what > the OP is proposing to do. > > Personally, I suspect that a JSON type is both a more interesting > project to work on and a more useful result for this community. No disagreement here; I'd expect that a JSON type would significantly ease building such a framework. Indeed, that could be a demonstration of success... "We then implemented an HTTP/JSON proxy in 27 lines of Python code..." :-) -- "Unless you used NetInfo. _Then_ changing network settings could often require torching of the existing system, salting of the ground it had rested on, and termination of anyone who used it." -- JFW on comp.sys.next.advocacy -- 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] TODO list updates
Robert Haas wrote: > In reading through the TODO list, I noticed a few things that I think > are done, may be done, or may be partially done. See below. > Thoughts? ...Robert > > Add missing operators for geometric data types > - this is at least partly done. not sure if it is entirely done. > > Add OR REPLACE to CREATE LANGUAGE > - Done. TODO updated. > Add PQescapeIdentifierConn() > - Done, as PQescapeIdentifier(). TODO updated. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] TODO list updates
Tom Lane wrote: > Robert Haas writes: > > In reading through the TODO list, I noticed a few things that I think > > are done, may be done, or may be partially done. See below. > > Thoughts? ...Robert > > > Add missing operators for geometric data types > > - this is at least partly done. not sure if it is entirely done. > > I think you are thinking of Teodor's point_ops patch, but what that > did was add GIST index support for some existing geometric operators. > This TODO item suffers from the all-too-common sin of being uselessly > vague; it doesn't identify what operators it thinks are missing. The full TODO item text is: Add missing operators for geometric data types Some geometric types do not have the full suite of geometric operators, e.g. box @> point * point_ops for GiST but we now have the @> operator mentioned: pg_catalog | @> | box | point | boolean | contains? so I have removed this TODO item. > > Add UNIQUE capability to non-btree indexes > > - This is one application of exclusion constraints, so I'd say this is done. > > I think exclusion constraints address this as much as it needs to be > addressed for GIST and GIN, neither of which have "equality" as a core > concept. Hash, however, does have that. So I'd vote for narrowing the > entry to "support UNIQUE natively in hash indexes" and moving it to the > hash-index section. Agreed, moved. > > Clean up VACUUM FULL's klugy transaction management > > - I think this is moot with the new cluster-based VF. > > Right, that one's either done or no longer relevant depending on how you > want to look at it. Agreed, removed. > There is another TODO item that I was just struck by while reading your > response to Joseph Adams: > > Fix system views like pg_stat_all_tables to use set-returning > functions, rather than views of per-column functions > > What is the point of this proposal? The reason for the per-column function > implementation was to allow people to slice and dice the underlying data > their own way. Changing to monolithic SRFs would make that harder, and > I don't see that it's buying anything especially useful. I'd vote for > taking this off unless someone can explain why it's an improvement. Agreed, removed. I wasn't aware why we implemented this as slices. I now assume it was for performance reasons. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.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] Performance Enhancement/Fix for Array Utility Functions
On Wed, Mar 31, 2010 at 5:08 AM, Mike Lewis wrote: > Woops. I sent the wrong patch. My apologies. Attached is the real > patch. Sorry, also forgot this is made against 9.0 alpha 4 tag. Neat. Please add it here: https://commitfest.postgresql.org/action/commitfest_view/open ...Robert -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
On 31 March 2010 15:45, Robert Haas wrote: > On Wed, Mar 31, 2010 at 10:44 AM, Tom Lane wrote: > > Robert Haas writes: > >> On Wed, Mar 31, 2010 at 12:54 AM, Fujii Masao > wrote: > >>>could not accept connection from the standby because max_wal_senders > is 0 > > > >> Well, that might still leave someone confused if they had one standby > >> and were trying to bring up a second one. > > > > I'd suggest something like "number of requested standby connections > > exceeds max_wal_senders (currently %d)" > > Oh, that's much better than anything I thought of. +1. > > ...Robert > > That provides more explicit information. :) sr_error_message_v2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pending patch: Re: [HACKERS] HS/SR and smart shutdown
On Wed, Mar 31, 2010 at 5:02 AM, Simon Riggs wrote: >> > >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect. >> > "backends might be waiting for the WAL record that conflicts with their >> > queries to be replayed". Recovery sometimes waits for backends, but >> > backends never wait for recovery. >> >> Really? As Heikki explained before, backends might wait for the lock >> taken by the startup process. >> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02984.php > > Backends wait for locks, yes, but they could be waiting for user locks > also. That is not "waiting for the WAL record", that concept does not > exist. Hmm... this is a good point, on two levels. First, the comment is not as well-phrased as it could be. Second, I wonder why we can't kill the startup process and WAL receiver right away, and then wait for the backends to die off afterwards. ...Robert -- 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] pgindent excluded files list
On Wed, Mar 31, 2010 at 10:27:03AM -0400, Andrew Dunstan wrote: > > I propose that we create a file containing the list of patterns to > exclude from pgindent runs. It would look like this: > >#list of file patterns to exclude from pg_indent runs >/s_lock\.h$ >/ecpg/test/expected/ >/snowball/libstemmer/ >/ecpg/include/(sqlda|sqltypes)\.h$ >/ecpg/include/preproc/struct\.h$ >/pl/plperl/ppport\.h$ > > > Then a pgindent run would look like this: > >find . -name '*.[ch]' -type f -print | \ >egrep -v -f src/tools/pgindent/exclude_files | \ >xargs -n100 pgindent src/tools/pgindent/typedefs.list > > which is shorter and more efficient and less error prone than the > way it's done in the current instructions (which puts the patterns > to be excluded in a series of egrep pipes). > > Thoughts? +1 for simplifying and consolidating. Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] mremap and bus error
Hi,
I playing with mmap. I have a problem with mremap function. It
doesn't allocate correct memory. All others work well.
static void *
mmap_realloc(void *ptr, Size size)
{
Size oldsize;
void *result;
int i;
char *x;
ptr = (char *) ptr - MAXALIGN(sizeof(Size));
oldsize = *((Size *) ptr);
size = MAXALIGN(size) + MAXALIGN(sizeof(Size));
ptr = mremap(ptr, oldsize,
size,
MREMAP_MAYMOVE);
if (ptr == MAP_FAILED)
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg("out of memory"),
errdetail("Failed on request of size %lu.",
(unsigned long) size)));
*((Size*) ptr) = size;
result = (char *) ptr + MAXALIGN(sizeof(Size));
/* check allocated memory */
x = ptr;
fprintf(stderr, "allocated memory %ld\n", size);
for (i = 0; i < size; i++)
{
if (i > oldsize)
{
*x = 0;
}
x++;
}
fprintf(stderr, "memory checked\n");
return result;
}
log:
1 <<<>>> 1048584
3 <<<>>> 2097216
3 <<<>>> 9024
allocated memory 10304
memory checked
allocated memory 11584
memory checked
allocated memory 12864
gdb
Program terminated with signal 7, Bus error.
#0 mmap_realloc (size=12864, ptr=) at mmap_alloc.c:357
357 *x = 0;
Missing separate debuginfos, use: debuginfo-install glibc-2.10.2-1.x86_64
(gdb) print x
$1 = 0x7f92055df000 ""
(gdb) print i
$2 = 12289
Can somebody help me?
Regards
Pavel Stehule
--
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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
On Wed, Mar 31, 2010 at 10:44 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Mar 31, 2010 at 12:54 AM, Fujii Masao wrote: >>> could not accept connection from the standby because max_wal_senders is 0 > >> Well, that might still leave someone confused if they had one standby >> and were trying to bring up a second one. > > I'd suggest something like "number of requested standby connections > exceeds max_wal_senders (currently %d)" Oh, that's much better than anything I thought of. +1. ...Robert -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
Robert Haas writes: > On Wed, Mar 31, 2010 at 12:54 AM, Fujii Masao wrote: >> could not accept connection from the standby because max_wal_senders is 0 > Well, that might still leave someone confused if they had one standby > and were trying to bring up a second one. I'd suggest something like "number of requested standby connections exceeds max_wal_senders (currently %d)" regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pgindent excluded files list
I propose that we create a file containing the list of patterns to exclude from pgindent runs. It would look like this: #list of file patterns to exclude from pg_indent runs /s_lock\.h$ /ecpg/test/expected/ /snowball/libstemmer/ /ecpg/include/(sqlda|sqltypes)\.h$ /ecpg/include/preproc/struct\.h$ /pl/plperl/ppport\.h$ Then a pgindent run would look like this: find . -name '*.[ch]' -type f -print | \ egrep -v -f src/tools/pgindent/exclude_files | \ xargs -n100 pgindent src/tools/pgindent/typedefs.list which is shorter and more efficient and less error prone than the way it's done in the current instructions (which puts the patterns to be excluded in a series of egrep pipes). Thoughts? cheers andrew -- 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] booleans in recovery.conf
Simon Riggs wrote: > On Tue, 2010-03-23 at 19:43 -0400, Bruce Momjian wrote: > > Is there a reason that recovery.conf uses true/false, while > > postgresql.conf uses on/off? > > > > #recovery_target_inclusive = 'true' # 'true' or 'false' > > > > or are these settings more boolean for some reason? > > The code accepts any of on|off|true|false and uses the same code as the > postgresql.conf for parsing that. > > I've changed the standby_mode to on|off as per the docs. I left the > above parameter because true|false reads better. Agreed. I also applied the attached change so defaults are listed and example values only appear as comments in the file. This makes the file match postgresql.conf in style. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com Index: src/backend/access/transam/recovery.conf.sample === RCS file: /cvsroot/pgsql/src/backend/access/transam/recovery.conf.sample,v retrieving revision 1.7 diff -c -c -r1.7 recovery.conf.sample *** src/backend/access/transam/recovery.conf.sample 29 Mar 2010 18:50:36 - 1.7 --- src/backend/access/transam/recovery.conf.sample 31 Mar 2010 14:16:12 - *** *** 20,27 # Comments are introduced with '#'. # # The complete list of option names and allowed values can be found ! # in the PostgreSQL documentation. The commented-out settings shown below ! # are example values. # #--- # ARCHIVE RECOVERY PARAMETERS --- 20,26 # Comments are introduced with '#'. # # The complete list of option names and allowed values can be found ! # in the PostgreSQL documentation. # #--- # ARCHIVE RECOVERY PARAMETERS *** *** 44,50 # NOTE that the basename of %p will be different from %f; do not # expect them to be interchangeable. # ! #restore_command = 'cp /mnt/server/archivedir/%f %p' # # # restartpoint_command --- 43,49 # NOTE that the basename of %p will be different from %f; do not # expect them to be interchangeable. # ! #restore_command = '' # e.g. 'cp /mnt/server/archivedir/%f %p' # # # restartpoint_command *** *** 74,91 # transaction(s) with the recovery target value (ie, stop either # just after or just before the given target, respectively). # ! #recovery_target_time = '2004-07-14 22:39:00 EST' # ! #recovery_target_xid = '1100842' # ! #recovery_target_inclusive = 'true' # 'true' or 'false' # # # If you want to recover into a timeline other than the "main line" shown in # pg_control, specify the timeline number here, or write 'latest' to get # the latest branch for which there's a history file. # ! #recovery_target_timeline = '33' # number or 'latest' # #--- # LOG-STREAMING REPLICATION PARAMETERS --- 73,90 # transaction(s) with the recovery target value (ie, stop either # just after or just before the given target, respectively). # ! #recovery_target_time = '' # e.g. '2004-07-14 22:39:00 EST' # ! #recovery_target_xid = '' # ! #recovery_target_inclusive = 'true' # # # If you want to recover into a timeline other than the "main line" shown in # pg_control, specify the timeline number here, or write 'latest' to get # the latest branch for which there's a history file. # ! #recovery_target_timeline = 'latest' # #--- # LOG-STREAMING REPLICATION PARAMETERS *** *** 96,104 # connection settings primary_conninfo, and receives XLOG records # continuously. # ! #standby_mode = 'off' # 'on' or 'off' # ! #primary_conninfo = 'host=localhost port=5432' # # # By default, a standby server keeps streaming XLOG records from the --- 95,103 # connection settings primary_conninfo, and receives XLOG records # continuously. # ! #standby_mode = 'off' # ! #primary_conninfo = '' # e.g. 'host=localhost port=5432' # # # By default, a standby server keeps streaming XLOG records from the -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
On Wed, Mar 31, 2010 at 12:54 AM, Fujii Masao wrote: > On Wed, Mar 31, 2010 at 12:06 PM, Robert Haas wrote: >> After snapshotting my master using hot backup to create a workable >> slave instance, I created recovery.conf on the slave and tried to get >> it to connect to the master and stream WAL. >> >> This led to the message "sorry, too many standbys already", which did >> not immediately clue me in as to what I needed to do to fix the >> problem. Grepping the source code for the error message revealed that >> the problem was that MaxWalSenders was zero. A few seconds further >> head-scratching revealed that this was the GUC max_wal_senders, which >> I duly increased from 0 to 1, after which it worked. >> >> I think perhaps this error message needs some adjustment. It should >> be reasonably possible to guess the name of the GUC that needs >> increasing based on the error message, and it currently isn't. > > Agreed. How about the atteched patch? > The patch treats differently the case where max_wal_senders is 0, > and the following error message (better message?) is written only > in this case. > > could not accept connection from the standby because max_wal_senders is 0 Well, that might still leave someone confused if they had one standby and were trying to bring up a second one. ...Robert -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
Robert Haas escribió: > On Wed, Mar 31, 2010 at 8:19 AM, Magnus Hagander wrote: > > How about using errhint to tell the user which parameter to use? > > I thought about that. I noticed that the error message from the > master gets displayed on the slave. I didn't check if an errhint > would also propagate over. Hmm, it would be very good that it did. Perhaps that needs fixing, if it doesn't work already. (Personally, I consider that this idea that hints, details and other message fields are second-level citizens in the error report country has got to stop. It means we can only use hints and details for near useless information.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 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] Parameter name standby_mode
On Wed, Mar 31, 2010 at 1:47 AM, Fujii Masao wrote: > On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas wrote: >> I just tested this and it seems to just sit there doing this over and >> over again: >> >> LOG: record with zero length at 0/3006B28 >> >> I'm not sure that we should forbid this configuration, but the current >> behavior doesn't seem right either. ISTM that, in the absence of a >> way to get any more WAL, it would be reasonable for the standby server >> to just start up and sit there in recovery mode but without actually >> advancing recovery, but the repeated log messages are pretty annoying. > > I'm concerned about that the configuration might prevent the standby > from accepting connection from a client because it cannot get the WAL > for making the database consistent. So that configuration seems to be > reasonable only when starting the standby from the already-consistent > database or with enough WAL files in pg_xlog. But it seems to me that > the standby often starts from the inconsistent database without enough > WAL in pg_xlog. Agreed. I think if the server starts up in standby mode and it is an inconsistent state with no source of WAL, then the startup process should exit with a suitable error message, which AIUI will result in the whole server shutting down. However if there is no source of WAL but the server is in a consistent state, then I think we should allow it to start up as a read-only standby. Now, an interesting question is - if the server is in this state, and somebody manually drops more WAL into pg_xlog, what happens? And what happens in the similar case where primary_conninfo is set but we can't connect to the master at the moment, and someone drops a pile of WAL on us? >> A related question is... do we ever reload recovery.conf? I tried >> adding the setting to recovery.conf and doing pg_ctl reload, and it >> says that it's "reloading configuration files", but doesn't pick up >> the new setting. :-( > > recovery.conf cannot be reloaded while the server is running. This > restriction should be removed in the future release, I think. Yes. If we don't already have a TODO for that, we should definitely add one. I found myself annoyed by this several times last night. I kept having to restart the master, too, first to fix archive_mode and then to fix max_wal_senders. It's far too late to start tinkering with this stuff now but I am pretty confident there will be a huge sigh of collective relief out there if we can relax some of these restrictions for 9.1. Nobody likes having to shut down the server, even if it's just for a few seconds. ...Robert -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
On Wed, Mar 31, 2010 at 8:19 AM, Magnus Hagander wrote: > How about using errhint to tell the user which parameter to use? I thought about that. I noticed that the error message from the master gets displayed on the slave. I didn't check if an errhint would also propagate over. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pending patch: Re: [HACKERS] HS/SR and smart shutdown
On Wed, Mar 31, 2010 at 4:00 AM, Simon Riggs wrote: > Please add some docs that a) explains what the patch does and b) notes > any changes from behaviour in previous releases. ISTM this is a major > change in behaviour. I guess I see this a little bit differently. If you do a smart shutdown on 8.4, the autovacuum launcher won't prevent s smart shutdown from completing successfully. Neither will the background writer. If they did, we'd consider that a bug and fix it. walreceiver is just one more system process that needs to get properly shut down when a smart shutdown is requested. So I don't think this is a major behavior change - I think it's preserving the behavior we've had all along. The current documentation reads: In stop mode, the server that is running in the specified data directory is shut down. Three different shutdown methods can be selected with the -m option: "Smart" mode waits for online backup mode to finish and all the clients to disconnect. This is the default. "Fast" mode does not wait for clients to disconnect and will terminate an online backup in progress. All active transactions are rolled back and clients are forcibly disconnected, then the server is shut down. "Immediate" mode will abort all server processes without a clean shutdown. This will lead to a recovery run on restart. That all still seems accurate after this patch. I'm not even sure what to add. I suppose we could add a sentence like If a smart shutdown is requested while the server is in recovery, recovery will stop and the server will shut down. ...but if we add that then why don't we have a similar sentence that says: If a smart shutdown is requested while the autovacuum launcher is running, the autovacuum launcher will be stopped and the server will shut down. I just don't see that we're adding any additional clarity here. I think what would require documentation is if we DIDN'T apply this patch. Then we'd need something like: Smart shutdown mode should not be used if streaming replication is in use. The server will begin to shut down but, because the streaming replication process is not automatically shut down, it will never actually finish shutting down unless the streaming replication process crashes. If a server using streaming replication is accidentally shut down using smart mode, the problem can be corrected by shutting down again using fast or immediate mode. ...Robert -- 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] sorry, too many standbys already vs. MaxWalSenders vs. max_wal_senders
2010/3/31 Fujii Masao : > On Wed, Mar 31, 2010 at 12:06 PM, Robert Haas wrote: >> After snapshotting my master using hot backup to create a workable >> slave instance, I created recovery.conf on the slave and tried to get >> it to connect to the master and stream WAL. >> >> This led to the message "sorry, too many standbys already", which did >> not immediately clue me in as to what I needed to do to fix the >> problem. Grepping the source code for the error message revealed that >> the problem was that MaxWalSenders was zero. A few seconds further >> head-scratching revealed that this was the GUC max_wal_senders, which >> I duly increased from 0 to 1, after which it worked. >> >> I think perhaps this error message needs some adjustment. It should >> be reasonably possible to guess the name of the GUC that needs >> increasing based on the error message, and it currently isn't. > > Agreed. How about the atteched patch? > The patch treats differently the case where max_wal_senders is 0, > and the following error message (better message?) is written only > in this case. > > could not accept connection from the standby because max_wal_senders is 0 How about using errhint to tell the user which parameter to use? -- 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] Problems with variable cursorname in ecpg
Michael Meskes írta:
> On Wed, Mar 31, 2010 at 10:35:31AM +0200, Boszormenyi Zoltan wrote:
>
>>> I think we should make the error message/documentation a little bit
>>> clearer as
>>> people have stumbled over it.
>>>
>> Yes, we need to document it.
>>
>
> I changed the error message and documented a possible improvement in the TODO
> list.
>
>
>> I think you forget that in this case, only global variables are
>> usable in the DECLARE in this case, no local variables in
>> functions preceding the DECLARE are visible to it.
>>
>
> I thought about not allowing variables in declare statements that are outside
> a
> function. Do you think it makes sense to allow those? Forbidding these right
> now would give us more headroomfor future development.
>
I think forbidding global variables in DECLARE is not good.
Consider this code (existing code using this practice is in use):
/* globals for our cursor */
EXEC SQL BEGIN DECLARE SECTION;
char *global_curname;
EXEC SQL END DECLARE SECTION;
void open_cursor(char *curname)
{
global_curname = curname;
EXEC SQL DECLARE :global_curname CURSOR FOR ...;
EXEC SQL OPEN :global_curname;
}
... and similar codes for FETCH (into SQLDA) and CLOSE.
It works nicely for single-threaded code.
The dump_variables() code cannot distinguish between the
dynamic cursorname variable (used for $0) and the other
input variables. Considering the usefulness of the current
state, we shouldn't disallow global variables for DECLARE.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
--
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] Problems with variable cursorname in ecpg
Boszormenyi Zoltan írta:
> Boszormenyi Zoltan írta:
>
>> I think you forget that in this case, only global variables are
>> usable in the DECLARE in this case, no local variables in
>> functions preceding the DECLARE are visible to it.
>>
>> What we need here is an extra check in ECPGdump_a_type().
>> We need to raise an error if
>> ECPGdump_a_type(name, type, ...)
>> and
>> var = with find_variable(name);
>> on the passed name disagrees in the variable type and maybe
>> a warning if they disagree in the brace_level. The same applies
>> to the indicator variable. For that, we need to pass the brace_level
>> to ECPGdump_a_type() for both the variable and the indicator.
>>
>>
>
> I was thinking about something like the attached patch.
> It passes all the regression tests.
>
And here's the code to test with.
> Best regards,
> Zoltán Böszörményi
>
>
>
>
>
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
EXEC SQL BEGIN DECLARE SECTION;
int id;
chart[256];
EXEC SQL END DECLARE SECTION;
EXEC SQL DECLARE mycur CURSOR FOR SELECT * INTO :id,:t FROM t1;
int main(void) {
EXEC SQL BEGIN DECLARE SECTION;
int id;
int t;
EXEC SQL END DECLARE SECTION;
EXEC SQL CONNECT TO test;
EXEC SQL OPEN mycur;
EXEC SQL FETCH mycur;
EXEC SQL CLOSE mycur;
EXEC SQL DISCONNECT ALL;
return 0;
}
--
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] Problems with variable cursorname in ecpg
Boszormenyi Zoltan írta:
> I think you forget that in this case, only global variables are
> usable in the DECLARE in this case, no local variables in
> functions preceding the DECLARE are visible to it.
>
> What we need here is an extra check in ECPGdump_a_type().
> We need to raise an error if
> ECPGdump_a_type(name, type, ...)
> and
> var = with find_variable(name);
> on the passed name disagrees in the variable type and maybe
> a warning if they disagree in the brace_level. The same applies
> to the indicator variable. For that, we need to pass the brace_level
> to ECPGdump_a_type() for both the variable and the indicator.
>
I was thinking about something like the attached patch.
It passes all the regression tests.
Best regards,
Zoltán Böszörményi
--
Bible has answers for everything. Proof:
"But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil." (Matthew 5:37) - basics of digital technology.
"May your kingdom come" - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
http://www.postgresql.at/
diff -dcrp pgsql.orig/src/interfaces/ecpg/preproc/descriptor.c pgsql/src/interfaces/ecpg/preproc/descriptor.c
*** pgsql.orig/src/interfaces/ecpg/preproc/descriptor.c 2010-03-10 14:31:49.0 +0100
--- pgsql/src/interfaces/ecpg/preproc/descriptor.c 2010-03-31 12:34:46.0 +0200
*** output_get_descr(char *desc_name, char *
*** 188,194
break;
}
fprintf(yyout, "%s,", get_dtype(results->value));
! ECPGdump_a_type(yyout, v->name, v->type, NULL, NULL, NULL, NULL, make_str("0"), NULL, NULL);
}
drop_assignments();
fputs("ECPGd_EODT);\n", yyout);
--- 188,194
break;
}
fprintf(yyout, "%s,", get_dtype(results->value));
! ECPGdump_a_type(yyout, v->name, v->type, NULL, NULL, NULL, NULL, make_str("0"), NULL, NULL, v->brace_level, -1);
}
drop_assignments();
fputs("ECPGd_EODT);\n", yyout);
*** output_set_descr(char *desc_name, char *
*** 293,299
case ECPGd_length:
case ECPGd_type:
fprintf(yyout, "%s,", get_dtype(results->value));
! ECPGdump_a_type(yyout, v->name, v->type, NULL, NULL, NULL, NULL, make_str("0"), NULL, NULL);
break;
default:
--- 293,299
case ECPGd_length:
case ECPGd_type:
fprintf(yyout, "%s,", get_dtype(results->value));
! ECPGdump_a_type(yyout, v->name, v->type, NULL, NULL, NULL, NULL, make_str("0"), NULL, NULL, v->brace_level, -1);
break;
default:
diff -dcrp pgsql.orig/src/interfaces/ecpg/preproc/type.c pgsql/src/interfaces/ecpg/preproc/type.c
*** pgsql.orig/src/interfaces/ecpg/preproc/type.c 2010-03-31 12:44:07.0 +0200
--- pgsql/src/interfaces/ecpg/preproc/type.c 2010-03-31 13:11:24.0 +0200
*** ECPGstruct_member_dup(struct ECPGstruct_
*** 54,60
* if this array does contain a struct again, we have to
* create the struct too
*/
! if (rm->type->u.element->type == ECPGt_struct)
type = ECPGmake_struct_type(rm->type->u.element->u.members, rm->type->u.element->type, rm->type->u.element->type_name, rm->type->u.element->struct_sizeof);
else
type = ECPGmake_array_type(ECPGmake_simple_type(rm->type->u.element->type, rm->type->u.element->size, rm->type->u.element->counter), rm->type->size);
--- 54,60
* if this array does contain a struct again, we have to
* create the struct too
*/
! if (rm->type->u.element->type == ECPGt_struct || rm->type->u.element->type == ECPGt_union)
type = ECPGmake_struct_type(rm->type->u.element->u.members, rm->type->u.element->type, rm->type->u.element->type_name, rm->type->u.element->struct_sizeof);
else
type = ECPGmake_array_type(ECPGmake_simple_type(rm->type->u.element->type, rm->type->u.element->size, rm->type->u.element->counter), rm->type->size);
*** ECPGdump_a_type(FILE *o, const char *nam
*** 240,247
const char *ind_name, struct ECPGtype * ind_type,
const char *prefix, const char *ind_prefix,
char *arr_str_siz, const char *struct_sizeof,
! const char *ind_struct_sizeof)
{
switch (type->type)
{
case ECPGt_array:
--- 240,283
const char *ind_name, struct ECPGtype * ind_type,
const char *prefix, const char *ind_prefix,
char *arr_str_siz, const char *struct_sizeof,
! const char *ind_struct_sizeof,
! const int brace_level, const int ind_brace_level)
{
+ struct variable *var;
+
+ if (type->type != ECPGt_descriptor && type->type != ECPGt_sqlda &&
+ type->type != ECPGt_char_variable &&
+ brace_level >= 0)
+ {
+ char *str;
+
+ str = strdup(name);
+ var = find_variable(str);
+ free(str);
+
+ if ((var->type->type != type->type) ||
+ (var->type->type_name && !type->type_name) ||
+ (!var->type->type_name && type->type_name) ||
+ (var->type->type_name && type
Re: [HACKERS] ECPG pointer vs array
On Wed, Mar 31, 2010 at 10:37:13AM +0200, Boszormenyi Zoltan wrote: > It would be good if libecpg to support e.g. "char **strings" instead of > "char *strings[]" for preallocated strings and the array of those. > ... I'm open to improvements. The way ecpg accesses variables hasn't been changed for ages, just new types got added. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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] Problems with variable cursorname in ecpg
On Wed, Mar 31, 2010 at 10:35:31AM +0200, Boszormenyi Zoltan wrote: > > I think we should make the error message/documentation a little bit > > clearer as > > people have stumbled over it. > > Yes, we need to document it. I changed the error message and documented a possible improvement in the TODO list. > I think you forget that in this case, only global variables are > usable in the DECLARE in this case, no local variables in > functions preceding the DECLARE are visible to it. I thought about not allowing variables in declare statements that are outside a function. Do you think it makes sense to allow those? Forbidding these right now would give us more headroomfor future development. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pending patch: Re: [HACKERS] HS/SR and smart shutdown
On Wed, Mar 31, 2010 at 6:02 PM, Simon Riggs wrote: > On Wed, 2010-03-31 at 17:48 +0900, Fujii Masao wrote: >> On Wed, Mar 31, 2010 at 5:00 PM, Simon Riggs wrote: >> > Please add some docs that a) explains what the patch does and b) notes >> > any changes from behaviour in previous releases. ISTM this is a major >> > change in behaviour. >> >> How about adding the following description into "17.5. Shutting Down >> the Server"? >> >> If the server is in recovery, it waits for all of the read only >> connections to be closed. > > You need to explain which mode you're talking about. Smart Shutdown mode > Adding minimal > comments isn't my objective. We need good, useful documentation on every > aspect that you add or change. But the patch doesn't provide anything beyond: >> If the server is in recovery, it waits for all of the read only >> connections to be closed. What additional explanation do you think is required? >> And, where should the note be put in? AFAIK, the previous behavior >> has not been documented anywhere. > >> > >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect. >> > "backends might be waiting for the WAL record that conflicts with their >> > queries to be replayed". Recovery sometimes waits for backends, but >> > backends never wait for recovery. >> >> Really? As Heikki explained before, backends might wait for the lock >> taken by the startup process. >> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02984.php > > Backends wait for locks, yes, but they could be waiting for user locks > also. That is not "waiting for the WAL record", that concept does not > exist. How about the following change? -* waiting for the WAL record that conflicts with their queries to be -* replayed, recovery and replication need to remain until all read +* waiting until the startup process has released the lock that +* their queries are waiting for by replaying the WAL record, +* recovery and replication need to remain until all read Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] Performance Enhancement/Fix for Array Utility Functions
Woops. I sent the wrong patch. My apologies. Attached is the real patch. Sorry, also forgot this is made against 9.0 alpha 4 tag. Thanks, Mike -- Michael Lewis lolrus.org mikelikes...@gmail.com On Wed, Mar 31, 2010 at 12:39 AM, Mike Lewis wrote: > I noticed while doing work with very large arrays that several > functions such as array_length detoast the entire array instead of > only what is required. > > I found the solution to be just unpacking the header portion of the > array and ignoring the rest. Since the header (including the > dimensions) is variable length, I just unpack the size of what the > header would be if it had MAXDIM dimensions. (Patch is attached) > > I made a test case to demonstrate performance gains (watch out, it > creates a big table): > > create temporary table foo as > select array_agg(i) as a > from ( > select generate_series(1,1000) as i) as bar; > \timing > select array_length(a, 1) from foo; -- Run a few times. First time will be > cold > > Results (after warming up) > > Before patch: > Time: 6.251 ms > Time: 6.078 ms > Time: 5.983 ms > > After patch: > Time: 0.401 ms > Time: 0.397 ms > Time: 0.441 ms > ... > > -- > Michael Lewis > lolrus.org > mikelikes...@gmail.com > detoast-headers-for-array-functions-002.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pending patch: Re: [HACKERS] HS/SR and smart shutdown
On Wed, 2010-03-31 at 17:48 +0900, Fujii Masao wrote: > On Wed, Mar 31, 2010 at 5:00 PM, Simon Riggs wrote: > > Please add some docs that a) explains what the patch does and b) notes > > any changes from behaviour in previous releases. ISTM this is a major > > change in behaviour. > > How about adding the following description into "17.5. Shutting Down > the Server"? > > If the server is in recovery, it waits for all of the read only > connections to be closed. You need to explain which mode you're talking about. Adding minimal comments isn't my objective. We need good, useful documentation on every aspect that you add or change. > And, where should the note be put in? AFAIK, the previous behavior > has not been documented anywhere. > > >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect. > > "backends might be waiting for the WAL record that conflicts with their > > queries to be replayed". Recovery sometimes waits for backends, but > > backends never wait for recovery. > > Really? As Heikki explained before, backends might wait for the lock > taken by the startup process. > http://archives.postgresql.org/pgsql-hackers/2010-01/msg02984.php Backends wait for locks, yes, but they could be waiting for user locks also. That is not "waiting for the WAL record", that concept does not exist. -- Simon Riggs www.2ndQuadrant.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: pending patch: Re: [HACKERS] HS/SR and smart shutdown
On Wed, Mar 31, 2010 at 5:00 PM, Simon Riggs wrote: > Please add some docs that a) explains what the patch does and b) notes > any changes from behaviour in previous releases. ISTM this is a major > change in behaviour. How about adding the following description into "17.5. Shutting Down the Server"? If the server is in recovery, it waits for all of the read only connections to be closed. And, where should the note be put in? AFAIK, the previous behavior has not been documented anywhere. > >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect. > "backends might be waiting for the WAL record that conflicts with their > queries to be replayed". Recovery sometimes waits for backends, but > backends never wait for recovery. Really? As Heikki explained before, backends might wait for the lock taken by the startup process. http://archives.postgresql.org/pgsql-hackers/2010-01/msg02984.php Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ECPG pointer vs array
Hi, It would be good if libecpg to support e.g. "char **strings" instead of "char *strings[]" for preallocated strings and the array of those. IIRC, the first version overwrote my stack in a test programme, as these two are treated the same but they are not. Also, as "numeric" is supposed to be allocated using PGTYPESnumeric_new(), we would need to support array of pointers to numeric, as well as the current static array of numerics. There's no way PGTYPESnumeric_free() works on a static array, e.g. glibc will abort the app with a debug output of free() on an invalid pointer. Freeing the "digit" pointer manually is ugly, numeric has accessor functions, after all. Not doing anything leads to a memory leak. Somehow digitbuf_free() should be make visible outside for such static numeric variables. These and other types came up regarding problems with "FETCH N" in ECPG. All boils down to the same problem: "sometype *ptr" is not equivalent to "sometype ptr[]" if you use &ptr, which is used by ECPG in most cases. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/ -- 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] Problems with variable cursorname in ecpg
Michael Meskes írta: >> The interpretation of the standard in the above way (DECLARE is declarative, >> ... >> > > It's not just interpretation, but also a regression if we were to change this. > Obviously. >> The uniqueness problem can only be solved with modifying >> the runtime library to keep track of the cursor names in the client. >> It would ruin the declarative nature of DECLARE but would increase >> compatibility with Informix, and we would also need to implement >> correct "FREE cursorname" behaviour, too. Which would also bring >> the consequence that the ECPG client library would need to >> forbid cursors and prepared statements with the same name as >> "FREE" can also free cursors and prepared statements. >> > > True. > > >> I think the current behaviour is the best we could achieve >> while keeping close standard conformance. >> > > I think we should make the error message/documentation a little bit clearer > as > people have stumbled over it. Yes, we need to document it. > Having said that couldn't we keep the statement > declarative only for statements that do not carry a variable? This will not > break any onld program and besides using a variable that doesn't exist, > because > you're outside a function doesn't make sense either. I think you forget that in this case, only global variables are usable in the DECLARE in this case, no local variables in functions preceding the DECLARE are visible to it. What we need here is an extra check in ECPGdump_a_type(). We need to raise an error if ECPGdump_a_type(name, type, ...) and var = with find_variable(name); on the passed name disagrees in the variable type and maybe a warning if they disagree in the brace_level. The same applies to the indicator variable. For that, we need to pass the brace_level to ECPGdump_a_type() for both the variable and the indicator. > This is probably something > for 9.1 though if it indeed works. > Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: pending patch: Re: [HACKERS] HS/SR and smart shutdown
On Wed, 2010-03-31 at 10:48 +0900, Fujii Masao wrote: > On Wed, Mar 31, 2010 at 9:47 AM, Robert Haas wrote: > > On Tue, Mar 30, 2010 at 5:09 AM, Fujii Masao wrote: > >> I rebased the patch to HEAD. Is the patch still required for 9.0? > >> If not, I'd remove the open item of the smart shutdown during > >> recovery. > > > > I am by no means an expert on this area of the code, but in the > > interest of moving things along I reviewed this patch tonight. > > Thanks a lot! > > > 1. I wonder if there is a problem if we receive SIGINT while in the > > PM_WAIT_READONLY state? Seems to me that might need to be added to > > the if statement beginning at line 2212, in pmdie(). > > > > 2. It appears to me that HandleChildCrash() needs to switch to > > PM_WAIT_BACKENDS state if it's in PM_WAIT_READONLY when the child > > crash occurs - i.e. the if statement beginning at line 2772 needs > > updating. > > > > Thoughts? > > Oh, those are my oversights. You are right! > I modified the patch as you pointed out. Please add some docs that a) explains what the patch does and b) notes any changes from behaviour in previous releases. ISTM this is a major change in behaviour. The reason for the lack of consensus on this issue is simply people aren't following what you're talking about and don't want to have to re-read a whole thread to do so. It might be that many would agree. >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect. "backends might be waiting for the WAL record that conflicts with their queries to be replayed". Recovery sometimes waits for backends, but backends never wait for recovery. -- Simon Riggs www.2ndQuadrant.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] Alpha release this week?
On Tue, Mar 30, 2010 at 1:04 AM, Magnus Hagander wrote: > Last i heard from Dave on that topic is that there's no chance of that > happening that quickly. He's on a plane now but I'm sure he'll confirm that > when he lands. Not with any amount of testing as we'd normally give any build before releasing it anyway. I can certainly stuff a tarball into the new build machine and see what comes out the next morning. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Performance Enhancement/Fix for Array Utility Functions
I noticed while doing work with very large arrays that several functions such as array_length detoast the entire array instead of only what is required. I found the solution to be just unpacking the header portion of the array and ignoring the rest. Since the header (including the dimensions) is variable length, I just unpack the size of what the header would be if it had MAXDIM dimensions. (Patch is attached) I made a test case to demonstrate performance gains (watch out, it creates a big table): create temporary table foo as select array_agg(i) as a from ( select generate_series(1,1000) as i) as bar; \timing select array_length(a, 1) from foo; -- Run a few times. First time will be cold Results (after warming up) Before patch: Time: 6.251 ms Time: 6.078 ms Time: 5.983 ms After patch: Time: 0.401 ms Time: 0.397 ms Time: 0.441 ms ... -- Michael Lewis lolrus.org mikelikes...@gmail.com detoast-headers-for-array-functions-001.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [SPAM]Re: [HACKERS] Questions about 9.0 release note
On 31 March 2010 07:56, Takahiro Itagaki wrote: > > "Robert Haas" wrote: > >> > * (seq_page_cost/(random_page_cost)) >> > * EXCLUDE constraints has no tags to be linked. >> > * "EXCLUDE constraints" is not indexed from the Index page. > >> CREATE TABLE ... CONSTRAINT ... EXCLUDE rather than CREATE TABLE >> CONSTRAINT ... EXCLUDE. > > Here is a patch to fix the documentation. > > For exclusion constraints, I added a tag "SQL-CREATETABLE-exclude" > to of EXCLUDE in CREATE TABLE documentation. Also, > "Exclusion constraints" section is added to the constraints doc. > But the section is very short and just links to the CREATE TABLE doc. > We could move some contents from CREATE TABLE to the constraints doc. > > Regards, > --- > Takahiro Itagaki > NTT Open Source Software Center > Just one typo: "that that". Regards Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
