Re: [PATCHES] Table function support
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Pavel Stehule wrote: > Hello > > this patch allows using SQL2003 syntax for set returning functions. It is > based on using new type of argmode - PROARGMODE_TABLE. > > Proposal: http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php > > Sample: > > CREATE FUNCTION foof(a int) > RETURNS TABLE(a int, b int) AS > $$ SELECT x, y FROM Foo WHERE x < a $$ LANGUAGE sql; > > CREATE FUNCTION fooff(a int) > RETURNS TABLE(a int, b int) AS $$ > BEGIN > RETURN TABLE(SELECT * FRON Foo WHERE x < a); > END; $$ LANGUAGE plpgsql; > > This patch enhance plpgsql stmt return too (table expression support). > > Conformance with SQL2003: > T326 Table functions > > Description: SIGMOD Record, Vol. 33, No. 1, March 2004 > > Regards > Pavel Stehule > > _ > Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. > http://messenger.msn.cz/ [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Re: [BUGS] BUG #2996: to_char( timestamp, 'DD-Mon-YYYY HH24:MI:SS.MS' ) reports .1000 ms
Nice test case. I did some research and realized that there is an incorrect use of rint() in the code. The problem is that you can't rint() if you can't overflow to the next units, and you can't rint() if you might need to print the lesser units. In this case, we hit both of those problems, so the fix is to remove rint() in the two places that have it. Notice before how the overflow to a full second happens: 16-Feb-2007 22:03:23. 999 999427 16-Feb-2007 22:03:23. 999 999461 16-Feb-2007 22:03:23. 999 999495 16-Feb-2007 22:03:23. 1000 999529 16-Feb-2007 22:03:23. 1000 999563 16-Feb-2007 22:03:23. 1000 999597 16-Feb-2007 22:03:23. 1000 999631 16-Feb-2007 22:03:23. 1000 999665 16-Feb-2007 22:03:23. 1000 999699 16-Feb-2007 22:03:23. 1000 999733 16-Feb-2007 22:03:23. 1000 999767 16-Feb-2007 22:03:23. 1000 999801 16-Feb-2007 22:03:23. 1000 999835 16-Feb-2007 22:03:23. 1000 999869 16-Feb-2007 22:03:23. 1000 03 16-Feb-2007 22:03:23. 1000 37 16-Feb-2007 22:03:23. 1000 71 16-Feb-2007 22:03:24. 000 06 16-Feb-2007 22:03:24. 000 39 16-Feb-2007 22:03:24. 000 72 and without rint(): 16-Feb-2007 21:55:04. 999 04 16-Feb-2007 21:55:04. 999 39 16-Feb-2007 21:55:04. 999 73 16-Feb-2007 21:55:05. 000 07 16-Feb-2007 21:55:05. 000 40 16-Feb-2007 21:55:05. 000 74 Patch attached and applied, with comment added about rint() removal. --- Anthony Taylor wrote: > > The following bug has been logged online: > > Bug reference: 2996 > Logged by: Anthony Taylor > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.8 > Operating system: Linux kernel 2.6.11 (based on Gentoo) > Description:to_char( timestamp, 'DD-Mon- HH24:MI:SS.MS' ) > reports .1000 ms > Details: > > When using the "to_char" function to output timestamps, some timestamps > report .1000 milliseconds. > > Specifically, > > select to_char( time, 'DD-Mon- HH24:MI:SS.MS' ) from test_time; > > Reports: > > 12-Feb-2007 18:16:34.999 > 12-Feb-2007 18:16:34.1000 > 12-Feb-2007 18:16:35.000 > > I believe the 34.1000 should either be 34.999 or 35.000. > > According to the documentation (table 9-21, Template Patterns for Date/Time > Formatting): > > MSmillisecond (000-999) > > Here's a nice little test script: > > -- > > CREATE TABLE test_time ( time TIMESTAMP ); > > CREATE OR REPLACE FUNCTION timetest( ) > RETURNS VOID > AS $$ > BEGIN > FOR i IN 0..10 LOOP > INSERT INTO test_time VALUES ( timeofday()::timestamp ); > END LOOP; > END; > $$ LANGUAGE plpgsql; > > SELECT timetest(); > > select to_char( time, 'DD-Mon- HH24:MI:SS.MS' ) from test_time; > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/backend/utils/adt/formatting.c === RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v retrieving revision 1.127 diff -c -c -r1.127 formatting.c *** src/backend/utils/adt/formatting.c 17 Feb 2007 01:51:42 - 1.127 --- src/backend/utils/adt/formatting.c 17 Feb 2007 03:09:43 - *** *** 2000,2006 #ifdef HAVE_INT64_TIMESTAMP sprintf(inout, "%03d", (int) (tmtc->fsec / INT64CONST(1000))); #else ! sprintf(inout, "%03d", (int) rint(tmtc->fsec * 1000)); #endif if (S_THth(suf)) str_numth(p_inout, inout, S_TH_TYPE(suf)); --- 2000,2007 #ifdef HAVE_INT64_TIMESTAMP sprintf(inout, "%03d", (int) (tmtc->fsec / INT64CONST(1000))); #else ! /* No rint() because we can't overflow and we might print US */ ! sprintf(inout, "%03d", (int) (tmtc->fsec * 1000)); #endif if (S_THth(suf)) str_numth(p_inout, inout, S_TH_TYPE(suf)); *** *** 2041,2047 #ifdef HAVE_INT64_TIMESTAMP sprintf(inout, "%06d", (int) tmtc->fsec); #else ! sprintf(inout, "%06d", (int) rint(tmtc->fsec * 100)); #endif if (S_THth(suf)) str_numth(p_inout, inout, S_TH_TYPE(suf)); --- 2042,2049 #ifdef HAVE_INT64_TIMESTAMP sprintf(inout, "%06d", (int) tmtc->fsec); #else ! /* don't use rint() because we can't overflow 1000 */ ! sprintf(inout, "%06d", (int) (tmtc->fsec * 100)); #endif if (S_THth(suf)) str_numth(p_inout, inout, S_TH_TYPE(suf)); ---(end of broadcast
Re: [PATCHES] [GENERAL] ISO week dates
Applied. --- Brendan Jurd wrote: > On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > Thanks for the clarification. Would you have a look at the tests as > > they are now and confirm that that's what you wanted? > > > > Yes, the tests in HEAD right now are what I wanted. Although, while I > was in there I did notice a minor thing (another copy-paste error): > the timestamptz test is using a column alias that's not consistent > with other tests in the vicinity. Patch attached. [ Attachment, skipping... ] -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [GENERAL] ISO week dates
On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote: Thanks for the clarification. Would you have a look at the tests as they are now and confirm that that's what you wanted? Yes, the tests in HEAD right now are what I wanted. Although, while I was in there I did notice a minor thing (another copy-paste error): the timestamptz test is using a column alias that's not consistent with other tests in the vicinity. Patch attached. iso_regress_fix.patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] \prompt for psql
Seems the consensus was this was a good idea, and not feature-creep. It needs SGML documentation, which I will add. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Chad Wagner wrote: > Anyways, here is the patch again with the pager output changed from 67 to > 69. Feel free to use it or ignore it, I still think it is a useful patch > and doesn't necessary imply that users will want looping next (although, I > would like to do anonymous PL/pgSQL chunks ;). I just understand how useful > internal variables are if you can't get input into them easily on all > platforms. [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Avg performance for int8/numeric
Patch applied. Thanks. --- Mark Kirkwood wrote: > Bruce Momjian wrote: > > I have tested this patch but it generates regression failures. > > > > There was some code drift, so I am attaching an updated version of the > > patch, and the regression diffs. The 'four' column is an 'int4' so my > > guess is that somehow the wrong aggregate is being called. > > > > Good catch - I must have neglected to run the regression test after > amending the number of array arguments for the numeric avg :-(. > > Hmmm - this changing the number of array args for avg means we can't mix > transition functions for variance with final functions for avg - which > is exactly what the regression suite does with the 'newavg' aggregate. > > I've 'fixed' this by amending the definition of 'newavg' to use the > transition and final function that 'avg' does. However I found myself > asking if this lost us the point of that test - so I looked back at the > older postgres versions (e.g. 7.1.3) and saw that back *then* 'newavg' > and 'avg' were defined using the same functions...so I think making the > change as indicated is ok. > > I've attached a new patch with this change. > > Cheers > > Mark -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [GENERAL] ISO week dates
Brendan Jurd escribió: > On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote: > >Yes, it was: you now have two duplicate tests in timestamp.sql, and > >no corresponding test in timestamptz.sql. It looks to me like the > >submitter intended to be testing timestamp_tbl in the former file > >and the same tests against timestamptz_tbl in the latter. Please > >recheck the diff and fix. > > > > Tom's right. Looking back at the patch, it was a simple coding error. > The test in timestamptz.sql should have been querying TIMESTAMPTZ_TBL > not TIMESTAMP_TBL. The intent was to run the same tests against both > timestamp and timestamptz. Thanks for the clarification. Would you have a look at the tests as they are now and confirm that that's what you wanted? > > I'll have a patch for proper handling of invalid formatting codes > soon. And I'll be sure to test it in every way I can find to do so. Great. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [GENERAL] ISO week dates
Brendan Jurd wrote: > On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote: > > Yes, it was: you now have two duplicate tests in timestamp.sql, and > > no corresponding test in timestamptz.sql. It looks to me like the > > submitter intended to be testing timestamp_tbl in the former file > > and the same tests against timestamptz_tbl in the latter. Please > > recheck the diff and fix. > > > > Tom's right. Looking back at the patch, it was a simple coding error. > The test in timestamptz.sql should have been querying TIMESTAMPTZ_TBL > not TIMESTAMP_TBL. The intent was to run the same tests against both > timestamp and timestamptz. > > Looks like I failed to run the parallel tests after my last round of > modifications, as Alvaro suggested. That was my bad. > > I'll have a patch for proper handling of invalid formatting codes > soon. And I'll be sure to test it in every way I can find to do so. Great. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Avg performance for int8/numeric
Mark Kirkwood wrote: > Bruce Momjian wrote: > > I have tested this patch but it generates regression failures. > > > > There was some code drift, so I am attaching an updated version of the > > patch, and the regression diffs. The 'four' column is an 'int4' so my > > guess is that somehow the wrong aggregate is being called. > > > > Good catch - I must have neglected to run the regression test after > amending the number of array arguments for the numeric avg :-(. > > Hmmm - this changing the number of array args for avg means we can't mix > transition functions for variance with final functions for avg - which > is exactly what the regression suite does with the 'newavg' aggregate. Yea, I was just looking at this and came to same conclusion. > I've 'fixed' this by amending the definition of 'newavg' to use the > transition and final function that 'avg' does. However I found myself > asking if this lost us the point of that test - so I looked back at the > older postgres versions (e.g. 7.1.3) and saw that back *then* 'newavg' > and 'avg' were defined using the same functions...so I think making the > change as indicated is ok. > > I've attached a new patch with this change. OK, great, will apply. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Avg performance for int8/numeric
Bruce Momjian wrote:
I have tested this patch but it generates regression failures.
There was some code drift, so I am attaching an updated version of the
patch, and the regression diffs. The 'four' column is an 'int4' so my
guess is that somehow the wrong aggregate is being called.
Good catch - I must have neglected to run the regression test after
amending the number of array arguments for the numeric avg :-(.
Hmmm - this changing the number of array args for avg means we can't mix
transition functions for variance with final functions for avg - which
is exactly what the regression suite does with the 'newavg' aggregate.
I've 'fixed' this by amending the definition of 'newavg' to use the
transition and final function that 'avg' does. However I found myself
asking if this lost us the point of that test - so I looked back at the
older postgres versions (e.g. 7.1.3) and saw that back *then* 'newavg'
and 'avg' were defined using the same functions...so I think making the
change as indicated is ok.
I've attached a new patch with this change.
Cheers
Mark
diff -Nacr pgsql.orig/src/backend/utils/adt/numeric.c pgsql/src/backend/utils/adt/numeric.c
*** pgsql.orig/src/backend/utils/adt/numeric.c Sun Jan 21 11:36:20 2007
--- pgsql/src/backend/utils/adt/numeric.c Fri Feb 16 18:09:24 2007
***
*** 2165,2170
--- 2165,2204
return result;
}
+ /*
+ * Improve avg performance by not caclulating sum(X*X).
+ */
+ static ArrayType *
+ do_numeric_avg_accum(ArrayType *transarray, Numeric newval)
+ {
+ Datum *transdatums;
+ int ndatums;
+ Datum N,
+ sumX;
+ ArrayType *result;
+
+ /* We assume the input is array of numeric */
+ deconstruct_array(transarray,
+ NUMERICOID, -1, false, 'i',
+ &transdatums, NULL, &ndatums);
+ if (ndatums != 2)
+ elog(ERROR, "expected 2-element numeric array");
+ N = transdatums[0];
+ sumX = transdatums[1];
+
+ N = DirectFunctionCall1(numeric_inc, N);
+ sumX = DirectFunctionCall2(numeric_add, sumX,
+ NumericGetDatum(newval));
+
+ transdatums[0] = N;
+ transdatums[1] = sumX;
+
+ result = construct_array(transdatums, 2,
+ NUMERICOID, -1, false, 'i');
+
+ return result;
+ }
+
Datum
numeric_accum(PG_FUNCTION_ARGS)
{
***
*** 2175,2180
--- 2209,2226
}
/*
+ * Optimized case for average of numeric.
+ */
+ Datum
+ numeric_avg_accum(PG_FUNCTION_ARGS)
+ {
+ ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
+ Numeric newval = PG_GETARG_NUMERIC(1);
+
+ PG_RETURN_ARRAYTYPE_P(do_numeric_avg_accum(transarray, newval));
+ }
+
+ /*
* Integer data types all use Numeric accumulators to share code and
* avoid risk of overflow. For int2 and int4 inputs, Numeric accumulation
* is overkill for the N and sum(X) values, but definitely not overkill
***
*** 2219,2224
--- 2265,2286
PG_RETURN_ARRAYTYPE_P(do_numeric_accum(transarray, newval));
}
+ /*
+ * Optimized case for average of int8.
+ */
+ Datum
+ int8_avg_accum(PG_FUNCTION_ARGS)
+ {
+ ArrayType *transarray = PG_GETARG_ARRAYTYPE_P(0);
+ Datum newval8 = PG_GETARG_DATUM(1);
+ Numeric newval;
+
+ newval = DatumGetNumeric(DirectFunctionCall1(int8_numeric, newval8));
+
+ PG_RETURN_ARRAYTYPE_P(do_numeric_avg_accum(transarray, newval));
+ }
+
+
Datum
numeric_avg(PG_FUNCTION_ARGS)
{
***
*** 2232,2242
deconstruct_array(transarray,
NUMERICOID, -1, false, 'i',
&transdatums, NULL, &ndatums);
! if (ndatums != 3)
! elog(ERROR, "expected 3-element numeric array");
N = DatumGetNumeric(transdatums[0]);
sumX = DatumGetNumeric(transdatums[1]);
- /* ignore sumX2 */
/* SQL92 defines AVG of no values to be NULL */
/* N is zero iff no digits (cf. numeric_uminus) */
--- 2294,2303
deconstruct_array(transarray,
NUMERICOID, -1, false, 'i',
&transdatums, NULL, &ndatums);
! if (ndatums != 2)
! elog(ERROR, "expected 2-element numeric array");
N = DatumGetNumeric(transdatums[0]);
sumX = DatumGetNumeric(transdatums[1]);
/* SQL92 defines AVG of no values to be NULL */
/* N is zero iff no digits (cf. numeric_uminus) */
diff -Nacr pgsql.orig/src/include/catalog/catversion.h pgsql/src/include/catalog/catversion.h
*** pgsql.orig/src/include/catalog/catversion.h Fri Feb 16 18:06:34 2007
--- pgsql/src/include/catalog/catversion.h Fri Feb 16 18:09:24 2007
***
*** 53,58
*/
/* mmddN */
! #define CATALOG_VERSION_NO 200702131
#endif
--- 53,58
*/
/* mmddN */
! #define CATALOG_VERSION_NO 200702151
#endif
diff -Nacr pgsql.orig/src/include/catalog/pg_aggregate.h pgsql/src/include/catalog/pg_aggregate.h
*** pgsql.orig/src/include/catalog/pg_aggregate.h Sun Jan 21 11:36:22 2007
--- pgsql/src/include/catalog/pg_aggregate.h Fri Feb 16 18:09:24 2007
***
*** 80,89
*/
/* avg */
! DATA(insert ( 2100 int8_accum numeric_avg
Re: [PATCHES] [GENERAL] ISO week dates
On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote: Yes, it was: you now have two duplicate tests in timestamp.sql, and no corresponding test in timestamptz.sql. It looks to me like the submitter intended to be testing timestamp_tbl in the former file and the same tests against timestamptz_tbl in the latter. Please recheck the diff and fix. Tom's right. Looking back at the patch, it was a simple coding error. The test in timestamptz.sql should have been querying TIMESTAMPTZ_TBL not TIMESTAMP_TBL. The intent was to run the same tests against both timestamp and timestamptz. Looks like I failed to run the parallel tests after my last round of modifications, as Alvaro suggested. That was my bad. I'll have a patch for proper handling of invalid formatting codes soon. And I'll be sure to test it in every way I can find to do so. BJ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] patch adding new regexp functions
On Fri, 16 Feb 2007, Peter Eisentraut wrote: > Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake: > > Does this version sufficiently address your concerns? > > I don't think anyone asked for the start position and length in the result of > regexp_split(). The result should be an array of text. That is what Perl et > al. do. The length is not returned, I simply call length() on the string result to make sure that no whitespace gets in. The start position was suggested in these two messages from Alvaro Herrera: http://archives.postgresql.org/pgsql-patches/2007-02/msg00276.php http://archives.postgresql.org/pgsql-patches/2007-02/msg00281.php This was meant to address your concern about the order not necessarily being preserved of the split results when being returned as SETOF. This gives the benefits of returning SETOF while still allowing the order to be preserved if desired (simply add ORDER BY startpos to guarantee the correct order). In case you haven't noticed, I am rather averse to making this return text[] because it is much easier in my experience to use the results when returned in SETOF rather than text[], and in all of the code that I have experience with where this would be useful I would end up using information_schema._pg_expandarray (a function that, AFAIK, is documented nowhere) to convert it into SETOF text. While, if you really really wanted a text[], you could use the (fully documented) ARRAY(select resultstr from regexp_split(...) order by startpos) construct. > As for the regexp_matches() function, it seems to me that it returns too much > information at once. What is the use case for getting all of prematch, > fullmatch, matches, and postmatch in one call? It was requested by David Fetter: http://archives.postgresql.org/pgsql-hackers/2007-02/msg00056.php It was not horribly difficult to provide, and it seemed reasonable to me. I have no need for them personally. -- Some people in this department wouldn't recognize subtlety if it hit them on the head. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] New features for pgbench
On 2/12/2007 11:43 AM, Tom Lane wrote: Greg Smith <[EMAIL PROTECTED]> writes: Right now when you run pgbench, the results vary considerably from run to run even if you completely rebuild the database every time. I've found that a lot of that variation comes from two things: This is a real issue, but I think your proposed patch does not fix it. A pgbench run will still be penalized according to the number of checkpoints or autovacuums that happen while it occurs. Guaranteeing that there's at least one is maybe a bit more fair than allowing the possibility of having none, but it's hardly a complete fix. Also, this approach means that short test runs will have artificially lower TPS results than longer ones, because the fixed part of the maintenance overhead is amortized over fewer transactions. Anything that doesn't run exclusively on the server, is given enough data in size and enough time to similarly populate the buffer cache for each run, WILL report more or less random TPS results. Real benchmarks on considerable sized hardware have ramp-up times that are measured in hours if not days, with the sole purpose of populating the cache and thus smoothing out the transaction response profile. I think this change is an entirely misleading approach to tackle the problem at hand. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [PATCHES] pg_standby
Robert Treat wrote:
> At the risk of starting trouble, is there some reason this was added to
> contrib and not put on pgfoundry ?
I thought the idea was that it was integral to using PITR, but might
change so it was put in /contrib.
>
> On Thursday 08 February 2007 10:09, Bruce Momjian wrote:
> > Patch applied. Thanks.
> >
> > ---
> >
> > Simon Riggs wrote:
> > > On Wed, 2007-01-17 at 16:15 +, Simon Riggs wrote:
> > > > On Wed, 2007-01-17 at 10:05 -0500, Merlin Moncure wrote:
> > > > > On 12/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > > > > > On Thu, 2006-12-28 at 19:26 +, Simon Riggs wrote:
> > > > > > > On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote:
> > > > > > > > pg_standby and test framework, in separate .tar files
> > > > > > >
> > > > > > > New version (v2), following further testing.
> > > > > > >
> > > > > > > Signal handling not included in this version.
> > > > > >
> > > > > > Signal handling now added, tested and working correctly in version
> > > > > > 3, attached.
> > > > > >
> > > > > > pg_standby is an example program for a warm standby script as
> > > > > > discussed on -hackers:
> > > > > > http://archives.postgresql.org/pgsql-hackers/2006-08/msg00407.php
> > > > > >
> > > > > > Program looks complete and ready for review, to me.
> > > > >
> > > > > I double checked and re-ran all my test and confirmed that pg_standby
> > > > > move (-m) mode is definitely busted in v3 in the sense that a restart
> > > > > of the standby will not resume recovery and requires a pg_resetxlog
> > > > > to become operational -- it needs one more WAL file back than the
> > > > > oldest one available.
> > > >
> > > > new v4
> > > >
> > > > Changes
> > > > - removed -m command, design flaw in original spec, use -l instead
> > > > - added -k N command to cleanup archive and leave max N files
> > > > - fflush() points added to allow Windows debug
> > > > - bug fix: when .history file present
> > > > - bug fix: command line switch cleanup
> > > > - readme updated
> > >
> > > new v6 (v5 was Windows dev release)
> > >
> > > Changes
> > >
> > > - added -r option to specify maxretries
> > > - -l option for Windows Vista (only) using mklink
> > > - Windows examples and docs added to readme
> > > - code restructured to allow more easy customization
> > > - bug fix: -k 0 error fixed
> > >
> > > - successful port report from Dave Page on Windows XP
> > >
> > > --
> > > Simon Riggs
> > > EnterpriseDB http://www.enterprisedb.com
> >
> > [ Attachment, skipping... ]
> >
> > > ---(end of broadcast)---
> > > TIP 1: if posting/reading through Usenet, please send an appropriate
> > >subscribe-nomail command to [EMAIL PROTECTED] so that your
> > >message can get through to the mailing list cleanly
>
> --
> Robert Treat
> Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
>
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [PATCHES] pg_standby
At the risk of starting trouble, is there some reason this was added to
contrib and not put on pgfoundry ?
On Thursday 08 February 2007 10:09, Bruce Momjian wrote:
> Patch applied. Thanks.
>
> ---
>
> Simon Riggs wrote:
> > On Wed, 2007-01-17 at 16:15 +, Simon Riggs wrote:
> > > On Wed, 2007-01-17 at 10:05 -0500, Merlin Moncure wrote:
> > > > On 12/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > > > > On Thu, 2006-12-28 at 19:26 +, Simon Riggs wrote:
> > > > > > On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote:
> > > > > > > pg_standby and test framework, in separate .tar files
> > > > > >
> > > > > > New version (v2), following further testing.
> > > > > >
> > > > > > Signal handling not included in this version.
> > > > >
> > > > > Signal handling now added, tested and working correctly in version
> > > > > 3, attached.
> > > > >
> > > > > pg_standby is an example program for a warm standby script as
> > > > > discussed on -hackers:
> > > > > http://archives.postgresql.org/pgsql-hackers/2006-08/msg00407.php
> > > > >
> > > > > Program looks complete and ready for review, to me.
> > > >
> > > > I double checked and re-ran all my test and confirmed that pg_standby
> > > > move (-m) mode is definitely busted in v3 in the sense that a restart
> > > > of the standby will not resume recovery and requires a pg_resetxlog
> > > > to become operational -- it needs one more WAL file back than the
> > > > oldest one available.
> > >
> > > new v4
> > >
> > > Changes
> > > - removed -m command, design flaw in original spec, use -l instead
> > > - added -k N command to cleanup archive and leave max N files
> > > - fflush() points added to allow Windows debug
> > > - bug fix: when .history file present
> > > - bug fix: command line switch cleanup
> > > - readme updated
> >
> > new v6 (v5 was Windows dev release)
> >
> > Changes
> >
> > - added -r option to specify maxretries
> > - -l option for Windows Vista (only) using mklink
> > - Windows examples and docs added to readme
> > - code restructured to allow more easy customization
> > - bug fix: -k 0 error fixed
> >
> > - successful port report from Dave Page on Windows XP
> >
> > --
> > Simon Riggs
> > EnterpriseDB http://www.enterprisedb.com
>
> [ Attachment, skipping... ]
>
> > ---(end of broadcast)---
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> >subscribe-nomail command to [EMAIL PROTECTED] so that your
> >message can get through to the mailing list cleanly
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Another aspect of set_ps_display ()
Applied.
---
Bruce Momjian wrote:
>
> I did some research on this item from October, 2006. I was struck by
> the memset of 2344 for every proc title change on popular platforms like
> Linux.
>
> The attached patch reduces the memset to only span the length needed
> since the last title change. This should significantly reduce the proc
> title overhead.
>
> Now that we are using strlcpy(), we still need this code because
> strlcpy() doesn't span the entire buffer if not needed, and sometimes
> the clobber character is a space, rather than a zero byte.
>
> ---
>
> Strong, David wrote:
> > We were just analyzing some more OProfile and ltrace data against
> > Postgres 8.2Beta1 and we noticed a number of calls as follows:
> >
> >
> > strlen("postgres: tpc tpc 192.168.1.200("...)= 58
> > memset(0xb6b2, '\000', 2344) = 0xb6b2
> >
> >
> > We have tracked this down to the following code in the set_ps_display ()
> > function:
> >
> >
> > #ifdef PS_USE_CLOBBER_ARGV
> > {
> > int buflen;
> >
> > /* pad unused memory */
> > buflen = strlen(ps_buffer);
> > MemSet(ps_buffer + buflen, PS_PADDING, ps_buffer_size - buflen);
> > }
> > #endif /* PS_USE_CLOBBER_ARGV */
> >
> >
> > If set_ps_display () moves to use the strlcpy () function call, this
> > code might be redundant. Even if the StrNCpy () call is kept, this code
> > may still be redundant as StrNCpy () will zero fill the ps_buffer.
> >
> > A MemSet () call on the ps_buffer has to be added to the init_ps_display
> > () function, if this code is removed to clear the buffer before use.
> >
> > David
> >
> > ---(end of broadcast)---
> > TIP 2: Don't 'kill -9' the postmaster
>
> --
> Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---(end of broadcast)---
> TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [PATCHES] patch adding new regexp functions
On Fri, Feb 16, 2007 at 01:03:32PM -0500, Andrew Dunstan wrote: > David Fetter wrote: > >> > >>The question is, what is the use case? If there is one in Perl, can > >>this proposed function API support it? > >> > > > >Perl makes the following variables available in any regex match, > >although it optimizes some cases for when they're not there: > > > >$1, ... $n (captured matches in parentheses) > >$` (pre-match) > >$' (post-match) > >$& (whole match) > > > > Use of any of these is notoriously costly, BTW, especially pre-match > and post-match. See perlre man page. This is why they only appear when called for :) Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] patch adding new regexp functions
David Fetter wrote: > > The question is, what is the use case? If there is one in Perl, > > can this proposed function API support it? > > Perl makes the following variables available in any regex match, That is not a use case. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] patch adding new regexp functions
David Fetter wrote: The question is, what is the use case? If there is one in Perl, can this proposed function API support it? Perl makes the following variables available in any regex match, although it optimizes some cases for when they're not there: $1, ... $n (captured matches in parentheses) $` (pre-match) $' (post-match) $& (whole match) Use of any of these is notoriously costly, BTW, especially pre-match and post-match. See perlre man page. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] patch adding new regexp functions
On Fri, Feb 16, 2007 at 05:54:47PM +0100, Peter Eisentraut wrote: > Am Freitag, 16. Februar 2007 17:11 schrieb David Fetter: > > > As for the regexp_matches() function, it seems to me that it > > > returns too much information at once. What is the use case for > > > getting all of prematch, fullmatch, matches, and postmatch in > > > one call? > > > > If not in one call, how would you get it? Perl, for example, > > makes these available to any regex match in the form of variables > > it sets. > > The question is, what is the use case? If there is one in Perl, can > this proposed function API support it? Perl makes the following variables available in any regex match, although it optimizes some cases for when they're not there: $1, ... $n (captured matches in parentheses) $` (pre-match) $' (post-match) $& (whole match) Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [GENERAL] ISO week dates
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Andrew Dunstan escribió: >> Well, the first question is "which table should these tests actually be >> using, and why?" Then they can be changed or moved as appropriate. > I just committed my patch before reading this comment. Maybe it was > rushed. Yes, it was: you now have two duplicate tests in timestamp.sql, and no corresponding test in timestamptz.sql. It looks to me like the submitter intended to be testing timestamp_tbl in the former file and the same tests against timestamptz_tbl in the latter. Please recheck the diff and fix. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] patch adding new regexp functions
Am Freitag, 16. Februar 2007 17:11 schrieb David Fetter: > > As for the regexp_matches() function, it seems to me that it returns > > too much information at once. What is the use case for getting all > > of prematch, fullmatch, matches, and postmatch in one call? > > If not in one call, how would you get it? Perl, for example, makes > these available to any regex match in the form of variables it sets. The question is, what is the use case? If there is one in Perl, can this proposed function API support it? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [GENERAL] ISO week dates
Alvaro Herrera wrote:
> > > > The same situation can arise if the user mixes ISO and Gregorian data;
> > > > how should Postgres deal with something like to_date('2006-250',
> > > > 'IYYY-DDD')? The current behaviour in my patch is actually to assume
> > > > that the user meant to say 'IYYY-IDDD', since "the 250th Gregorian day
> > > > of the ISO year 2006" is total gibberish. But perhaps it should be
> > > > throwing an error message.
>
> My thinking is that erroneous patterns should throw an error, and not
> try to second-guess the user. (IIRC this was being discussed in some
> other thread not long ago).
The author is working to consistently throw an error for all invalid
patterns. Right now, the patch just tries to do its best, which is
unfortunately consistent with what the rest of the code currently does.
:-)
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] patch adding new regexp functions
On Fri, Feb 16, 2007 at 01:19:55PM +0100, Peter Eisentraut wrote: > Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake: > > On Thu, 15 Feb 2007, Peter Eisentraut wrote: > > > I have no strong opinion about how matches are returned. Seeing > > > the definitional difficulties that you point out, it may be fine > > > to return them unordered. But then all "matches" functions > > > should do that. > > > > > > For the "split" functions, however, providing the order is > > > clearly important. > > > > Does this version sufficiently address your concerns? > > I don't think anyone asked for the start position and length in the > result of regexp_split(). The result should be an array of text. > That is what Perl et al. do. > > As for the regexp_matches() function, it seems to me that it returns > too much information at once. What is the use case for getting all > of prematch, fullmatch, matches, and postmatch in one call? If not in one call, how would you get it? Perl, for example, makes these available to any regex match in the form of variables it sets. Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [GENERAL] ISO week dates
Bruce Momjian escribió:
Maybe now would be an appropriate time to discuss the open questions in
the submitting email:
> > Brendan Jurd wrote:
> > > I have tried to implement these features with as little disruption to
> > > the existing code as possible. I built on the existing date2iso*
> > > functions in src/backend/utils/adt/timestamp.c, and added a few
> > > functions of my own, but I wonder if these functions would be more
> > > appropriately located in datetime.c, alongside date2j and j2date?
> > >
> > > I'd also like to raise the topic of how conversion from text to ISO
> > > week dates should be handled, where the user has specified a bogus
> > > mixture of fields. Existing code basically ignores these issues; for
> > > example, if a user were to call to_date('1998-01-01 2454050',
> > > '-MM-DD J') the function returns 2006-01-01, a result of setting
> > > the year field from , then overwriting year, month and day with
> > > the values from the Julian date in J, then setting the month and day
> > > normally from MM and DD.
> > >
> > > 2006-01-01 is not a valid representation of either of the values the
> > > user specified. Now you might say "ask a silly question, get a silly
> > > answer"; the user shouldn't send nonsense arguments to to_date and
> > > expect a sensible result. But perhaps the right way to respond to a
> > > broken timestamp definition is to throw an error, rather than behave
> > > as though everything has gone to plan, and return something which is
> > > not correct.
> > >
> > > The same situation can arise if the user mixes ISO and Gregorian data;
> > > how should Postgres deal with something like to_date('2006-250',
> > > 'IYYY-DDD')? The current behaviour in my patch is actually to assume
> > > that the user meant to say 'IYYY-IDDD', since "the 250th Gregorian day
> > > of the ISO year 2006" is total gibberish. But perhaps it should be
> > > throwing an error message.
My thinking is that erroneous patterns should throw an error, and not
try to second-guess the user. (IIRC this was being discussed in some
other thread not long ago).
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [GENERAL] ISO week dates
Andrew Dunstan escribió: > Alvaro Herrera wrote: > >Bruce Momjian escribió: > > > >>Alvaro Herrera wrote: > >> > >>>Andrew Dunstan escribi?: > >>> > >>> > Looks to me like the timestamptz test relies on the timestamp test (for > timestamp_tbl) but they are set to run in parallel, so we have a race > condition. Oops! > > >>>Good catch :-) > >>> > >>>I'd guess the answer is to move the tests using the timestamp_tbl to the > >>>timestamp test. > >>> > >>OK, will do. Thanks for the diagnosis. > >> > > > >Actually I have a patch ready for it. > > > > > > Well, the first question is "which table should these tests actually be > using, and why?" Then they can be changed or moved as appropriate. I just committed my patch before reading this comment. Maybe it was rushed. On the other hand, my thinking was that the submitter used the serial schedule to test, so he wouldn't catch the problem because the timestamp test comes before the timestamptz test and so there's no race condition there. My conclusion would be that he intended to use the timestamp_tbl table because that's what he did and it worked for him. However, he did change one test from using the timestamptz_tbl into using timestamp_tbl (and changed the to_char format in the process); I fixed that by putting the new format in the timestamp test, and restoring the original in timestamptz. Lesson for today would be to make sure to run both the serial and the parallel tests, several times, and that they both pass ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] WIP patch - INSERT-able log statements
FAST PostgreSQL wrote: > On Fri, 16 Feb 2007 11:50, Tom Lane wrote: >> "FAST PostgreSQL" <[EMAIL PROTECTED]> writes: >>> The second variable is of interest. We need to specify a table in the >>> insert command. My preferred option is for the user to give one and he >>> can create it if and when he wants to. The alternative is we decide the >>> table name and make initdb to create one. >> Why not output the data in COPY format instead? That (a) eliminates the >> problem of needing to predetermine a destination table name, and (b) >> should be considerably faster to load than thousands of INSERT statements. > > Yeah, that was my initial idea too... But because the TODO item clearly > mentions INSERT, I thought maybe there was some very specific reason for the > output to be in INSERT stmts.. .. COPY would be a good option, but INSERT is probably what I would use as the default. The most use I see for this is something where I am tailing out the log and inserting live into a log db... Sincerely, Joshua D. Drake > > Rgds, > Arul Shaji > > > >> regards, tom lane > This is an email from Fujitsu Australia Software Technology Pty Ltd, ABN 27 > 003 693 481. It is confidential to the ordinary user of the email address to > which it was addressed and may contain copyright and/or legally privileged > information. No one else may read, print, store, copy or forward all or any > of it or its attachments. If you receive this email in error, please return > to sender. Thank you. > > If you do not wish to receive commercial email messages from Fujitsu > Australia Software Technology Pty Ltd, please email [EMAIL PROTECTED] > > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [GENERAL] ISO week dates
Alvaro Herrera wrote: > Bruce Momjian escribi?: > > Alvaro Herrera wrote: > > > Andrew Dunstan escribi?: > > > > > > > Looks to me like the timestamptz test relies on the timestamp test (for > > > > timestamp_tbl) but they are set to run in parallel, so we have a race > > > > condition. Oops! > > > > > > Good catch :-) > > > > > > I'd guess the answer is to move the tests using the timestamp_tbl to the > > > timestamp test. > > > > OK, will do. Thanks for the diagnosis. > > Actually I have a patch ready for it. OK, thanks, I will not do anything. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [GENERAL] ISO week dates
Alvaro Herrera wrote: Bruce Momjian escribió: Alvaro Herrera wrote: Andrew Dunstan escribi?: Looks to me like the timestamptz test relies on the timestamp test (for timestamp_tbl) but they are set to run in parallel, so we have a race condition. Oops! Good catch :-) I'd guess the answer is to move the tests using the timestamp_tbl to the timestamp test. OK, will do. Thanks for the diagnosis. Actually I have a patch ready for it. Well, the first question is "which table should these tests actually be using, and why?" Then they can be changed or moved as appropriate. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [GENERAL] ISO week dates
Bruce Momjian escribió: > Alvaro Herrera wrote: > > Andrew Dunstan escribi?: > > > > > Looks to me like the timestamptz test relies on the timestamp test (for > > > timestamp_tbl) but they are set to run in parallel, so we have a race > > > condition. Oops! > > > > Good catch :-) > > > > I'd guess the answer is to move the tests using the timestamp_tbl to the > > timestamp test. > > OK, will do. Thanks for the diagnosis. Actually I have a patch ready for it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [GENERAL] ISO week dates
Alvaro Herrera wrote: > Andrew Dunstan escribi?: > > > Looks to me like the timestamptz test relies on the timestamp test (for > > timestamp_tbl) but they are set to run in parallel, so we have a race > > condition. Oops! > > Good catch :-) > > I'd guess the answer is to move the tests using the timestamp_tbl to the > timestamp test. OK, will do. Thanks for the diagnosis. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [GENERAL] ISO week dates
Andrew Dunstan escribió: > Looks to me like the timestamptz test relies on the timestamp test (for > timestamp_tbl) but they are set to run in parallel, so we have a race > condition. Oops! Good catch :-) I'd guess the answer is to move the tests using the timestamp_tbl to the timestamp test. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [GENERAL] ISO week dates
Alvaro Herrera wrote: Bruce Momjian escribió: Followup --- something weird is going on. I am seeing _random_ failures of the regression tests here in that same place, and the build farm seems to fail in the same place, but with different row counts. This failure is pretty interesting: --- 724,730 date_part( 'isoyear', d1) AS isoyear, date_part( 'week', d1) AS week, date_part( 'dow', d1) AS dow FROM TIMESTAMP_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01'; ! ERROR: relation "timestamp_tbl" does not exist -- TO_CHAR() SELECT '' AS to_char_1, to_char(d1, 'DAY Day day DY Dy dy MONTH Month month RM MON Mon mon') FROM TIMESTAMPTZ_TBL; http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=agouti&dt=2007-02-16%2005:15:01 How can the table fail to exist, and yet not report a problem when it was created? Looks to me like the timestamptz test relies on the timestamp test (for timestamp_tbl) but they are set to run in parallel, so we have a race condition. Oops! cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] patch adding new regexp functions
Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake: > On Thu, 15 Feb 2007, Peter Eisentraut wrote: > > I have no strong opinion about how matches are returned. Seeing the > > definitional difficulties that you point out, it may be fine to return > > them unordered. But then all "matches" functions should do that. > > > > For the "split" functions, however, providing the order is clearly > > important. > > Does this version sufficiently address your concerns? I don't think anyone asked for the start position and length in the result of regexp_split(). The result should be an array of text. That is what Perl et al. do. As for the regexp_matches() function, it seems to me that it returns too much information at once. What is the use case for getting all of prematch, fullmatch, matches, and postmatch in one call? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[PATCHES] further bootstrap cleanup
Here is a patch further cleaning up dummy process startup and the
bootstrap code itself a little.
I've tested it manually giving erroneous input and it behaves in the
same ways as the original. Of course, it still manages to bootstrap
normally and passes regression tests.
This patches removes a BOOTSTRAP_INCLUDE symbol from tcopprot.h, since
it seems to be useless. It is about trying to avoid getting prototypes
for functions not needed in bootstrap, presumably because at some point
the bootstrap.c file did not have enough includes to be able to compile
those definitions cleanly, or maybe because it had conflicting
definitions. But it now works without that.
I also took the liberty of renaming "xlog operation" into "dummy process
type", since that's what really the things are. I assume it was named
"xlog operation" back when the xlog code was written with the idea of
extending it into different xlog ops. But we haven't had any.
I think this is as far as I'll go with cleaning up this code in this
round. Task for some other janitor ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/bootstrap/bootparse.y
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/bootstrap/bootparse.y,v
retrieving revision 1.86
diff -c -p -r1.86 bootparse.y
*** src/backend/bootstrap/bootparse.y 9 Jan 2007 02:14:11 - 1.86
--- src/backend/bootstrap/bootparse.y 16 Feb 2007 04:23:28 -
*** Boot_InsertStmt:
*** 235,244
elog(ERROR, "incorrect number of columns in row (expected %d, got %d)",
numattr, num_columns_read);
if (boot_reldesc == NULL)
! {
! elog(ERROR, "relation not open");
! err_out();
! }
InsertOneTuple($2);
do_end();
}
--- 235,241
elog(ERROR, "incorrect number of columns in row (expected %d, got %d)",
numattr, num_columns_read);
if (boot_reldesc == NULL)
! elog(FATAL, "relation not open");
InsertOneTuple($2);
do_end();
}
Index: src/backend/bootstrap/bootstrap.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/bootstrap/bootstrap.c,v
retrieving revision 1.232
diff -c -p -r1.232 bootstrap.c
*** src/backend/bootstrap/bootstrap.c 16 Feb 2007 02:10:07 - 1.232
--- src/backend/bootstrap/bootstrap.c 16 Feb 2007 04:54:30 -
***
*** 20,27
#include
#endif
- #define BOOTSTRAP_INCLUDE /* mask out stuff in tcop/tcopprot.h */
-
#include "access/genam.h"
#include "access/heapam.h"
#include "access/xact.h"
--- 20,25
*** extern char *optarg;
*** 48,53
--- 46,53
#define ALLOC(t, c) ((t *) calloc((unsigned)(c), sizeof(t)))
+ static void CheckerModeMain(void);
+ static void BootstrapModeMain(void);
static void bootstrap_signals(void);
static void ShutdownDummyProcess(int code, Datum arg);
static hashnode *AddStr(char *str, int strlength, int mderef);
*** static Form_pg_attribute AllocateAttribu
*** 55,61
static int CompHash(char *str, int len);
static hashnode *FindStr(char *str, int length, hashnode *mderef);
static Oid gettype(char *type);
- static void cleanup(void);
/*
* global variables
--- 55,60
*** struct typmap
*** 166,172
static struct typmap **Typ = NULL;
static struct typmap *Ap = NULL;
- static int Warnings = 0;
static char Blanks[MAXATTR];
Form_pg_attribute attrtypes[MAXATTR]; /* points to attribute info */
--- 165,170
*** static IndexList *ILHead = NULL;
*** 193,215
/*
! * The main entry point for running the backend in bootstrap mode
*
! * The bootstrap mode is used to initialize the template database.
! * The bootstrap backend doesn't speak SQL, but instead expects
! * commands in a special bootstrap language.
*
! * For historical reasons, BootstrapMain is also used as the control
! * routine for non-backend subprocesses launched by the postmaster,
! * such as startup and shutdown.
*/
! int
! BootstrapMain(int argc, char *argv[])
{
char *progname = argv[0];
- int i;
int flag;
! int xlogop = BS_XLOG_NOP;
char *userDoption = NULL;
/*
--- 191,209
/*
! * DummyProcessMain
*
! * The main entry point for dummy (non-backend) processes, such as the
! * bgwriter, bootstrapper and the shared memory checker code.
*
! * This code is here just because of historical reasons.
*/
! void
! DummyProcessMain(int argc, char *argv[])
{
char *progname = argv[0];
int flag;
! DummyProcType dummyType = CheckerProcess;
char *userDoption = NULL;
/*
*** BootstrapMain(int argc, char *argv[])
*** 278,284
strlcpy(OutputFileName, optarg, MAXPGPATH);
Re: [PATCHES] [GENERAL] ISO week dates
Bruce Momjian escribió: > > Followup --- something weird is going on. I am seeing _random_ failures > of the regression tests here in that same place, and the build farm > seems to fail in the same place, but with different row counts. This failure is pretty interesting: --- 724,730 date_part( 'isoyear', d1) AS isoyear, date_part( 'week', d1) AS week, date_part( 'dow', d1) AS dow FROM TIMESTAMP_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01'; ! ERROR: relation "timestamp_tbl" does not exist -- TO_CHAR() SELECT '' AS to_char_1, to_char(d1, 'DAY Day day DY Dy dy MONTH Month month RM MON Mon mon') FROM TIMESTAMPTZ_TBL; http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=agouti&dt=2007-02-16%2005:15:01 How can the table fail to exist, and yet not report a problem when it was created? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] further bootstrap cleanup
[reposting with gzipped patch] Here is a patch further cleaning up dummy process startup and the bootstrap code itself a little. I've tested it manually giving erroneous input and it behaves in the same ways as the original. Of course, it still manages to bootstrap normally and passes regression tests. This patches removes a BOOTSTRAP_INCLUDE symbol from tcopprot.h, since it seems to be useless. It is about trying to avoid getting prototypes for functions not needed in bootstrap, presumably because at some point the bootstrap.c file did not have enough includes to be able to compile those definitions cleanly, or maybe because it had conflicting definitions. But it now works without that. I also took the liberty of renaming "xlog operation" into "dummy process type", since that's what really the things are. I assume it was named "xlog operation" back when the xlog code was written with the idea of extending it into different xlog ops. But we haven't had any. I think this is as far as I'll go with cleaning up this code in this round. Task for some other janitor ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. bootstrap-cleanup.patch.gz Description: Binary data ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
