Re: [HACKERS] Synchronous replication Hot standby patches
On Sat, 2009-02-28 at 23:21 -0800, Josh Berkus wrote: Fujii, Again, I'm not planning to get rid of any existing capabilities Good unless necessary. That is not a caveat I will accept, a priori. While Simon stated it a bit strongly My intention was only to be clear about how important a technical point it was for me. My comments were aimed at avoiding a costly blind alley, not critically towards any individual. I am happy to apologise in case people thought my words rude. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and 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] Synchronous replication Hot standby patches
Fujii, Again, I'm not planning to get rid of any existing capabilities Good unless necessary. That is not a caveat I will accept, a priori. While Simon stated it a bit strongly, I think it's important that you alert people if you think you have to remove existing features in order to make easy standby possible. It's possible that features which seem trivial to you are used extensively by people with particular failover requirements. --Josh -- 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] cardinality()
On 1 Mar 2009, at 00:52, Andrew Dunstan wrote: We seem to have acquired a cardinality() function with almost no discussion, and it has semantics that are a bit surprising to me. I should have thought cardinality(array) would be the total number of elements in the array. Instead, it seems it is a synonym for array_length(array,1). Is that *really* what the standard says? any difference between array_upper(array,1), and cardinality ? Standart just says something like: cardinality (a collection): - The number of elements in that collection. - Those elements need not necessarily have distinct values. - The objects to which this concept applies includes tables and the values of collection types. -- 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] regression test crashes at tsearch
Hi Teodor-san. Sorry late reaction. - Original Message - From: Teodor Sigaev teo...@sigaev.ru If there's an effective function like pg_wchar2mb_with_len() which converts wchar_t strings to server encoded strings, we had better simply call it for char2wchar(). I don't see a way to produce correct result of char2wchar with C-locale and sizeof(wchar_t) = 2. In summary, I suggest to remove support of C-locale from char2wchar function and tsearch's parser should directly use pg_mb2wchar_with_len() in case of C-locale and multibyte encoding. In all other places char2wchar is called only for non-C locale. Please, test attached patch. Um, I think your patch like the overkill reaction of C-locale... However, I tried your patch. make check MULTIBYTE=euc_jp NO_LOCALE=true ... === All 120 tests passed. === Anyway, either should be applied. Thanks. Regards, Hiroshi Saito -- 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] xpath processing brain dead
Hannu Krosing wrote: Some of the functions, including some specified in the standard, produce fragments. That's why we have the 'IS DOCUMENT' test. But then you could use xmlfragments as the functions return type, no ? Does tha standard require that the same field type must store both documents and fragments ? Yes, the standard very explicitly provides for one XML type which need not be an XML document. We have no choice about that. 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] cardinality()
Grzegorz Jaskiewicz wrote: On 1 Mar 2009, at 00:52, Andrew Dunstan wrote: We seem to have acquired a cardinality() function with almost no discussion, and it has semantics that are a bit surprising to me. I should have thought cardinality(array) would be the total number of elements in the array. Instead, it seems it is a synonym for array_length(array,1). Is that *really* what the standard says? any difference between array_upper(array,1), and cardinality ? Standart just says something like: cardinality (a collection): - The number of elements in that collection. - Those elements need not necessarily have distinct values. - The objects to which this concept applies includes tables and the values of collection types. Well, I think that's a definition of the term as used in the standard, rather than of a function. But in any case, I think it goes in the right direction, and the semantics of our new function (as well as the docs) are misleading. I'm also a bit concerned that I could not find any real discussion of this new function at all on this list, so our processes seem to have slipped a bit. 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] cardinality()
Andrew Dunstan and...@dunslane.net writes: Grzegorz Jaskiewicz wrote: On 1 Mar 2009, at 00:52, Andrew Dunstan wrote: We seem to have acquired a cardinality() function with almost no discussion, and it has semantics that are a bit surprising to me. I should have thought cardinality(array) would be the total number of . elements in the array. Instead, it seems it is a synonym for array_length(array,1). Is that *really* what the standard says? Standart just says something like: cardinality (a collection): - The number of elements in that collection. The standard doesn't have multi-dimensional arrays, so it's entirely possible that somewhere in it there is wording that makes cardinality() equivalent to the length of the first dimension. But I concur with Andrew that this is flat wrong when extended to m-d arrays. 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
Re: [HACKERS] cardinality()
I wrote: The standard doesn't have multi-dimensional arrays, so it's entirely possible that somewhere in it there is wording that makes cardinality() equivalent to the length of the first dimension. But I concur with Andrew that this is flat wrong when extended to m-d arrays. I poked around in the SQL:2008 draft a bit. AFAICT the most precise statement about cardinality() is in 6.27 numeric value function: cardinality expression ::= CARDINALITYleft paren collection value expression right paren 7) The result of cardinality expression is the number of elements of the result of the collection value expression. Now the standard is only considering 1-D arrays, but I fail to see any way that it could be argued that the appropriate reading of number of elements for a multi-D array is the length of the first dimension. So I think Andrew is right and we need to fix our implementation of cardinality() while we still can. 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
Re: [HACKERS] cardinality()
2009/3/1 Tom Lane t...@sss.pgh.pa.us: I wrote: The standard doesn't have multi-dimensional arrays, so it's entirely possible that somewhere in it there is wording that makes cardinality() equivalent to the length of the first dimension. But I concur with Andrew that this is flat wrong when extended to m-d arrays. I poked around in the SQL:2008 draft a bit. AFAICT the most precise statement about cardinality() is in 6.27 numeric value function: cardinality expression ::= CARDINALITYleft paren collection value expression right paren 7) The result of cardinality expression is the number of elements of the result of the collection value expression. Now the standard is only considering 1-D arrays, but I fail to see any way that it could be argued that the appropriate reading of number of elements for a multi-D array is the length of the first dimension. So I think Andrew is right and we need to fix our implementation of cardinality() while we still can. ₊1 regards Pavel Stehule 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 -- 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] encoding conversion functions versus zero-length inputs
Tom Lane wrote: The REL7_4 members of the buildfarm are all red this morning, with this symptom in initdb: Oh dear. I must confess that I didn't test the 7.4 commit, because the 7.4 branch isn't compiling on my laptop for some reason. Seemed safe enough since the changed codepath hadn't been modified between 7.4 and later version. I guess I need to fix my 7.4 installation after all... My first thought about fixing this was just to alter the check patch to pass a length-one instead of length-zero test string, but I now think that that's just hiding our heads in the sand; the right fix is to go around and make all these palloc's len * ENCODING_GROWTH_RATE + 1 so that they are honestly accounting for the terminating null. It's a bit more tedious but it's the right fix. Agreed, thanks for the fix. -- 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] cardinality()
On Sun, 1 Mar 2009, Tom Lane wrote: I wrote: The standard doesn't have multi-dimensional arrays, so it's entirely possible that somewhere in it there is wording that makes cardinality() equivalent to the length of the first dimension. But I concur with Andrew that this is flat wrong when extended to m-d arrays. I poked around in the SQL:2008 draft a bit. AFAICT the most precise statement about cardinality() is in 6.27 numeric value function: cardinality expression ::= CARDINALITYleft paren collection value expression right paren 7) The result of cardinality expression is the number of elements of the result of the collection value expression. Now the standard is only considering 1-D arrays, but I fail to see any way that it could be argued that the appropriate reading of number of elements for a multi-D array is the length of the first dimension. Does the standard allow you to make arrays of arrays, for example with something like ARRAY[ARRAY[1,2], ARRAY[3,4]]? If so, it might be possible that cardinality(that expression) would be returning the number of arrays in the outer array. -- 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] cardinality()
On Sunday 01 March 2009 19:40:16 Tom Lane wrote: I wrote: The standard doesn't have multi-dimensional arrays, so it's entirely possible that somewhere in it there is wording that makes cardinality() equivalent to the length of the first dimension. But I concur with Andrew that this is flat wrong when extended to m-d arrays. I poked around in the SQL:2008 draft a bit. AFAICT the most precise statement about cardinality() is in 6.27 numeric value function: cardinality expression ::= CARDINALITYleft paren collection value expression right paren 7) The result of cardinality expression is the number of elements of the result of the collection value expression. Now the standard is only considering 1-D arrays, The standard represents multidimensional arrays as arrays of arrays (like in C). But the cardinality is only that of the first level array. The real question here is how we want to consider mapping what the standard has to what PostgreSQL has, and might have in the future. For example, will we ever have arrays of arrays as distinct from multidimensional arrays? Will we support things like array of multiset of array? What would the results be there? I think PostgreSQL multidimensional array support and SQL standard multidimensional array support are pretty well in line leaving aside minor syntax issues and the major syntax issue that the subscript order is reversed. So I think there is not much of a need to do much redefining and reinterpreting, unless someone has a larger and different plan in mind. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] patch for space around the FragmentDelimiter
FragmentDelimiter is an argument for ts_headline function to separates
different headline fragments. The default delimiter is ... .
Currently if someone specifies the delimiter as an option to the
function, no extra space is added around the delimiter. However, it does
not look good without space around the delimter.
Since the option parsing function removes any space around the given
value, it is not possible to add any desired space. The attached patch
adds space when a FragmentDelimiter is specified.
QUERY:
SELECT ts_headline('english', '
Day after day, day after day,
We stuck, nor breath nor motion,
As idle as a painted Ship
Upon a painted Ocean.
Water, water, every where
And all the boards did shrink;
Water, water, every where,
Nor any drop to drink.
S. T. Coleridge (1772-1834)
', to_tsquery('english', 'Coleridge stuck'),
'MaxFragments=2,FragmentDelimiter=***');
OLD RESULT
ts_headline
after day, day after day,
We bstuck/b, nor breath nor motion,
As idle as a painted Ship
Upon a painted Ocean.
Water, water, every where
And all the boards did shrink;
Water, water, every where***drop to drink.
S. T. bColeridge/b
(1 row)
NEW RESULT after the patch
ts_headline
--
after day, day after day,
We bstuck/b, nor breath nor motion,
As idle as a painted Ship
Upon a painted Ocean.
Water, water, every where
And all the boards did shrink;
Water, water, every where *** drop to drink.
S. T. bColeridge/b
Index: src/backend/tsearch/wparser_def.c
===
RCS file: /home/sushant/devel/pgrep/pgsql/src/backend/tsearch/wparser_def.c,v
retrieving revision 1.20
diff -c -r1.20 wparser_def.c
*** src/backend/tsearch/wparser_def.c 15 Jan 2009 16:33:59 - 1.20
--- src/backend/tsearch/wparser_def.c 2 Mar 2009 06:00:02 -
***
*** 2082,2087
--- 2082,2088
int shortword = 3;
int max_fragments = 0;
int highlight = 0;
+ int len;
ListCell *l;
/* config */
***
*** 2105,2111
else if (pg_strcasecmp(defel-defname, StopSel) == 0)
prs-stopsel = pstrdup(val);
else if (pg_strcasecmp(defel-defname, FragmentDelimiter) == 0)
! prs-fragdelim = pstrdup(val);
else if (pg_strcasecmp(defel-defname, HighlightAll) == 0)
highlight = (pg_strcasecmp(val, 1) == 0 ||
pg_strcasecmp(val, on) == 0 ||
--- 2106,2116
else if (pg_strcasecmp(defel-defname, StopSel) == 0)
prs-stopsel = pstrdup(val);
else if (pg_strcasecmp(defel-defname, FragmentDelimiter) == 0)
! {
! len = strlen(val) + 2 + 1;/* 2 for spaces and 1 for end of string */
! prs-fragdelim = palloc(len * sizeof(char));
! snprintf(prs-fragdelim, len, %s , val);
! }
else if (pg_strcasecmp(defel-defname, HighlightAll) == 0)
highlight = (pg_strcasecmp(val, 1) == 0 ||
pg_strcasecmp(val, on) == 0 ||
Index: src/test/regress/expected/tsearch.out
===
RCS file: /home/sushant/devel/pgrep/pgsql/src/test/regress/expected/tsearch.out,v
retrieving revision 1.15
diff -c -r1.15 tsearch.out
*** src/test/regress/expected/tsearch.out 17 Oct 2008 18:05:19 - 1.15
--- src/test/regress/expected/tsearch.out 2 Mar 2009 02:02:38 -
***
*** 624,630
body
bSea/b view wow ubfoo/b bar/u iqq/i
a href=http://www.google.com/foo.bar.html; target=_blankYES nbsp;/a
! ff-bg
script
document.write(15);
/script
--- 624,630
body
bSea/b view wow ubfoo/b bar/u iqq/i
a href=http://www.google.com/foo.bar.html; target=_blankYES nbsp;/a
! ff-bg
script
document.write(15);
/script
***
*** 712,726
Nor any drop to drink.
S. T. Coleridge (1772-1834)
', to_tsquery('english', 'Coleridge stuck'), 'MaxFragments=2,FragmentDelimiter=***');
! ts_headline
!
after day, day after day,
We bstuck/b, nor breath nor motion,
As idle as a painted Ship
Upon a painted Ocean.
Water, water, every where
And all the boards did shrink;
! Water, water, every where***drop to drink.
S. T. bColeridge/b
(1 row)
--- 712,726
Nor any drop to drink.
S. T. Coleridge (1772-1834)
', to_tsquery('english', 'Coleridge stuck'), 'MaxFragments=2,FragmentDelimiter=***');
! ts_headline
! --
after day, day after day,
We bstuck/b, nor breath nor motion,
As idle as a painted Ship
Upon a painted Ocean.
Water, water, every where
And all the boards did shrink;
! Water, water, every where *** drop to drink.
S. T. bColeridge/b
(1 row)
--
Sent via pgsql-hackers mailing list
Re: [HACKERS] xpath processing brain dead
On Sun, 2009-03-01 at 10:13 -0500, Andrew Dunstan wrote: Hannu Krosing wrote: Some of the functions, including some specified in the standard, produce fragments. That's why we have the 'IS DOCUMENT' test. But then you could use xmlfragments as the functions return type, no ? Does tha standard require that the same field type must store both documents and fragments ? Yes, the standard very explicitly provides for one XML type which need not be an XML document. We have no choice about that. What is it then ? A sequence of XML elements ? Which standard does postgreSQL XML type need to confirm to - general XML DB, Xpath or some other XML ? XML Path Language (XPath) Version 1.0 -- starts with this Abstract: XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. So I think that using Xpath on anything else than XML document is invalid and results are undefined. XML 1.0 and XML 1.1 --- Also, both XML 1.0 and XML 1.1 standards are about a thing called an XML document, so I don't see anything there, which would make us accept anything else as being XML. And SQL 2008, Part 14: XML-Related Specifications (SQL/XML) --- Says: SQL defines a predefined data type named by the following key word: XML. ... The data types XML(DOCUMENT(UNTYPED)), XML(DOCUMENT(ANY)), XML(DOCUMENT(XMLSCHEMA)), XML(CONTENT(UNTYPED)), XML(CONTENT(ANY)), XML(CONTENT(XMLSCHEMA)), and XML(SEQUENCE) are referred to as the XML types. Values of XML types are called XML values. So while the type itself could be called XML, there are several subtypes, like Document, Content and Sequence Could the XML(SEQUENCE) better be represented as an array of xml documents aka. xml[] , and maybe CONTENT could be done as xmlelement[] where xmlelement can be any single XML element, including CDATA and plain text ? cheers andrew -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- 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] xpath processing brain dead
Hannu Krosing wrote: On Sun, 2009-03-01 at 10:13 -0500, Andrew Dunstan wrote: Hannu Krosing wrote: Some of the functions, including some specified in the standard, produce fragments. That's why we have the 'IS DOCUMENT' test. But then you could use xmlfragments as the functions return type, no ? Does tha standard require that the same field type must store both documents and fragments ? Yes, the standard very explicitly provides for one XML type which need not be an XML document. We have no choice about that. What is it then ? A sequence of XML elements ? In its typically oblique way, the 2003 draft says this: NOTE 1 — An XML root information item is similar to an XML document information item, with the following modifications: an XML root information item does not have a [document element] property, a [base URI] property, a [character encoding scheme] property, or an [all declarations processed] property; and the [children] property permits more than one XML element information item. An SQL/XML information item is either an XML root information item or one of the following (defined in Subclause 3.1.3, “Definitions provided in Part 14”): an XML attribute information item, an XML character information item, an XML comment information item, an XML document type declaration information item, an XML element information item, an XML namespace information item, an XML notation information item, an XML processing instruction information item, an XML unexpanded entity reference information item, or an XML unparsed entity information item. An XML value is either the null value, or a collection of SQL/XML information items, consisting of exactly one XML root information item, plus any other SQL/XML information items that can be reached recursively by traversing the properties of the SQL/XML information items. Which standard does postgreSQL XML type need to confirm to - general XML DB, Xpath or some other XML ? I think the XML type needs to conform to the SQL/XML spec. However, we are trying to apply XPath, which has a different data model, to that type - hence the impedance mismatch. I think that the best we can do (for 8.4, having fixed 8.3 as best we can without adversely changing behaviour) is to throw the responsibility for ensuring that the XML passed to the function is an XML document back on the programmer. Anything else, especially any mangling of the XPath expression, presents a very real danger of breaking on correct input. 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] cardinality()
Peter Eisentraut pete...@gmx.net writes: The standard represents multidimensional arrays as arrays of arrays (like in C). Uh, C doesn't represent multidimensional arrays as arrays of arrays so you've lost me already. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication 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] cardinality()
Gregory Stark wrote: Peter Eisentraut pete...@gmx.net writes: The standard represents multidimensional arrays as arrays of arrays (like in C). Uh, C doesn't represent multidimensional arrays as arrays of arrays so you've lost me already. I think he meant to say C _can_ represent multidimensional arrays as arrays of arrays. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 space around the FragmentDelimiter
Sushant Sinha sushant...@gmail.com writes: FragmentDelimiter is an argument for ts_headline function to separates different headline fragments. The default delimiter is ... . Currently if someone specifies the delimiter as an option to the function, no extra space is added around the delimiter. However, it does not look good without space around the delimter. Maybe not to you, for the particular delimiter you happen to be working with, but it doesn't follow that spaces are always appropriate. Since the option parsing function removes any space around the given value, it is not possible to add any desired space. The attached patch adds space when a FragmentDelimiter is specified. I think this is a pretty bad idea. Better would be to document how to get spaces into the delimiter, ie, use double quotes: ... FragmentDelimiter = ... ... Hmm, actually, it looks to me that the documentation already shows this, in the example of the default values. 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
Re: [HACKERS] WIP: named and mixed notation support
Pavel Stehule pavel.steh...@gmail.com writes: postgres=# create function dfunc(a int, b int = 1, c int) returns table (a int, b int, c int) as $$ select $1, $2, $3; $$ language sql; The above is simply a horrid idea. It'll completely break any ability to resolve ambiguous function calls in a sane way. What, for example, will you do given dfunc(1,2) and alternatives create function dfunc(a int, b int = 1, c int) ... create function dfunc(a int, b int, c int = 1) ... We should *not* remove the restriction that all parameters after the first one with a default also have to have defaults. 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
Re: [HACKERS] Synchronous replication Hot standby patches
Hi, On Sun, Mar 1, 2009 at 4:21 PM, Josh Berkus j...@agliodbs.com wrote: While Simon stated it a bit strongly, I think it's important that you alert people if you think you have to remove existing features in order to make easy standby possible. Now, I think that any existing capabilities don't need to be removed for Synch Rep. It's possible that features which seem trivial to you are used extensively by people with particular failover requirements. Of course, I have no intention of ignoring such people. 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] patch for space around the FragmentDelimiter
yeah you are right. I did not know that you can pass space using double quotes. -Sushant. On Sun, 2009-03-01 at 20:49 -0500, Tom Lane wrote: Sushant Sinha sushant...@gmail.com writes: FragmentDelimiter is an argument for ts_headline function to separates different headline fragments. The default delimiter is ... . Currently if someone specifies the delimiter as an option to the function, no extra space is added around the delimiter. However, it does not look good without space around the delimter. Maybe not to you, for the particular delimiter you happen to be working with, but it doesn't follow that spaces are always appropriate. Since the option parsing function removes any space around the given value, it is not possible to add any desired space. The attached patch adds space when a FragmentDelimiter is specified. I think this is a pretty bad idea. Better would be to document how to get spaces into the delimiter, ie, use double quotes: ... FragmentDelimiter = ... ... Hmm, actually, it looks to me that the documentation already shows this, in the example of the default values. 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
Re: [HACKERS] Immediate shutdown and system(3)
Hi, On Fri, Feb 27, 2009 at 6:52 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: We're using SIGQUIT to signal immediate shutdown request. Upon receiving SIGQUIT, postmaster in turn kills all the child processes with SIGQUIT and exits. This is a problem when child processes use system(3) to call other programs. We use system(3) in two places: to execute archive_command and restore_command. Fujii Masao identified this with pg_standby back in November: http://archives.postgresql.org/message-id/3f0b79eb0811280156s78a3730en73aca49b6e95d...@mail.gmail.com and recently discussed here http://archives.postgresql.org/message-id/3f0b79eb0902260919l2675aaafq10e5b2d49ebfa...@mail.gmail.com I'm starting a new thread to bring this to attention of those who haven't been following the hot standby stuff. pg_standby has a particular problem because it traps SIGQUIT to mean end recovery, promote standby to master, which it shouldn't do IMHO. But ignoring that for a moment, the problem is generic. SIGQUIT by default dumps core. That's not what we want to happen on immediate shutdown. All PostgreSQL processes trap SIGQUIT to exit immediately instead, but external commands will dump core. system(3) ignores SIGQUIT, so we can't trap it in the parent process; it is always relayed to the child. There's a few options on how to fix that: 1. Implement a custom version of system(3) using fork+exec that let's us trap SIGQUIT and send e.g SIGTERM or SIGINT to the child instead. It might be a bit tricky to get this right in a portable way; Windows would certainly need a completely separate implementation. 2. Use a signal other than SIGQUIT for immediate shutdown of child processes. We can't change the signal sent to postmaster for backwards-compatibility reasons, but the signal sent by postmaster to child processes we could change. We've already used all signals in normal backends, but perhaps we could rearrange them. 3. Use SIGINT instead of SIGQUIT for immediate shutdown of the two child processes that use system(3): the archiver process and the startup process. Neither of them use SIGINT currently. SIGINT is ignored by system(3), like SIGQUIT, but the default action is to terminate the process rather than core dump. Unfortunately pg_standby traps SIGINT too to mean promote to master, but we could change it to use SIGUSR1 instead for that purpose. If someone has a script that uses killall -INT pg_standby to promote a standby server to master, it would need to be changed. Looking at the manual page of pg_standby, however, it seems that the kill-method of triggering a promotion isn't documented, so with a notice in release notes we could do that. I'm leaning towards option 3, but I wonder if anyone sees a better solution. 4. Use the shared memory to tell the startup process about the shutdown state. When a shutdown signal arrives, postmaster sets the corresponding shutdown state to the shared memory before signaling to the child processes. The startup process check the shutdown state whenever executing system(), and determine how to exit according to that state. This solution doesn't change any existing behavior of pg_standby. What is your opinion? 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] WIP: named and mixed notation support
2009/3/2 Tom Lane t...@sss.pgh.pa.us: Pavel Stehule pavel.steh...@gmail.com writes: postgres=# create function dfunc(a int, b int = 1, c int) returns table (a int, b int, c int) as $$ select $1, $2, $3; $$ language sql; The above is simply a horrid idea. It'll completely break any ability to resolve ambiguous function calls in a sane way. What, for example, will you do given dfunc(1,2) and alternatives no, it's not ambigonous, because named (mixed) notation and positional notation is distinct. create function dfunc(a int, b int = 1, c int) ... - var A create function dfunc(a int, b int, c int = 1) ... - var B yes, this case should be prohibited. what will be executed for dfunc(10,20,30) - A or B? Regards Pavel We should *not* remove the restriction that all parameters after the first one with a default also have to have defaults. I don't thing it. Function like fx(some with defaults, some) should be called only in named notation or with full set of parameters. For position notation (current behave) this function is invisible.So your restriction is maybe not necessary, but restriction should be good for simplicity - then I don't need default bitmap and it's true, so it's enough for probably an most used case func([non optional params], named optional flags with default) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
