Re: [HACKERS] EOL is when?
On Thu, 2010-06-24 at 10:32 -0400, Tom Lane wrote: Magnus Hagander mag...@hagander.net writes: On Thu, Jun 24, 2010 at 15:39, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: On 24/06/10 14:41, Magnus Hagander wrote: Our versioning policy (http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy) says that we EOL 7.4 and 8.0 July 2010. Does that mean July 1st or July 31st? Probably means one more minor release, and that's it. Yes, but I care about what actual date we mean. A month is a lot of time :-) There is no actual date as yet. Whenever the next set of minor releases come out will be the last one for 7.4 and 8.0. We'll keep back-patching those branches as appropriate up till then. I think we should have both. People need an exact date so they can discuss in their organisations the consequences of not upgrading. Without a date, those discussions become more complicated because it sounds like our intentions are unclear and may be subject to change. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- 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] Streaming Replication: sql error on standby
On Wed, 2010-06-23 at 10:48 +0200, Sander, Ingo (NSN - DE/Munich) wrote: Sql query select pg_last_xlog_receive_location(); does not work during startup of standby database. Thanks for the report. We need to understand more about what you are saying. There is no error message with that text. TestScenario; We have a active-standby system with PostgreSQL Streaming Replication beta2. If the active database is up the database is in use (read/write queries will be performed). Then the standby PostgreSQL SR will be started (the complete database from the active side is copied to the standby side; nec. Files for starting streaming replication are created). Directly after the possibility to connect to the standby system, the above given sql query will be executed. To this timepoint the sql query delivers an error. To a later timepoint (all wal segments are completly incooperated) the query delivers a valid result. Question: What is the reason for the error? Exists a command to find out if the standby database is really active to accept/can work with sql commands? Could you show us the log? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- 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] Re: [COMMITTERS] pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.
On Fri, 2010-06-25 at 10:56 -0700, Josh Berkus wrote: Shouldn't this be backpatched, or was this a new bug in 9.0? We've always output bytes. I'd have noticed the discrepancy myself if I'd read the actual docs ;-) We can still output bytes, no problem. The issue is that the parameter is actually measured in bytes, whereas the docs say kilobytes, so you get much more log output than you were expecting. KB would be more useful. And I don't think people have enough scripts built on this yet to make this break anything. We should backport to 8.4. OK -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- 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] GSoC - code of implementation of materialized views
On Fri, 2010-06-25 at 20:24 +0200, Pavel Baros wrote: ... also you can look at enclosed patch. No tests == no patch Always best to work on the tests first, so everybody can see the syntax you are proposing, and also see if your patch actually works. Otherwise you may find people disagree and then you are faced with extensive rework. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: parallelizing subplan execution (was: [HACKERS] explain and PARAM_EXEC)
On Sat, 2010-06-26 at 21:01 -0400, Robert Haas wrote: The section (from that same paper) on parallelizing hash joins and merge-join-over-sort is interesting, and I can definitely imagine those techniques being a win for us. But I'm not too sure how we'd know when to apply them - that is, what algorithm would the query optimizer use? I'm sure we could come up with something, but I'd get a warmer, fuzzier feeling if we could implement the fruits of someone else's research rather than rolling our own. You've just touched on why parallel query is hard. There is a big bucket of executor code to write and then lots of very subtle thinking, heuristics and usability parameters to make parallel query sensibly optimised. You need both to make it actually work in practice (without hints). Parallel sub-plans is not a good case to start with because it presumes only certain kinds of plans are in place. It wouldn't be usable for the majority of plans. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why are these modules built without respecting my LDFLAGS?
I have a short list of modules that have been built without respecting my LDFLAGS and/or LDFLAGS_SL. They are as follows: autoinc.so citext.so earthdistance.so insert_username.so isn.so lo.so moddatetime.so refint.so tablefunc.so timetravel.so tsearch2.so I have looked around in the documentation and the source code, but have found nothing enlightening. Is there a way to force them to be built with my LDFLAGS? Is it a bad idea? If so, why? Sincerely, Aaron W. Swenson -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why are these modules built without respecting my LDFLAGS?
Aaron W. Swenson aaron.w.swen...@gmail.com writes: I have a short list of modules that have been built without respecting my LDFLAGS and/or LDFLAGS_SL. It's difficult to comment on this since you haven't told us what flags you wanted to inject, nor exactly how you tried to inject them, nor what version of PG you're working with, nor what platform you're on. But generally speaking I'd expect the values of those variables set by configure to be used in linking all contrib modules. 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
[PATCH] Re: [HACKERS] Adding XMLEXISTS to the grammar
and finally in pg_proc.h I have:
DATA(insert OID = 3037 ( xmlexists PGNSP PGUID 12 1 0 0 f f f t f i 3 0
16 25 142 _null_ _null_ _null_ _null_ xml_exists _null_ _null_ _null_ ));
DESCR(evaluate XPath expression in a boolean context);
It looks like the pg_proc entry is creating an SQL function called
xmlexists referencing a C function called xml_exists, and the gram.y
changes want there to be an SQL function called xml_exists. I think
you should rip out all the catalog and parser changes for starters,
and just try to get it working as a regular old function. Once you
have that working, you can add the syntax support back in. I'd
suggest making the C and SQL function names the same as each other,
but different from the keyword you're planning to use (xmlexists).
Thanks again for your help Robert, turns out the fault was in the
pg_proc entry (the 3 up there should've been a two!). Once I took the
grammar out it was quickly obvious where I'd gone wrong.
Attached is a patch with the revised XMLEXISTS function, complete with
grammar support and regression tests. The implemented grammar is:
XMLEXISTS ( xpath_expression PASSING BY REF xml_value [BY REF] )
Though the full grammar makes everything after the xpath_expression
optional, I've left it has mandatory simply to avoid lots of rework of
the function (would need new null checks, memory handling would need
reworking).
--
Mike Fowler
Registered Linux user: 379787
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
***
*** 423,431 static TypeName *TableFuncTypeName(List *columns);
%type list opt_check_option
%type target xml_attribute_el
! %type list xml_attribute_list xml_attributes
%type node xml_root_version opt_xml_root_standalone
! %type ival document_or_content
%type boolean xml_whitespace_option
%type node common_table_expr
--- 423,432
%type list opt_check_option
%type target xml_attribute_el
! %type list xml_attribute_list xml_attributes xmlexists_list
%type node xml_root_version opt_xml_root_standalone
! %type node xmlexists_query_argument_list xml_default_passing_mechanism xml_passing_mechanism
! %type ival document_or_content
%type boolean xml_whitespace_option
%type node common_table_expr
***
*** 511,523 static TypeName *TableFuncTypeName(List *columns);
OBJECT_P OF OFF OFFSET OIDS ON ONLY OPERATOR OPTION OPTIONS OR
ORDER OUT_P OUTER_P OVER OVERLAPS OVERLAY OWNED OWNER
! PARSER PARTIAL PARTITION PASSWORD PLACING PLANS POSITION
PRECEDING PRECISION PRESERVE PREPARE PREPARED PRIMARY
PRIOR PRIVILEGES PROCEDURAL PROCEDURE
QUOTE
! RANGE READ REAL REASSIGN RECHECK RECURSIVE REFERENCES REINDEX
RELATIVE_P RELEASE RENAME REPEATABLE REPLACE REPLICA RESET RESTART
RESTRICT RETURNING RETURNS REVOKE RIGHT ROLE ROLLBACK ROW ROWS RULE
--- 512,524
OBJECT_P OF OFF OFFSET OIDS ON ONLY OPERATOR OPTION OPTIONS OR
ORDER OUT_P OUTER_P OVER OVERLAPS OVERLAY OWNED OWNER
! PARSER PARTIAL PARTITION PASSING PASSWORD PLACING PLANS POSITION
PRECEDING PRECISION PRESERVE PREPARE PREPARED PRIMARY
PRIOR PRIVILEGES PROCEDURAL PROCEDURE
QUOTE
! RANGE READ REAL REASSIGN RECHECK RECURSIVE REF REFERENCES REINDEX
RELATIVE_P RELEASE RENAME REPEATABLE REPLACE REPLICA RESET RESTART
RESTRICT RETURNING RETURNS REVOKE RIGHT ROLE ROLLBACK ROW ROWS RULE
***
*** 539,545 static TypeName *TableFuncTypeName(List *columns);
WHEN WHERE WHITESPACE_P WINDOW WITH WITHOUT WORK WRAPPER WRITE
! XML_P XMLATTRIBUTES XMLCONCAT XMLELEMENT XMLFOREST XMLPARSE
XMLPI XMLROOT XMLSERIALIZE
YEAR_P YES_P
--- 540,546
WHEN WHERE WHITESPACE_P WINDOW WITH WITHOUT WORK WRAPPER WRITE
! XML_P XMLATTRIBUTES XMLCONCAT XMLELEMENT XMLEXISTS XMLFOREST XMLPARSE
XMLPI XMLROOT XMLSERIALIZE
YEAR_P YES_P
***
*** 9806,9811 func_expr: func_name '(' ')' over_clause
--- 9807,9828
{
$$ = makeXmlExpr(IS_XMLELEMENT, $4, $6, $8, @1);
}
+ | XMLEXISTS '(' xmlexists_list ')'
+ {
+ /* xmlexists(A [PASSING BY REF B [BY REF]]) is converted to
+ * xmlexists(A, B)*/
+
+ FuncCall *n = makeNode(FuncCall);
+ n-funcname = SystemFuncName(xmlexists);
+ n-args = $3;
+ n-agg_order = NIL;
+ n-agg_star = FALSE;
+ n-agg_distinct = FALSE;
+ n-func_variadic = FALSE;
+ n-over = NULL;
+ n-location = @1;
+ $$ = (Node *)n;
+ }
| XMLFOREST '(' xml_attribute_list ')'
{
$$ = makeXmlExpr(IS_XMLFOREST, NULL, $3, NIL, @1);
***
*** 9896,9901 xml_whitespace_option: PRESERVE WHITESPACE_P { $$ = TRUE; }
--- 9913,9946
| /*EMPTY*/{ $$ = FALSE; }
;
+ xmlexists_list:
+ AexprConst xmlexists_query_argument_list
+ {
+ $$ = list_make2(makeTypeCast($1,SystemTypeName(text), -1), $2);
+ }
+ ;
+
+ xmlexists_query_argument_list:
+
[PATCH] Re: [HACKERS] Adding xpath_exists function
Bruce Momjian wrote:
I have added this to the next commit-fest:
https://commitfest.postgresql.org/action/commitfest_view?id=6
Thanks Bruce. Attached is a revised patch which changes the code
slightly such that it uses an older version of the libxml library. I've
added comments to the code so that we remember why we didn't use the
latest function.
Regards,
--
Mike Fowler
Registered Linux user: 379787
*** a/src/backend/utils/adt/xml.c
--- b/src/backend/utils/adt/xml.c
***
*** 3495,3497 xpath(PG_FUNCTION_ARGS)
--- 3495,3681
return 0;
#endif
}
+
+ /*
+ * Determines if the node specified by the supplied XPath exists
+ * in a given XML document, returning a boolean.
+ *
+ * It is up to the user to ensure that the XML passed is in fact
+ * an XML document - XPath doesn't work easily on fragments without
+ * a context node being known.
+ */
+ Datum
+ xpath_exists(PG_FUNCTION_ARGS)
+ {
+ #ifdef USE_LIBXML
+ text *xpath_expr_text = PG_GETARG_TEXT_P(0);
+ xmltype*data = PG_GETARG_XML_P(1);
+ ArrayType *namespaces = PG_GETARG_ARRAYTYPE_P(2);
+ ArrayBuildState *astate = NULL;
+ xmlParserCtxtPtr ctxt = NULL;
+ xmlDocPtr doc = NULL;
+ xmlXPathContextPtr xpathctx = NULL;
+ xmlXPathCompExprPtr xpathcomp = NULL;
+ xmlXPathObjectPtr xpathobj = NULL;
+ char *datastr;
+ int32 len;
+ int32 xpath_len;
+ xmlChar*string;
+ xmlChar*xpath_expr;
+ int i;
+ int res_nitems;
+ int ndim;
+ Datum *ns_names_uris;
+ bool *ns_names_uris_nulls;
+ int ns_count;
+ int result;
+
+ /*
+ * Namespace mappings are passed as text[]. If an empty array is passed
+ * (ndim = 0, 0-dimensional), then there are no namespace mappings.
+ * Else, a 2-dimensional array with length of the second axis being equal
+ * to 2 should be passed, i.e., every subarray contains 2 elements, the
+ * first element defining the name, the second one the URI. Example:
+ * ARRAY[ARRAY['myns', 'http://example.com'], ARRAY['myns2',
+ * 'http://example2.com']].
+ */
+ ndim = ARR_NDIM(namespaces);
+ if (ndim != 0)
+ {
+ int *dims;
+
+ dims = ARR_DIMS(namespaces);
+
+ if (ndim != 2 || dims[1] != 2)
+ ereport(ERROR,
+ (errcode(ERRCODE_DATA_EXCEPTION),
+ errmsg(invalid array for XML namespace mapping),
+ errdetail(The array must be two-dimensional with length of the second axis equal to 2.)));
+
+ Assert(ARR_ELEMTYPE(namespaces) == TEXTOID);
+
+ deconstruct_array(namespaces, TEXTOID, -1, false, 'i',
+ ns_names_uris, ns_names_uris_nulls,
+ ns_count);
+
+ Assert((ns_count % 2) == 0); /* checked above */
+ ns_count /= 2; /* count pairs only */
+ }
+ else
+ {
+ ns_names_uris = NULL;
+ ns_names_uris_nulls = NULL;
+ ns_count = 0;
+ }
+
+ datastr = VARDATA(data);
+ len = VARSIZE(data) - VARHDRSZ;
+ xpath_len = VARSIZE(xpath_expr_text) - VARHDRSZ;
+ if (xpath_len == 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_DATA_EXCEPTION),
+ errmsg(empty XPath expression)));
+
+ string = (xmlChar *) palloc((len + 1) * sizeof(xmlChar));
+ memcpy(string, datastr, len);
+ string[len] = '\0';
+
+ xpath_expr = (xmlChar *) palloc((xpath_len + 1) * sizeof(xmlChar));
+ memcpy(xpath_expr, VARDATA(xpath_expr_text), xpath_len);
+ xpath_expr[xpath_len] = '\0';
+
+ pg_xml_init();
+ xmlInitParser();
+
+ PG_TRY();
+ {
+ /*
+ * redundant XML parsing (two parsings for the same value during one
+ * command execution are possible)
+ */
+ ctxt = xmlNewParserCtxt();
+ if (ctxt == NULL)
+ xml_ereport(ERROR, ERRCODE_OUT_OF_MEMORY,
+ could not allocate parser context);
+ doc = xmlCtxtReadMemory(ctxt, (char *) string, len, NULL, NULL, 0);
+ if (doc == NULL)
+ xml_ereport(ERROR, ERRCODE_INVALID_XML_DOCUMENT,
+ could not parse XML document);
+ xpathctx = xmlXPathNewContext(doc);
+ if (xpathctx == NULL)
+ xml_ereport(ERROR, ERRCODE_OUT_OF_MEMORY,
+ could not allocate XPath context);
+ xpathctx-node = xmlDocGetRootElement(doc);
+ if (xpathctx-node == NULL)
+ xml_ereport(ERROR, ERRCODE_INTERNAL_ERROR,
+ could not find root XML element);
+
+ /* register namespaces, if any */
+ if (ns_count 0)
+ {
+ for (i = 0; i ns_count; i++)
+ {
+ char *ns_name;
+ char *ns_uri;
+
+ if (ns_names_uris_nulls[i * 2] ||
+ ns_names_uris_nulls[i * 2 + 1])
+ ereport(ERROR,
+ (errcode(ERRCODE_NULL_VALUE_NOT_ALLOWED),
+ errmsg(neither namespace name nor URI may be null)));
+ ns_name = TextDatumGetCString(ns_names_uris[i * 2]);
+ ns_uri = TextDatumGetCString(ns_names_uris[i * 2 + 1]);
+ if (xmlXPathRegisterNs(xpathctx,
+ (xmlChar *) ns_name,
+ (xmlChar *) ns_uri) != 0)
+ ereport(ERROR, /* is this an internal error??? */
+ (errmsg(could not register XML namespace with name \%s\ and URI \%s\,
+ ns_name, ns_uri)));
+ }
+ }
+
+ xpathcomp =
[HACKERS] pg_dump's checkSeek() seems inadequate
While testing a fix for the pg_restore issues mentioned a few days ago, I noticed that checkSeek() returns true on my old HPUX box even when the input is in fact not seekable, for instance a pipe. This leads to pg_restore failing completely in cases where it ought to work, like this: $ cat vector.dump | pg_restore -d vector pg_restore: [custom archiver] WARNING: ftell mismatch with expected position -- ftell used pg_restore: [custom archiver] error during file seek: Illegal seek $ The test that checkSeek() is using is to see whether this works: fseeko(fp, 0, SEEK_CUR) and apparently on this platform that's a no-op even on an otherwise unseekable file. I don't know how common this behavior is; I don't recall having seen complaints about pg_restore failing for other people. If I change the test to be fseeko(fp, 0, SEEK_SET) then it does the right thing. Since checkSeek() is applied immediately after opening the input file this should be OK, but it does limit the scope of usefulness of that function. Any thoughts about whether or not to apply such a patch? If it should be changed, should we back-patch it? 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] pg_dump's checkSeek() seems inadequate
I wrote: The test that checkSeek() is using is to see whether this works: fseeko(fp, 0, SEEK_CUR) and apparently on this platform that's a no-op even on an otherwise unseekable file. BTW, I looked in the archives for related discussions and found only the thread in which the current fseek-checking code was designed. There were a couple of mentions that SEEK_CUR should be changed to SEEK_SET, eg http://archives.postgresql.org/pgsql-hackers/2002-10/msg01088.php but it was apparently focused around coping with specific seek APIs that didn't have SEEK_CUR at all. We ended up not using those so the change was never made. The thought that a no-op seek might not give the right answer wasn't discussed AFAICT. 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] GSoC - code of implementation of materialized views
On Sun, Jun 27, 2010 at 12:52:17PM +0100, Simon Riggs wrote: On Fri, 2010-06-25 at 20:24 +0200, Pavel Baros wrote: ... also you can look at enclosed patch. No tests == no patch This isn't quite how I'd have phrased it, and it would be nice if nobody phrased advice quite this way. :) In order for a patch to be accepted, it needs to include both SGML docs if it changes user-visible behavior, and tests for any new behaviors it has created. This is the project standard, and it or something very like it is a good standard for just about any project, as it gives people some ways to test intent vs. effect. Do you want some help with creating same? Cheers, David. -- David Fetter da...@fetter.org 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
Re: [PATCH] Re: [HACKERS] Adding XMLEXISTS to the grammar
On Sun, Jun 27, 2010 at 12:04 PM, Mike Fowler m...@mlfowler.com wrote: Thanks again for your help Robert, turns out the fault was in the pg_proc entry (the 3 up there should've been a two!). Once I took the grammar out it was quickly obvious where I'd gone wrong. Glad it was a helpful suggestion. Attached is a patch with the revised XMLEXISTS function, complete with grammar support and regression tests. The implemented grammar is: XMLEXISTS ( xpath_expression PASSING BY REF xml_value [BY REF] ) Though the full grammar makes everything after the xpath_expression optional, I've left it has mandatory simply to avoid lots of rework of the function (would need new null checks, memory handling would need reworking). So if you don't specify the xml_value, what does the xpath_expression get applied to? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump's checkSeek() seems inadequate
On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: If I change the test to be fseeko(fp, 0, SEEK_SET) then it does the right thing. Since checkSeek() is applied immediately after opening the input file this should be OK, but it does limit the scope of usefulness of that function. Any thoughts about whether or not to apply such a patch? If it should be changed, should we back-patch it? Well, I guess it depends on what you think the chances are that the revised test will fail on some other obscure platform. Have there been any reports from the field? If not, I might apply to HEAD and await developments. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_dump's checkSeek() seems inadequate
Robert Haas robertmh...@gmail.com writes: On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: If I change the test to be fseeko(fp, 0, SEEK_SET) then it does the right thing. Well, I guess it depends on what you think the chances are that the revised test will fail on some other obscure platform. To believe that, you'd have to believe that fseeko(fp, 0, SEEK_SET) will fail but fseeko(fp, something-not-zero, SEEK_SET) will succeed. A somewhat more plausible scenario is that somebody might hope that they could do something like this: echo 'some custom header' pg.dump pg_dump -Fc pg.dump I believe that (at least on most Unixen) doing fseeko(fp, 0, SEEK_SET) would result in overwriting the custom header, where it would not have been overwritten before. However the usefulness of the above is at best far-fetched; and I'm not very sure that it works today anyway, since pg_dump/pg_restore seem to assume that manual byte counting should match the results of ftell(). 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: [PATCH] Re: [HACKERS] Adding XMLEXISTS to the grammar
Robert Haas wrote: On Sun, Jun 27, 2010 at 12:04 PM, Mike Fowler m...@mlfowler.com wrote: Thanks again for your help Robert, turns out the fault was in the pg_proc entry (the 3 up there should've been a two!). Once I took the grammar out it was quickly obvious where I'd gone wrong. Glad it was a helpful suggestion. Attached is a patch with the revised XMLEXISTS function, complete with grammar support and regression tests. The implemented grammar is: XMLEXISTS ( xpath_expression PASSING BY REF xml_value [BY REF] ) Though the full grammar makes everything after the xpath_expression optional, I've left it has mandatory simply to avoid lots of rework of the function (would need new null checks, memory handling would need reworking). So if you don't specify the xml_value, what does the xpath_expression get applied to? From what I can gather the xpath_expression would be evalutated against an empty document thereby returning false for every xpath_expression except for 'true()'. Apache Derby has made the xml_value mandatory as well (though I'll stress my conclusion wasn't based on this fact). If you think it would better to adhere more closely to the standard I can certainly look to do so. From a cursory glance at libxml's API I think it should be straight forward to query against an empty document such that I wouldn't need ot code for the exceptional case (or cases if I've missed others). Regards, -- Mike Fowler Registered Linux user: 379787 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why are these modules built without respecting my LDFLAGS?
On Sunday 27 June 2010 10:26:48 you wrote:
Aaron W. Swenson aaron.w.swen...@gmail.com writes:
I have a short list of modules that have been built without respecting my
LDFLAGS and/or LDFLAGS_SL.
It's difficult to comment on this since you haven't told us what flags
you wanted to inject, nor exactly how you tried to inject them, nor what
version of PG you're working with, nor what platform you're on. But
generally speaking I'd expect the values of those variables set by
configure to be used in linking all contrib modules.
regards, tom lane
Thank you for the quick response. I apologize for leaving out some pertinent
information.
OS = Gentoo Linux
CPU = AMD Athlon XP-M x86
LDFLAGS = -Wl,-O1,--hash-style=gnu
LDFLAGS_SL = ${LDFLAGS}
PgSQL = 8.4.4
LDFLAGS and LDFLAGS_SL are exported as environment variables that ./configure
does pick up, and pg_config confirms this. (pg_config also reveals that '--as-
needed' is tacked onto LDFLAGS, which isn't a problem.)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why are these modules built without respecting my LDFLAGS?
Aaron W. Swenson aaron.w.swen...@gmail.com writes: LDFLAGS and LDFLAGS_SL are exported as environment variables that ./configure does pick up, and pg_config confirms this. (pg_config also reveals that '--as- needed' is tacked onto LDFLAGS, which isn't a problem.) OK, so after some digging I find that, while most of the .so's in our build are made using Makefile.shlib, pgxs's MODULES build rules don't use that. Instead they rely on the %.so: %.o (and platform-specific variants of that) rules found in src/makefiles/Makefile*. And on most platforms we've neglected to include LDFLAGS_SL in those rules. This seems like an oversight, especially since the one platform that has nonempty LDFLAGS_SL by default (AIX) does include LDFLAGS_SL. This seems like a clear bug. I'm hesitant to back-patch a change like that, but not hesitant to fix it in HEAD. Another thing that I notice is that it's unclear whether a shared-library link should include LDFLAGS too, or only LDFLAGS_SL. On AIX we seem to include both of those flag sets (according to both Makefile.aix and Makefile.shlib) but most other platforms are not including LDFLAGS in shlib link commands. But Makefile.hpux is off in left field, as it includes LDFLAGS but not LDFLAGS_SL. Just to confuse matters even more, Makefile.shlib goes out of its way to pull -L switches (only) out of LDFLAGS and include those into shlib links. Should we try to make that a bit more consistent, and if so how? The shenanigans in Makefile.shlib would get a lot simpler if we said that shlib links always include LDFLAGS *plus* LDFLAGS_SL, but I would think that that would carry substantial risk of breakage. Surely there are cases where linker switches are appropriate for making executables but not shlibs. Perhaps we should set up three variables instead of two, viz LDFLAGS = switches for linking both executables and shlibs LDFLAGS_EX = extra switches for linking executables only LDFLAGS_SL = extra switches for linking shlibs only Then we could get rid of that untrustworthy hack for extracting -L switches ... 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] pg_dump's checkSeek() seems inadequate
On Sun, Jun 27, 2010 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: On Sun, Jun 27, 2010 at 1:42 PM, Tom Lane t...@sss.pgh.pa.us wrote: If I change the test to be fseeko(fp, 0, SEEK_SET) then it does the right thing. Well, I guess it depends on what you think the chances are that the revised test will fail on some other obscure platform. To believe that, you'd have to believe that fseeko(fp, 0, SEEK_SET) will fail but fseeko(fp, something-not-zero, SEEK_SET) will succeed. A somewhat more plausible scenario is that somebody might hope that they could do something like this: echo 'some custom header' pg.dump pg_dump -Fc pg.dump I believe that (at least on most Unixen) doing fseeko(fp, 0, SEEK_SET) would result in overwriting the custom header, where it would not have been overwritten before. However the usefulness of the above is at best far-fetched; and I'm not very sure that it works today anyway, since pg_dump/pg_restore seem to assume that manual byte counting should match the results of ftell(). That doesn't actually sound all that far-fetched. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] suppress automatic recovery after back crash
[moving from -performance to -hackers; original subject is: PostgreSQL as a local in-memory cache] On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Berkus j...@agliodbs.com writes: (a) and (d) are probably simple, if by reprovisioning you mean rm -rf $PGDATA; initdb. Exactly. Followed by scp database_image. Or heck, just replacing the whole VM. Right, that would work. I don't think you really need to implement that inside Postgres. I would envision having the startup script do it, ie rm -rf $PGDATA cp -pr prepared-database-image $PGDATA # this loop exits when postmaster exits normally while ! postmaster ... do rm -rf $PGDATA cp -pr prepared-database-image $PGDATA done Then all you need is a tweak to make the postmaster exit(1) after a crash instead of trying to launch recovery. This seems useful to me so here's a patch to implement it. There didn't seem to be a suitable GUC category for it, until I noticed that we have a currently-undocumented GUC called exit_on_error. I thought it might make sense to document both that and this in a new section called Error Handling. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company guc_automatic_restart.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: [HACKERS] pg_dump's checkSeek() seems inadequate
Robert Haas robertmh...@gmail.com writes: On Sun, Jun 27, 2010 at 6:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: A somewhat more plausible scenario is that somebody might hope that they could do something like this: echo 'some custom header' pg.dump pg_dump -Fc pg.dump That doesn't actually sound all that far-fetched. I've got my doubts, but I guess we could write an even-more-bulletproof test by doing ftello() and then seeing if fseeko to that position complains. This might be a good thing anyway since most of the other uses of ftello aren't really checking for errors ... 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] suppress automatic recovery after back crash
Robert Haas robertmh...@gmail.com writes: On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote: Then all you need is a tweak to make the postmaster exit(1) after a crash instead of trying to launch recovery. This seems useful to me so here's a patch to implement it. Hm, is it useful in the absence of the other components of the proposed feature? One stylistic gripe: @@ -80,6 +80,7 @@ enum config_group COMPAT_OPTIONS, COMPAT_OPTIONS_PREVIOUS, COMPAT_OPTIONS_CLIENT, + ERROR_HANDLING, PRESET_OPTIONS, CUSTOM_OPTIONS, DEVELOPER_OPTIONS Please spell that ERROR_HANDLING_OPTIONS, both for consistency with the other enum members and to avoid likely conflicts with other uses of such a generic-looking identifier. 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] pg_dump's checkSeek() seems inadequate
Tom Lane wrote: A somewhat more plausible scenario is that somebody might hope that they could do something like this: echo 'some custom header' pg.dump pg_dump -Fc pg.dump I believe that (at least on most Unixen) doing fseeko(fp, 0, SEEK_SET) would result in overwriting the custom header, where it would not have been overwritten before. However the usefulness of the above is at best far-fetched; and I'm not very sure that it works today anyway, since pg_dump/pg_restore seem to assume that manual byte counting should match the results of ftell(). What would anyone hope to achieve by such a manoeuvre, even if it worked, which I am close the dead sure it would not? 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] pg_dump's checkSeek() seems inadequate
Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: A somewhat more plausible scenario is that somebody might hope that they could do something like this: echo 'some custom header' pg.dump pg_dump -Fc pg.dump What would anyone hope to achieve by such a manoeuvre, even if it worked, which I am close the dead sure it would not? It looks to me like it probably would actually work, so far as pg_dump is concerned, but _discoverArchiveFormat() would break it because that tries to do an unconditional fseeko(fp, 0, SEEK_SET) (and the position counting is screwed up even if the fseeko fails). That could probably be fixed if anyone thought this scenario was interesting enough to justify work directed specifically at it. I did the ftello/fseeko dance in checkSeek() just now because it seems sensible to me to have checkSeek() actually verify functionality of both of those calls, not because I think it's real likely that the position won't be 0. 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] Why are these modules built without respecting my LDFLAGS?
On sön, 2010-06-27 at 19:41 -0400, Tom Lane wrote: OK, so after some digging I find that, while most of the .so's in our build are made using Makefile.shlib, pgxs's MODULES build rules don't use that. Instead they rely on the %.so: %.o (and platform-specific variants of that) rules found in src/makefiles/Makefile*. And on most platforms we've neglected to include LDFLAGS_SL in those rules. This seems like an oversight, especially since the one platform that has nonempty LDFLAGS_SL by default (AIX) does include LDFLAGS_SL. This seems like a clear bug. I'm hesitant to back-patch a change like that, but not hesitant to fix it in HEAD. I think this issue is brought up about once a year. You might want to review previous discussions. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
