[PATCHES] Cleanup to procarray.c
I have applied the following cleanup to procarray.c.
--
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/storage/ipc/procarray.c
===
RCS file: /cvsroot/pgsql/src/backend/storage/ipc/procarray.c,v
retrieving revision 1.21
diff -c -c -r1.21 procarray.c
*** src/backend/storage/ipc/procarray.c 16 Jan 2007 13:28:56 - 1.21
--- src/backend/storage/ipc/procarray.c 23 Mar 2007 03:14:10 -
***
*** 590,595
--- 590,600
xmax = ReadNewTransactionId();
+ /*
+ * Spin over procArray checking xid, xmin, and subxids. The goal is
+ * to gather all active xids, find the lowest xmin, and try to record
+ * subxids.
+ */
for (index = 0; index < arrayP->numProcs; index++)
{
PGPROC *proc = arrayP->procs[index];
***
*** 614,621
if (TransactionIdPrecedes(xid, xmin))
xmin = xid;
! snapshot->xip[count] = xid;
! count++;
/* Update globalxmin to be the smallest valid xmin */
xid = proc->xmin;
--- 619,625
if (TransactionIdPrecedes(xid, xmin))
xmin = xid;
! snapshot->xip[count++] = xid;
/* Update globalxmin to be the smallest valid xmin */
xid = proc->xmin;
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Fix pg_wchar_tbl.maxmblen
ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
> I found wrong definitions of max bytes for a char in
> EUC_CN (3->2), EUC_TW (3->4) and MULE_INTERNAL (3->4).
Also, the length of a char in GB18030 could be 4,
though GB18030 is not supported as a server encoding.
- {0, pg_gb18030_mblen, pg_gb18030_dsplen, pg_gb18030_verifier, 2}
/* 37; PG_GB18030 */
+ {0, pg_gb18030_mblen, pg_gb18030_dsplen, pg_gb18030_verifier, 4}
/* 37; PG_GB18030 */
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
[PATCHES] Fix pg_wchar_tbl.maxmblen
Hello,
I found wrong definitions of max bytes for a char in
EUC_CN (3->2), EUC_TW (3->4) and MULE_INTERNAL (3->4).
Especially, EUC_TW and MULE_INTERNAL might cause problems.
Their pg_*_mblen could have returned values larger than their maxmblen.
I'm worrying that it leads buffer overrun.
Index: src/backend/utils/mb/wchar.c
===
--- src/backend/utils/mb/wchar.c(head)
+++ src/backend/utils/mb/wchar.c(working copy)
@@ -1314,12 +1314,12 @@
pg_wchar_tbl pg_wchar_table[] = {
{pg_ascii2wchar_with_len, pg_ascii_mblen, pg_ascii_dsplen,
pg_ascii_verifier, 1}, /* 0; PG_SQL_ASCII */
{pg_eucjp2wchar_with_len, pg_eucjp_mblen, pg_eucjp_dsplen,
pg_eucjp_verifier, 3}, /* 1; PG_EUC_JP */
- {pg_euccn2wchar_with_len, pg_euccn_mblen, pg_euccn_dsplen,
pg_euccn_verifier, 3}, /* 2; PG_EUC_CN */
+ {pg_euccn2wchar_with_len, pg_euccn_mblen, pg_euccn_dsplen,
pg_euccn_verifier, 2}, /* 2; PG_EUC_CN */
{pg_euckr2wchar_with_len, pg_euckr_mblen, pg_euckr_dsplen,
pg_euckr_verifier, 3}, /* 3; PG_EUC_KR */
- {pg_euctw2wchar_with_len, pg_euctw_mblen, pg_euctw_dsplen,
pg_euctw_verifier, 3}, /* 4; PG_EUC_TW */
+ {pg_euctw2wchar_with_len, pg_euctw_mblen, pg_euctw_dsplen,
pg_euctw_verifier, 4}, /* 4; PG_EUC_TW */
{pg_johab2wchar_with_len, pg_johab_mblen, pg_johab_dsplen,
pg_johab_verifier, 3}, /* 5; PG_JOHAB */
{pg_utf2wchar_with_len, pg_utf_mblen, pg_utf_dsplen, pg_utf8_verifier,
4}, /* 6; PG_UTF8 */
- {pg_mule2wchar_with_len, pg_mule_mblen, pg_mule_dsplen,
pg_mule_verifier, 3}, /* 7; PG_MULE_INTERNAL */
+ {pg_mule2wchar_with_len, pg_mule_mblen, pg_mule_dsplen,
pg_mule_verifier, 4}, /* 7; PG_MULE_INTERNAL */
{pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen,
pg_latin1_verifier, 1}, /* 8; PG_LATIN1 */
{pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen,
pg_latin1_verifier, 1}, /* 9; PG_LATIN2 */
{pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen,
pg_latin1_verifier, 1}, /* 10; PG_LATIN3 */
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
[PATCHES] Load distributed checkpoint V3
Folks, Here is the latest version of Load distributed checkpoint patch. I've fixed some bugs, including in cases of missing file errors and overlapping of asynchronous checkpoint requests. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center checkpoint_v3.patch.gz Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Peter Eisentraut wrote: > Mike Rylander wrote: >> A related question, however: Will the XML features being included in >> 8.3 support namespace prefix registration? > > That is certainly the plan. Let me bounce my ostrich (sp?) head up here and say, thanks for your work on this Peter. Joshua D. Drake -- === 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 2: Don't 'kill -9' the postmaster
Re: [PATCHES] guc patch: Make variables fall back to default values
On Thu, Mar 22, 2007 at 04:58:09PM -0400, Bruce Momjian wrote: > Is there a new version of this patch being worked on? Yes, I will submit a new version next week. Joachim ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Mike Rylander wrote: > A related question, however: Will the XML features being included in > 8.3 support namespace prefix registration? That is certainly the plan. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Heap page diagnostic/test functions (v2)
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. --- Simon Riggs wrote: > On Thu, 2007-03-08 at 15:44 +, Simon Riggs wrote: > > > Docs included > > Just noticed a typo. File mentioned in func.sgml, line 11049 should be > src/include/access/htup.h and not > src/include/storage/bufpage.h > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > > > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- 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] log_autovacuum
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. --- Simon Riggs wrote: > On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote: > > Maybe something like this is better: > > > > LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199, > > 2338 remain CPU usage: whatever > > CONTEXT: Automatic vacuuming of table "database.public.w" > > Yours is better. > > I've implemented this: > > LOG: autovac "public.w" index passes: 1 pages: removed 0, 197 remain > tuples: removed 7199, 2338 remain CPU usage: whatever > > I'm happy if this gets removed later, but I think it will help everybody > understand how multi-vacuums are working and what the best way to > specify the controls should be. > > Not sure about the CONTEXT bit. I think its verbose, plus I thought that > was for ERRORs only. I will defer on this point, since I know y'all > understand that better than I. > > -- > 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 -- 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] Heap page diagnostic/test functions (v2)
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. --- Simon Riggs wrote: > New functions to examine the contents of heap pages, as discussed > recently on -hackers. These are fully integrated into backend. > > Designed to be extended for other page layouts/contents. (Heikki has > some similar functions for index pages). > > Docs included, applies cleanly, tests good. > > I'll maintain this with immediate fixes/additions as we go up to 8.3 and > beyond, to assist review process of various patches that alter page > contents. > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > [ Attachment, skipping... ] > > ---(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. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] LIMIT/SORT optimization
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > > 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. > > Did Greg push a version which didn't carry the "WIP" label to it? As > far as I remember he was still asking how to make the Sort and Limit > nodes communicate. Good question. I asked for a new version of this patch and the WIP was only in the email subject line. Greg, is this ready for review? -- 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 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] LIMIT/SORT optimization
Bruce Momjian wrote: > > 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. Did Greg push a version which didn't carry the "WIP" label to it? As far as I remember he was still asking how to make the Sort and Limit nodes communicate. > Gregory Stark wrote: > > > > "Gregory Stark" <[EMAIL PROTECTED]> writes: > > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > >> Is there a newer version of this patch? > > > > > > As requested, I've cut an updated version of this patch against CVS HEAD: > > > > > > http://community.enterprisedb.com/sort-limit-v5.patch.gz -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(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] Synchronized Scan WIP patchf
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. --- Jeff Davis wrote: > On Thu, 2007-03-22 at 16:43 -0400, Bruce Momjian wrote: > > Will use '16' rather than '100'. > > > > 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. > > > > Here is the latest version, which includes the change to report every 16 > pages. > > This patch has the following improvements: > > * reporting interval to 16 pages > * rearranges the scan location tracing output to work regardless of the > reporting interval. Previously it did not trace the output correctly if > the logging interval was not an even multiple of the reporting interval > * GUC trace_sync_seqscan= now controls whether the DEBUG output > is generated or not. If this is true, a lot of logging output will be > generated at DEBUG3. > * You can set sync_seqscan_threshold=<-1.0 ... 100.0>. Positive values > are treated as a fraction of NBuffers. Negative values disable sync > scans. > > Still TODO: > > * Publish my test results (I've collected much of the raw data already > on this version of the patch) > * SGML documentation (after we stabilize the GUC names and meanings) > * Possibly remove sync_seqscan_threshold= and instead use a > simple enable/disable boolean that sets the threshold at a constant > fraction of NBuffers (most likely the same fraction as Simon's recycle > buffers patch) > > Regards, > Jeff Davis [ Attachment, skipping... ] > > ---(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. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Synchronized Scan WIP patch
On Thu, 2007-03-22 at 16:43 -0400, Bruce Momjian wrote:
> Will use '16' rather than '100'.
>
> 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.
>
Here is the latest version, which includes the change to report every 16
pages.
This patch has the following improvements:
* reporting interval to 16 pages
* rearranges the scan location tracing output to work regardless of the
reporting interval. Previously it did not trace the output correctly if
the logging interval was not an even multiple of the reporting interval
* GUC trace_sync_seqscan= now controls whether the DEBUG output
is generated or not. If this is true, a lot of logging output will be
generated at DEBUG3.
* You can set sync_seqscan_threshold=<-1.0 ... 100.0>. Positive values
are treated as a fraction of NBuffers. Negative values disable sync
scans.
Still TODO:
* Publish my test results (I've collected much of the raw data already
on this version of the patch)
* SGML documentation (after we stabilize the GUC names and meanings)
* Possibly remove sync_seqscan_threshold= and instead use a
simple enable/disable boolean that sets the threshold at a constant
fraction of NBuffers (most likely the same fraction as Simon's recycle
buffers patch)
Regards,
Jeff Davis
diff -cr postgresql-8.2.3/src/backend/access/heap/heapam.c postgresql-8.2.3-ss/src/backend/access/heap/heapam.c
*** postgresql-8.2.3/src/backend/access/heap/heapam.c Sun Feb 4 12:00:49 2007
--- postgresql-8.2.3-ss/src/backend/access/heap/heapam.c Tue Mar 20 16:12:12 2007
***
*** 65,70
--- 65,275
*
*/
+ static BlockNumber ss_init(HeapScanDesc);
+ static int ss_store_hint(HeapScanDesc,BlockNumber);
+ static int ss_hash(HeapScanDesc);
+ bool Trace_sync_seqscan = false;
+ double sync_seqscan_threshold = DEFAULT_SYNC_SCAN_THRESHOLD;
+ double sync_seqscan_offset = DEFAULT_SYNC_SCAN_OFFSET;
+
+ /*
+ * ss_init:
+ *
+ * This function reads the Sync Scan Hint Table
+ * (creating it if it doesn't already exist) to
+ * find a possible location for an already running
+ * sequential scan on this relation.
+ *
+ * By starting a sequential scan near the location
+ * of an already running scan, we improve the chance
+ * of finding pages in cache.
+ *
+ * Also, depending on SYNC_SCAN_START_OFFSET, this
+ * function will subtract from the hint before
+ * starting the scan, in order to pick up pages that
+ * are likely to already be in cache.
+ *
+ * This function assumes that scan->rs_nblocks is
+ * already properly set, and sets scan->rs_start_page
+ * to a value based on the hint found. Also, it sets
+ * scan->rs_hint to point to the location of the hint
+ * in the hint table.
+ */
+ static BlockNumber ss_init(HeapScanDesc scan)
+ {
+ ss_hint_t *hint_table;
+ int table_offset;
+ bool found;
+ int threshold = sync_seqscan_threshold * NBuffers;
+ int offset = sync_seqscan_offset * NBuffers;
+
+ /*
+ * If the table is not large enough, or sync_scan_threshold
+ * is disabled (negative), don't Sync Scan.
+ */
+ if(threshold < 0 || scan->rs_nblocks < threshold)
+ {
+ scan->rs_start_page = 0;
+ return 0;
+ }
+
+ table_offset = ss_hash(scan);
+ hint_table = (ss_hint_t*)ShmemInitStruct("Sync Scan Hint Table",
+ SYNC_SCAN_TABLE_SIZE*sizeof(ss_hint_t),&found);
+
+ scan->rs_hint = &hint_table[table_offset];
+
+ /*
+ * If we just created the hint table for the first time,
+ * initialize the table to zero and start the scan at page 0.
+ */
+ if(!found) {
+ if(Trace_sync_seqscan)
+ elog(DEBUG2,"SYNC_SCAN: Created Hint Table");
+ memset(hint_table,0,sizeof(ss_hint_t)*SYNC_SCAN_TABLE_SIZE);
+ scan->rs_start_page = 0;
+ return 0;
+ }
+
+ /*
+ * If the hint's relid is 0, that means
+ * we have not previously created a hint
+ * at this location in the table.
+ */
+ if(scan->rs_hint->relid == 0) {
+ if(Trace_sync_seqscan)
+ elog(DEBUG2, "SYNC_SCAN: Hint empty");
+ scan->rs_start_page = 0;
+ return 0;
+ }
+
+ /*
+ * If the relid doesn't match the one in the hint,
+ * we have a hash collision.
+ */
+ if(RelationGetRelid(scan->rs_rd) != scan->rs_hint->relid)
+ {
+ if(Trace_sync_seqscan)
+ elog(DEBUG1,"SYNC_SCAN: Hash collision");
+ scan->rs_start_page = 0;
+ return 0;
+ }
+
+ /*
+ * If the hint is not a valid block number
+ * for this relation, start at 0.
+ *
+ * This can happen if, for instance, someone
+ * TRUNCATEd the table between when the hint
+ * was set and now.
+ */
+ if(scan->rs_hint->location < 0 ||
+ scan->rs_hint->location >= scan->rs_nblocks)
+ {
+ if(Trace_sync_seqscan)
+ elog(DEBUG2,"SYNC_SCAN: Hint %d out of range." \
+ " Relation has %d pages.",
+ scan->
Re: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
On 3/22/07, Tom Lane <[EMAIL PROTECTED]> wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more >> features to it. > Author states: >> I understand that XML support is planned and at least partially >> implemented for 8.3, but many production instances will be unable (or, >> in fact, unwilling) to upgrade to 8.3 for quite some time. Because >> this patch is completely backward compatible it can (theoretically) be >> included in future 8.1 and 8.2 releases, and for those of us that need >> more full XML support in the short term the upgrade of a contrib >> module is probably a very viable option -- it is for me, anyway. Well, it's not going to be put in future 8.1 or 8.2 releases, so the above argument is not a reason to include it now. What the author should do if he wants to offer a new feature for past release branches is to put up a project on pgfoundry. regards, tom lane Hmm.. OK. Well, thank you all for clarifying that. I thought (perhaps only hoped?) that the bar was lower for contrib than for core as far as features go, but it seems that assumption is incorrect. I'll look at starting a pgfoundry project soon. A related question, however: Will the XML features being included in 8.3 support namespace prefix registration? If not, handling arbitrary XML via XPath that includes unprefixed (default) namespaces (for me that is the majority of the XML I deal with, and no, I can't change that) will have exactly the same problems using the new mechanisms as with the current xml2 contrib module. I ask because, based on the design emails I've seen on -hackers, nothing surrounding explicit support for said issue jumped out at me. Thanks again. -- Mike Rylander [EMAIL PROTECTED] GPLS -- PINES Development Database Developer http://open-ils.org ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Bruce Momjian <[EMAIL PROTECTED]> writes: > Peter Eisentraut wrote: >> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more >> features to it. > Author states: >> I understand that XML support is planned and at least partially >> implemented for 8.3, but many production instances will be unable (or, >> in fact, unwilling) to upgrade to 8.3 for quite some time. Because >> this patch is completely backward compatible it can (theoretically) be >> included in future 8.1 and 8.2 releases, and for those of us that need >> more full XML support in the short term the upgrade of a contrib >> module is probably a very viable option -- it is for me, anyway. Well, it's not going to be put in future 8.1 or 8.2 releases, so the above argument is not a reason to include it now. What the author should do if he wants to offer a new feature for past release branches is to put up a project on pgfoundry. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] simply custom variables protection
Patch removed from patch queue. --- Pavel Stehule wrote: > > >"Pavel Stehule" <[EMAIL PROTECTED]> writes: > > > this patch contains function ArmorCustomVariables. This function set > >flag > > > armored on any custom variable. From this moment only superuser can > >change > > > this variable. > > > >Why is this a good idea? Why don't you just fix the problem as > >previously agreed, namely make the GUC context values work properly > >for custom variables? > > > > I am sorry, I don't see it. In my solution module knows own variables and > can chose what want to do with its. So if I like ro variables, then I add > into module init calling ResetPgVariables() and ArmorCustomVariables(), and > without anything the behave is same like current.What do you though. > > Regards > Pavel Stehule > > _ > Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ > > > ---(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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] simply custom variables protection
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > 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. > > This patch was already objected to, on the grounds that it does not > meet the previously-agreed-to design for handling non-USERSET custom > variables. I did not see that. Removed. -- 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: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Dave Page wrote: > Bruce Momjian wrote: > > Peter Eisentraut wrote: > >> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more > >> features to it. > > > > Author states: > > > >> I understand that XML support is planned and at least partially > >> implemented for 8.3, but many production instances will be unable (or, > >> in fact, unwilling) to upgrade to 8.3 for quite some time. Because > >> this patch is completely backward compatible it can (theoretically) be > >> included in future 8.1 and 8.2 releases, and for those of us that need > >> more full XML support in the short term the upgrade of a contrib > >> module is probably a very viable option -- it is for me, anyway. > > > > But we don't add new features to stable branches, even if they're > backward compatible. I was quoting the text only to state the author realizes /contrib/xml2 is depricated in 8.3. This is not going into 8.2.X, only 8.3. -- 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] simply custom variables protection
Bruce Momjian <[EMAIL PROTECTED]> writes: > 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. This patch was already objected to, on the grounds that it does not meet the previously-agreed-to design for handling non-USERSET custom variables. regards, tom lane ---(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: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Bruce Momjian wrote: > Peter Eisentraut wrote: >> I was hoping that we're deprecating contrib/xml2, so I wouldn't add more >> features to it. > > Author states: > >> I understand that XML support is planned and at least partially >> implemented for 8.3, but many production instances will be unable (or, >> in fact, unwilling) to upgrade to 8.3 for quite some time. Because >> this patch is completely backward compatible it can (theoretically) be >> included in future 8.1 and 8.2 releases, and for those of us that need >> more full XML support in the short term the upgrade of a contrib >> module is probably a very viable option -- it is for me, anyway. > But we don't add new features to stable branches, even if they're backward compatible. Regards, Dave ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] simply custom variables protection
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 contains function ArmorCustomVariables. This function set flag > armored on any custom variable. From this moment only superuser can change > this variable. > > p.s. use it together with ResetPGVariable() > > Regards > Pavel Stehule > > _ > Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. > http://www.msn.cz/ [ 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 -- 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: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Peter Eisentraut wrote: > Bruce Momjian wrote: > > 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. > > I was hoping that we're deprecating contrib/xml2, so I wouldn't add more > features to it. Author states: > I understand that XML support is planned and at least partially > implemented for 8.3, but many production instances will be unable (or, > in fact, unwilling) to upgrade to 8.3 for quite some time. Because > this patch is completely backward compatible it can (theoretically) be > included in future 8.1 and 8.2 releases, and for those of us that need > more full XML support in the short term the upgrade of a contrib > module is probably a very viable option -- it is for me, anyway. -- 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
Re: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
Bruce Momjian wrote: > 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. I was hoping that we're deprecating contrib/xml2, so I wouldn't add more features to 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] xpath_array with namespaces support
Nikolay Samokhvalov wrote: > Also, maybe someone can suggest better approach for passing namespace > bindings (more convenient than ARRAY[ARRAY[...], ARRAY[...]])? Your code assumes ARRAY[ARRAY['myns', 'myns2'], ARRAY['http://example.com', 'http://example2.com']] Shouldn't it be ARRAY[ARRAY['myns', 'http://example.com'], ARRAY['myns2', 'http://example2.com']] ? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] guc patch: Make variables fall back to default values
Is there a new version of this patch being worked on? --- Tom Lane wrote: > Joachim Wieland <[EMAIL PROTECTED]> writes: > > On Tue, Mar 13, 2007 at 11:52:38AM -0400, Tom Lane wrote: > >> Why do you need to tell that? IMHO, once the DefineCustomFoo function > >> has been executed, it should be exactly like any other variable (other > >> than having a funny name). > > > For example for the fall-back-to-default patch. I might not need to tell if > > it has been introduced by one of the DefineCustomFoo functions but for the > > "other" custom variables. Imagine that we have defined a custom variable via > > the configuration file, remove it and send SIGHUP. My understanding is that > > this variable should then be deleted from the pool of valid variables > > because it falls back to its default value and the default value of a custom > > variable is its non-existance. > > Once DefineCustomFoo has been executed, you have a reset value to fall > back to. I think what you really want is to recognize variables that > are in the placeholder state, and have them go away as above. > For that you check the GUC_CUSTOM_PLACEHOLDER flag. In any case there > must never be any use of var->group for decision making; that's simply > wrong. > > However, ISTM that forcing variables to go away is useless extra code. > What purpose does it serve? Not error checking, because you already > accepted the variable before. Surely you wouldn't argue that, say, > reverting to a prior setting of check_function_bodies should cause the > system to go back and validate a CREATE FUNCTION command it has already > accepted. Moreover, while you could perhaps argue that the "principle > of least surprise" cuts either way here, it seems to me there's a good > argument for not throwing away variables: you might be discarding data > the user needed. So I'd vote for just leaving them there. > > regards, tom lane > > ---(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 -- 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 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] xpath_array with namespaces support
Andrew Dunstan wrote: > Would it be better to use some more unlikely name for the dummy root > element used to process fragments than ? Why do we even need to support xpath on fragments? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] xpath_array with namespaces support
Nikolay Samokhvalov wrote: > On 3/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote: > > I'll fix these issues and extend the patch with resgression tests > > and docs for xpath_array(). I'll resubmit it very soon. > > Here is a new version of the patch. I didn't change any part of docs > yet. Since there were no objections I've changed the name of the > function to xmlpath(). Why is the function not strict? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] xpath_array with namespaces support
Bruce Momjian wrote: > Patch applied. This code seems to think that if an xml datum starts with "http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] xpath_array with namespaces support
Nikolay Samokhvalov wrote: > Here is a new version of the patch. I didn't change any part of docs > yet. Since there were no objections I've changed the name of the > function to xmlpath(). I didn't see any discussion about changing the name to xmlpath. Seeing that the function implements xpath, and xpath is a recognized name, this change is wrong. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Re: [DOCS] suggestion for improving TMPDIR and "--format" docs for pg_dump
Bruce Momjian wrote: > Dave Page wrote: >> Bruce Momjian wrote: >> >>> Thanks for the report. I have corrected this and the fix will be in >>> PostgreSQL 8.3. Interestingly, we support non-documented option >>> "append" and "file" too. >> Append is undocumented as it's intended to be used by pg_dumpall, not >> directly by users. > > Ah, OK, but there should be a clear comment somewhere about that. I > will add it. > Thanks. Regards Dave ---(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] Re: [DOCS] suggestion for improving TMPDIR and "--format" docs for pg_dump
Dave Page wrote: > Bruce Momjian wrote: > > > Thanks for the report. I have corrected this and the fix will be in > > PostgreSQL 8.3. Interestingly, we support non-documented option > > "append" and "file" too. > > Append is undocumented as it's intended to be used by pg_dumpall, not > directly by users. Ah, OK, but there should be a clear comment somewhere about that. I will add it. -- 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 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Synchronized Scan WIP patch
Will use '16' rather than '100'. 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. --- Jeff Davis wrote: > This is my latest revision of the Sync Scan patch, and it implements the > observability as discussed with Simon. > > Changes: > * ss_report_loc() called once per hundred pages rather than once per > page > * DEBUG messages are a little cleaner and easier to parse, for the sake > of analysis after the fact. > * DEBUG2 reports a sync scan starting, the relation size in pages, and > the location at which the scan starts. > * DEBUG2 reports the location of a scan every 50k pages, DEBUG3 every > 5k pages (before it was 100k/10k at DEBUG3/DEBUG4, respectively). > Numbers are aligned along 5k boundaries to make analysis easier. > * GUCs: >* sync_seqscan_threshold: fraction of NBuffers for the threshold >* sync_seqscan_offset: fraction of NBuffers for the offset >* trace_sync_seqscan: will be used in final version of patch to > control DEBUG output > > Sync_scan_offset may be eliminated completely if it's not shown to be > useful enough in conjunction with Simon's patch. Sync Scans are still a > big win without sync_seqscan_offset. > > Sync_scan_threshold= may be turned into sync_seqscan= > with a fixed activation threshold (NBuffers/2 per Simon's suggestion). > The reason is that synchronized scans should activate at the same > threshold as Simon's scan_recycle_buffers feature. Should we make a > "#define BIG_SCAN_THRESHOLD NBuffers/2" to use for both sync_seqscan and > for scan_recycle_buffers? > > Regards, > Jeff Davis [ 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 -- 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 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] Updated Packed Varlena patch v20 (final?)
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. --- Gregory Stark wrote: > > Updated patch: > > I went through the "high traffic" areas and levelled them up to using the new > macros to avoid "detoasting" smaller arguments. They key areas are really > btree operators since they have a noticeable effect on sorts, especially index > builds, when the data being sorted fits in memory. > > There is a bit of a name-game here. The macros I made are called > VARDATA_ANY(datum) VARSIZE_ANY(datum) AND VARSIZE_ANY_EXHDR(datum). > And the datatype macros are, for example, PG_GETARG_TEXT_PP() and > DatumGetTextPP() -- short for "packed pointer". > > Maybe not the prettiest names in the world but clear and I've found them > pretty easy to spot when I'm looking for inconsistent use of > VARSIZE_ANY<->VARDATA for example. I thought of PVARSIZE/PVARDATA (for > "packed") but I'm afraid it would camouflage such cases. > > Anyone have any better ideas? If not I'm satisfied with them... > Except maybe VARSIZE_ANY_EXHDR() which seems too long. > > I got to almost everything in varlena.c and varchar.c so that includes text, > bpchar, and bytea as well as varchar's few procedures. That includes probably > more than I really needed to, but as long as the datatypes are working with > bytes it's convenient enough. > > Also, I replaced my tweaks to hstore and pg_trgm with Teodore's. > > And of course updated CVS. > > http://community.enterprisedb.com/varlena/varvarlena-20.patch.gz > > I'm going to be putting this aside for a little while. I think it's really > done. There's more that can be done of course, hit inet and numeric with the > new macros, for instance. But I want to see what happens when it gets reviewed > before I do that kind of bookkeeping. > > One thing that I've left in there again is the htonl/ntohl macros in the > big-endian case. It really makes sense to either remove them or remove the > #ifdef. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > > ---(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 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] Re: [DOCS] suggestion for improving TMPDIR and "--format" docs for pg_dump
Bruce Momjian wrote: > Thanks for the report. I have corrected this and the fix will be in > PostgreSQL 8.3. Interestingly, we support non-documented option > "append" and "file" too. Append is undocumented as it's intended to be used by pg_dumpall, not directly by users. Regards, Dave. ---(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] LIMIT/SORT optimization
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. --- Gregory Stark wrote: > > "Gregory Stark" <[EMAIL PROTECTED]> writes: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > >> Is there a newer version of this patch? > > > > As requested, I've cut an updated version of this patch against CVS HEAD: > > > > http://community.enterprisedb.com/sort-limit-v5.patch.gz > > Someone asked why I've been posting links rather than attachments. The only > reason was because when I posted patches in the past they were dropped by the > mailing list. I would say "refused" except I never received a bounce, the > messages just never appeared on list or in the archive. > > I'll try attaching this patch again, which is relatively small compared to the > recursive query patches and packed varlena patches which disappeared into the > ether. Also, this one is gzipped whereas in the past I usually attached > patches uncompressed so people could read them without saving and > uncompressing them. Perhaps one of those differences is the source of the > problem? > > Do people prefer receiving attachments or downloadable links? > Does the answer change if the patches are quite large? > [ Attachment, skipping... ] > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > > ---(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 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] xpath_array with namespaces support
Applying newest version of this patch now; still needs documentation.
---
Nikolay Samokhvalov wrote:
> On 3/5/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
> > On 3/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
> > > I'll fix these issues and extend the patch with resgression tests and
> > > docs for xpath_array(). I'll resubmit it very soon.
> >
> > Here is a new version of the patch. I didn't change any part of docs yet.
> > Since there were no objections I've changed the name of the function
> > to xmlpath().
>
> Updated version of the patch contains bugfix: there were a problem
> with path queries that pointed to elements (cases when a set of
> document parts that correspond to subtrees should be returned).
> Example is (included in regression test):
>
> xmltest=# SELECT xmlpath('//b', 'one two three etc');
> xmlpath
> -
> {two,etc}
> (1 row)
>
> Waiting for more feedback, please check it.
>
> --
> Best regards,
> Nikolay
[ 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 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Re: [DOCS] suggestion for improving TMPDIR and "--format" docs for pg_dump
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Thanks for the report. I have corrected this and the fix will be in > > PostgreSQL 8.3. Interestingly, we support non-documented option > > "append" and "file" too. > > Surely these should all be pg_strcasecmp? Yep, fixed. -- 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] Re: [DOCS] suggestion for improving TMPDIR and "--format" docs for pg_dump
Bruce Momjian <[EMAIL PROTECTED]> writes: > Thanks for the report. I have corrected this and the fix will be in > PostgreSQL 8.3. Interestingly, we support non-documented option > "append" and "file" too. Surely these should all be pg_strcasecmp? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] xml2 contrib patch supporting default XML namespaces
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.
---
Mike Rylander wrote:
> On 3/6/07, Mike Rylander <[EMAIL PROTECTED]> wrote:
> > On 3/6/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > > Mike Rylander wrote:
> > > > The patch adds support for default XML namespaces in xml2 by providing
> > > > a mechanism for supplying a prefix to a named namespace URI.
> > >
> > > How does it support multiple namespaces in one document?
> >
> > It supports one default (unprefixed) namespace URI per document, which
> > ISTM is the overwhelmingly common case (and the itch that I must
> > scratch).
>
> I think there is some confusion about what the current xml2 contrib
> module supports and what my patch adds. The current code, as it
> stands today, supports multiple namespaces just fine. The only
> requirement is that each namespace have a prefix, or else one is
> forced to use the local-name() construct with every single node for
> those nodes in unprefixed ("default") namespaces. This patch simply
> adds support for registering a prefix for an unprefixed namespace,
> which is an extremely common case in XML and causes the use of overly
> verbose contortions when designing XPath expressions. To illustrate
> this, xml2 currently supports all of these statements:
>
> SELECT xpath_nodeset('foo','/x/y');
> SELECT xpath_nodeset('foo','/x/a:y');
> SELECT xpath_nodeset(' xmlns:a="uri:for:a">foo','/b:x/a:y');
>
> All number and manner of /prefixed/ namespaces work fine today.
> However, in order to match an element or attribute with an unprefixed
> namespace, the xpath becomes a study in overly verbose, human error
> inducing repetition. For instance, consider the extremely common case
> of an xhtml document that does not use a prefix for the xhtml
> namespace. Using the xml2 contrib module as it stands today, without
> my patch, using XPath to get the title of the document might look
> something like this:
>
> /*[local-name()="html"]/*[local-name()="head"]/*[local-name()="title"]
>
> Now just imagine the XPath needed to get a portion of the body in a
> nested div based on the existence of some other node ... the logic
> gets lost in the noise simply because of the overhead of
> namespace-qualifying the elements.
>
> Namespaces were introduced in XML to address verbosity issues (among
> other things), but as XPath was designed primarily as a language for
> use inside XSLT (where namespace support is fully integrated) it
> didn't get the treatment needed to handle unprefixed namespaces. To
> address /that/ issue, my patch allows the registration of a supplied
> prefix for a supplied URI, which solves the common "default namespace"
> problem in a completely backward compatible way. The above example
> XPath can now become:
>
> /x:html/x:head/x:title
>
> simply by supplying 2 more arguments to the _ns version of any of the
> xpath_ functions available in xml2. I challenge anyone to claim that
> the [local-name()="foo] variant is easier to read and less error prone
> than the second, namespace-prefixed variant. They are exactly
> equivalent, but the second (quite obviously) is Better(tm).
>
> I understand that XML support is planned and at least partially
> implemented for 8.3, but many production instances will be unable (or,
> in fact, unwilling) to upgrade to 8.3 for quite some time. Because
> this patch is completely backward compatible it can (theoretically) be
> included in future 8.1 and 8.2 releases, and for those of us that need
> more full XML support in the short term the upgrade of a contrib
> module is probably a very viable option -- it is for me, anyway.
>
> So, to sum up, please let me know what I can do to increase the
> chances of getting this patch included. Alternatively, if my patch is
> being vetoed, please let me know that too so that I can create a local
> maintenance plan for this.
>
> Thanks in advance. I've attached the patch again for reference.
>
> --
> Mike Rylander
> [EMAIL PROTECTED]
> GPLS -- PINES Development
> Database Developer
> http://open-ils.org
[ Attachment, skipping... ]
>
> ---(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. +
---(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] xpath_array with namespaces support
Patch applied. Please provide a documentation addition. Thanks. --- Nikolay Samokhvalov wrote: > On 3/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote: > > I'll fix these issues and extend the patch with resgression tests and > > docs for xpath_array(). I'll resubmit it very soon. > > Here is a new version of the patch. I didn't change any part of docs yet. > Since there were no objections I've changed the name of the function > to xmlpath(). > > -- > Best regards, > Nikolay [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- 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] [HACKERS] LIKE optimization in UTF-8 and locale-C
Ühel kenal päeval, N, 2007-03-22 kell 11:08, kirjutas Tom Lane: > ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > > I found LIKE operators are slower on multi-byte encoding databases > > than single-byte encoding ones. It comes from difference between > > MatchText() and MBMatchText(). > > > We've had an optimization for single-byte encodings using > > pg_database_encoding_max_length() == 1 test. I'll propose to extend it > > in UTF-8 with locale-C case. > > If this works for UTF8, won't it work for all the backend-legal > encodings? I guess it works well for % but not for _ , the latter has to know, how many bytes the current (multibyte) character covers. The length is still easy to find out for UTF8 encoding, so it may be feasible to write UTF8MatchText() that is still faster than MBMatchText(). -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] vacuumdb cancel handler
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. --- ITAGAKI Takahiro wrote: > Hello, > > I found vacuumdb, reindexdb and clusterdb don't have cancel handlers. > The server continues to process commands when we press Ctrl+C on those > client programs, though they exit. Therefore, "psql -c VACUUM" and Ctrl+C > works well, but vacuumdb and Ctrl+C does not. > > I borrowed the cancel handler from psql and add it into vacuumdb, reindexdb > and clusterdb. Other programs in src/bin/scripts also have the same problem, > but I think it is worth porting only for maintenance commands because they > take long time. > > This bug (or spec?) exists in 7.4, 8.0, 8.1 and 8.2. Those commands > were wrappers of psql at 7.3 and we rewrote them into C programs at 7.4. > We might forget to port the feature then. > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center [ Attachment, skipping... ] > > ---(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. + ---(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] [HACKERS] Stats processor not restarting
Applied. I did the case where we exit right away too, just for
consistency.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Not really, but maybe it would be sensible to reset
> > >> last_pgstat_start_time
> > >> when doing a database-wide restart?
> >
> > > You mean like this, attached?
> >
> > I'd be fairly surprised if resetting the variable in the child process
> > had any effect on the postmaster...
>
> Yep, me too. ;-)
>
> > I think a correct fix would involve exposing either the variable or a
> > routine to zero it from pgstat.c, and having postmaster.c do that at
> > the points where it intentionally SIGQUITs the stats collector.
>
> OK, patch attached. I just reset the value in all places where we were
> killing the pgstat process and not immediately exiting ourselves.
>
> --
> 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/postmaster/pgstat.c
> ===
> RCS file: /cvsroot/pgsql/src/backend/postmaster/pgstat.c,v
> retrieving revision 1.149
> diff -c -c -r1.149 pgstat.c
> *** src/backend/postmaster/pgstat.c 16 Mar 2007 17:57:36 - 1.149
> --- src/backend/postmaster/pgstat.c 22 Mar 2007 14:40:36 -
> ***
> *** 572,577
> --- 572,581
> return 0;
> }
>
> + void allow_immediate_pgstat_restart(void)
> + {
> + last_pgstat_start_time = 0;
> + }
>
> /*
>* Public functions used by backends follow
> Index: src/backend/postmaster/postmaster.c
> ===
> RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
> retrieving revision 1.526
> diff -c -c -r1.526 postmaster.c
> *** src/backend/postmaster/postmaster.c 7 Mar 2007 13:35:02 -
> 1.526
> --- src/backend/postmaster/postmaster.c 22 Mar 2007 14:40:37 -
> ***
> *** 1896,1902
> --- 1896,1905
> signal_child(PgArchPID, SIGQUIT);
> /* Tell pgstat to shut down too; nothing left for it to
> do */
> if (PgStatPID != 0)
> + {
> signal_child(PgStatPID, SIGQUIT);
> + allow_immediate_pgstat_restart();
> + }
> /* Tell autovac launcher to shut down too */
> if (AutoVacPID != 0)
> signal_child(AutoVacPID, SIGTERM);
> ***
> *** 1952,1958
> --- 1955,1964
> signal_child(PgArchPID, SIGQUIT);
> /* Tell pgstat to shut down too; nothing left for it to
> do */
> if (PgStatPID != 0)
> + {
> signal_child(PgStatPID, SIGQUIT);
> + allow_immediate_pgstat_restart();
> + }
> /* Tell autovac launcher to shut down too */
> if (AutoVacPID != 0)
> signal_child(AutoVacPID, SIGTERM);
> ***
> *** 2241,2247
> --- 2247,2256
> signal_child(PgArchPID, SIGQUIT);
> /* Tell pgstat to shut down too; nothing left for it to do */
> if (PgStatPID != 0)
> + {
> signal_child(PgStatPID, SIGQUIT);
> + allow_immediate_pgstat_restart();
> + }
> /* Tell autovac launcher to shut down too */
> if (AutoVacPID != 0)
> signal_child(AutoVacPID, SIGTERM);
> ***
> *** 2404,2409
> --- 2413,2419
>"SIGQUIT",
>(int)
> PgStatPID)));
> signal_child(PgStatPID, SIGQUIT);
> + allow_immediate_pgstat_restart();
> }
>
> /* We do NOT restart the syslogger */
> Index: src/include/pgstat.h
> ===
> RCS file: /cvsroot/pgsql/src/include/pgstat.h,v
> retrieving revision 1.55
> diff -c -c -r1.55 pgstat.h
> *** src/include/pgstat.h 16 Mar 2007 17:57:36 - 1.55
> --- src/include/pgstat.h 22 Mar 2007 14:40:38 -
> ***
> *** 369,375
> extern void pgstat_init(void);
> extern int pgstat_start(void);
> extern void pgstat_reset_all(void);
> !
> #ifdef EXEC_BACKEND
> extern void PgstatCollectorMain(int argc, char *argv[]);
>
[PATCHES] Re: [DOCS] suggestion for improving TMPDIR and "--format" docs for pg_dump
Mark Stosberg wrote:
> Bruce Momjian wrote:
> > Mark Stosberg wrote:
> >> It woud also be nice to document that the full names "custom" and "tar" are
> >> supported. Longer names can be nice for clarity.
> >>
> >> ( Unfortunately, wrong formats like "txx" also work instead of throwing
> >> an error. )
> >
> > I don't see that with current CVS:
> >
> > $ pg_dump --format=x test
> > pg_dump: invalid output format "x" specified
>
> Bruce,
>
> I think the specific test case would have to start with a valid letter,
> like "t", and then include invalid characters. Try this instead:
>
> pg_dump --format=tx test
Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
"append" and "file" too.
Patch attached and applied.
--
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/bin/pg_dump/pg_dump.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.461
diff -c -c -r1.461 pg_dump.c
*** src/bin/pg_dump/pg_dump.c 19 Mar 2007 23:38:30 - 1.461
--- src/bin/pg_dump/pg_dump.c 22 Mar 2007 18:39:53 -
***
*** 476,513
}
/* open the output file */
! switch (format[0])
{
! case 'a':
! case 'A':
! plainText = 1;
! g_fout = CreateArchive(filename, archNull, 0, archModeAppend);
! break;
!
! case 'c':
! case 'C':
! g_fout = CreateArchive(filename, archCustom, compressLevel, archModeWrite);
! break;
!
! case 'f':
! case 'F':
! g_fout = CreateArchive(filename, archFiles, compressLevel, archModeWrite);
! break;
!
! case 'p':
! case 'P':
! plainText = 1;
! g_fout = CreateArchive(filename, archNull, 0, archModeWrite);
! break;
!
! case 't':
! case 'T':
! g_fout = CreateArchive(filename, archTar, compressLevel, archModeWrite);
! break;
!
! default:
! write_msg(NULL, "invalid output format \"%s\" specified\n", format);
! exit(1);
}
if (g_fout == NULL)
--- 476,508
}
/* open the output file */
! if (strcasecmp(format, "a") == 0 || strcasecmp(format, "append") == 0)
{
! /* not documented */
! plainText = 1;
! g_fout = CreateArchive(filename, archNull, 0, archModeAppend);
! }
! else if (strcasecmp(format, "c") == 0 || strcasecmp(format, "custom") == 0)
! g_fout = CreateArchive(filename, archCustom, compressLevel, archModeWrite);
! else if (strcasecmp(format, "f") == 0 || strcasecmp(format, "file") == 0)
! {
! /*
! * Dump files into the current directory; for demonstration only, not
! * documented.
! */
! g_fout = CreateArchive(filename, archFiles, compressLevel, archModeWrite);
! }
! else if (strcasecmp(format, "p") == 0 || strcasecmp(format, "plain") == 0)
! {
! plainText = 1;
! g_fout = CreateArchive(filename, archNull, 0, archModeWrite);
! }
! else if (strcasecmp(format, "t") == 0 || strcasecmp(format, "tar") == 0)
! g_fout = CreateArchive(filename, archTar, compressLevel, archModeWrite);
! else
! {
! write_msg(NULL, "invalid output format \"%s\" specified\n", format);
! exit(1);
}
if (g_fout == NULL)
---(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] OS timezone files support
Magnus Hagander wrote: Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: This patch brings possibility to switch from default build-in timezone to another timezone source - typically to OS timezone location. It was discussed few weeks ago: http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php AFAIR, the conclusion of that discussion was we didn't want it. I certainly don't see the point of the implementation as you have it --- it adds a great deal of unnecessary infrastructure compared to just installing a symlink at share/postgresql/timezone. And if you wanted it in the backend instead of a symlink, shouldn't it at least try to verify that the files in the timezone directory are compatible before blindly accepting it? I think that packager is responsible for verification his integration. It is same in both cases (configure or link solution). I'm not sure if it is necessary make check of timezone validity during build time. Build environment should be different from target system. If you talk about checking timezone files on runtime, I hope Postgres verify timezone files every time. Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] OS timezone files support
Zdenek Kotala <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I certainly don't see the point of the implementation as you have it >> --- it adds a great deal of unnecessary infrastructure compared to just >> installing a symlink at share/postgresql/timezone. > The point of my solution is that all packagers who interested in use > only configure switch instead of playing with link integration. In this > case, Packager also must cleanup build-in timezones after make install. > This is not only about add one line into spec file. No, it's two lines (rm -rf, ln -s). It'll take many more lines than that to do it in the Postgres configure/build system, even using the simpler symlink approach. And quite aside from the code addition, what of documentation? How much text will it take to make clear what this switch is good for and when it's safe to use? I just don't see the value of supporting this option in our configuration infrastructure. Anyone who is competent to determine whether it's a safe thing to use is more than competent to alter the installation that way for themselves. regards, tom lane ---(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] OS timezone files support
Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: This patch brings possibility to switch from default build-in timezone to another timezone source - typically to OS timezone location. It was discussed few weeks ago: http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php AFAIR, the conclusion of that discussion was we didn't want it. I'm sorry, but I don't think that the thread has clear conclusion. I certainly don't see the point of the implementation as you have it --- it adds a great deal of unnecessary infrastructure compared to just installing a symlink at share/postgresql/timezone. The point of my solution is that all packagers who interested in use only configure switch instead of playing with link integration. In this case, Packager also must cleanup build-in timezones after make install. This is not only about add one line into spec file. There is also big risk that new version of package which will delivery timezones can replace system file zone information and it damages a system. I discussed it with gatekeepers which are responsible for patch preparation and they afraid about future problems with link solution (based on experience with another sw integration). with regards Zdenek ---(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] OS timezone files support
Tom Lane wrote: > Zdenek Kotala <[EMAIL PROTECTED]> writes: >> This patch brings possibility to switch from default build-in timezone >> to another timezone source - typically to OS timezone location. > >> It was discussed few weeks ago: >> http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php > > AFAIR, the conclusion of that discussion was we didn't want it. > > I certainly don't see the point of the implementation as you have it > --- it adds a great deal of unnecessary infrastructure compared to just > installing a symlink at share/postgresql/timezone. And if you wanted it in the backend instead of a symlink, shouldn't it at least try to verify that the files in the timezone directory are compatible before blindly accepting it? //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] contrib/spi makefile inconsistency
Magnus Hagander wrote: > I would like to change that to actually listing the modules instead. > The reason for that is that parsing the Makefile for the msvc build > will be a *lot* easier if I don't have to parse $addsuffix rules. Let's not open that can of worms. Even if you think it's only a small can. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] OS timezone files support
Zdenek Kotala <[EMAIL PROTECTED]> writes: > This patch brings possibility to switch from default build-in timezone > to another timezone source - typically to OS timezone location. > It was discussed few weeks ago: > http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php AFAIR, the conclusion of that discussion was we didn't want it. I certainly don't see the point of the implementation as you have it --- it adds a great deal of unnecessary infrastructure compared to just installing a symlink at share/postgresql/timezone. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] OS timezone files support
This patch brings possibility to switch from default build-in timezone
to another timezone source - typically to OS timezone location. This
enhancement helps to packagers easy solve integration problem with
systems Timezones.
If --with-tzdir=/usr/share/zoneinfo is specified as ./configure
parameter, postgres will use timezone files from /usr/share/zoneinfo
directory and build-in timezone files will not be installed by make
install command.
It was discussed few weeks ago:
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00784.php
With regards Zdenek
Index: configure.in
===
RCS file: /projects/cvsroot/pgsql/configure.in,v
retrieving revision 1.503
diff -c -r1.503 configure.in
*** configure.in 21 Mar 2007 14:39:23 - 1.503
--- configure.in 22 Mar 2007 16:01:51 -
***
*** 121,126
--- 121,133
#
+ # Directory where timezone files are stored
+ #
+ PGAC_ARG_REQ(with, tzdir, [ --with-tzdir=DIRtimezone files directory location],
+ [tzdir=$withval])
+ AC_SUBST(tzdir)
+
+ #
# Add non-standard directories to the include path
#
PGAC_ARG_REQ(with, includes, [ --with-includes=DIRSlook for additional header files in DIRS])
Index: src/Makefile.global.in
===
RCS file: /projects/cvsroot/pgsql/src/Makefile.global.in,v
retrieving revision 1.233
diff -c -r1.233 Makefile.global.in
*** src/Makefile.global.in 9 Feb 2007 15:55:57 - 1.233
--- src/Makefile.global.in 22 Mar 2007 16:01:51 -
***
*** 77,82
--- 77,84
endif
endif
+ tzdir := @tzdir@
+
sysconfdir := @sysconfdir@
ifeq "$(findstring pgsql, $(sysconfdir))" ""
ifeq "$(findstring postgres, $(sysconfdir))" ""
***
*** 122,127
--- 124,130
bindir := $(shell $(PG_CONFIG) --bindir)
datadir := $(shell $(PG_CONFIG) --sharedir)
+ tzdir := $(shell $(PG_CONFIG) --timezonedir)
sysconfdir := $(shell $(PG_CONFIG) --sysconfdir)
libdir := $(shell $(PG_CONFIG) --libdir)
pkglibdir := $(shell $(PG_CONFIG) --pkglibdir)
Index: src/bin/pg_config/pg_config.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_config/pg_config.c,v
retrieving revision 1.24
diff -c -r1.24 pg_config.c
*** src/bin/pg_config/pg_config.c 7 Feb 2007 00:28:54 - 1.24
--- src/bin/pg_config/pg_config.c 22 Mar 2007 16:01:51 -
***
*** 194,199
--- 194,211
}
static void
+ show_timezonedir(bool all)
+ {
+ char path[MAXPGPATH];
+
+ if (all)
+ printf("TIMEZONEDIR = ");
+ get_timezone_path(mypath, path);
+ cleanup_path(path);
+ printf("%s\n", path);
+ }
+
+ static void
show_sysconfdir(bool all)
{
char path[MAXPGPATH];
***
*** 377,382
--- 389,395
{"--localedir", show_localedir},
{"--mandir", show_mandir},
{"--sharedir", show_sharedir},
+ {"--timezonedir", show_timezonedir},
{"--sysconfdir", show_sysconfdir},
{"--pgxs", show_pgxs},
{"--configure", show_configure},
Index: src/include/port.h
===
RCS file: /projects/cvsroot/pgsql/src/include/port.h,v
retrieving revision 1.110
diff -c -r1.110 port.h
*** src/include/port.h 7 Feb 2007 00:28:55 - 1.110
--- src/include/port.h 22 Mar 2007 16:01:51 -
***
*** 34,39
--- 34,40
extern bool path_is_prefix_of_path(const char *path1, const char *path2);
extern const char *get_progname(const char *argv0);
extern void get_share_path(const char *my_exec_path, char *ret_path);
+ extern void get_timezone_path(const char *my_exec_path, char *ret_path);
extern void get_etc_path(const char *my_exec_path, char *ret_path);
extern void get_include_path(const char *my_exec_path, char *ret_path);
extern void get_pkginclude_path(const char *my_exec_path, char *ret_path);
Index: src/port/Makefile
===
RCS file: /projects/cvsroot/pgsql/src/port/Makefile,v
retrieving revision 1.34
diff -c -r1.34 Makefile
*** src/port/Makefile 9 Feb 2007 15:56:00 - 1.34
--- src/port/Makefile 22 Mar 2007 16:01:51 -
***
*** 82,87
--- 82,88
echo "#define LOCALEDIR \"$(localedir)\"" >>$@
echo "#define DOCDIR \"$(docdir)\"" >>$@
echo "#define MANDIR \"$(mandir)\"" >>$@
+ echo "#define TZDIR \"$(tzdir)\"" >>$@
clean distclean maintainer-clean:
rm -f libpgport.a libpgport_srv.a $(LIBOBJS) $(LIBOBJS_SRV) pg_config_paths.h
Index: src/port/path.c
===
RCS file: /projects/cvsroot/pgsql/src/port/path.c,v
retrieving revision 1.71
diff -c -r1.71 path.c
*** src/port/path.c 5 Jan 2007 22:20:02 - 1.71
--- src/port/path.c 22 Mar 2007 16:01:51 -
***
*** 528,533
--- 528,553
}
/*
+ * get_timezone_path
+
Re: [PATCHES] contrib/spi makefile inconsistency
Magnus Hagander <[EMAIL PROTECTED]> writes: > contrib/spi has a Makefile that uses $(addsuffix) makefile rules for > DATA_built and DOCS. It's the only Makefile in contrib that does it. > I would like to change that to actually listing the modules instead. This seems like a definite regression in terms of writing the makefiles. I'm not very happy about it --- just how much complexity are you saving in the msvc support? And have you looked at the other places where addsuffix is already used? (It looks like many of the contrib modules rely on pgxs.mk's usages of addsuffix...) regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] LIKE optimization in UTF-8 and locale-C
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > I found LIKE operators are slower on multi-byte encoding databases > than single-byte encoding ones. It comes from difference between > MatchText() and MBMatchText(). > We've had an optimization for single-byte encodings using > pg_database_encoding_max_length() == 1 test. I'll propose to extend it > in UTF-8 with locale-C case. If this works for UTF8, won't it work for all the backend-legal encodings? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Stats processor not restarting
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Not really, but maybe it would be sensible to reset last_pgstat_start_time
> >> when doing a database-wide restart?
>
> > You mean like this, attached?
>
> I'd be fairly surprised if resetting the variable in the child process
> had any effect on the postmaster...
Yep, me too. ;-)
> I think a correct fix would involve exposing either the variable or a
> routine to zero it from pgstat.c, and having postmaster.c do that at
> the points where it intentionally SIGQUITs the stats collector.
OK, patch attached. I just reset the value in all places where we were
killing the pgstat process and not immediately exiting ourselves.
--
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/postmaster/pgstat.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/pgstat.c,v
retrieving revision 1.149
diff -c -c -r1.149 pgstat.c
*** src/backend/postmaster/pgstat.c 16 Mar 2007 17:57:36 - 1.149
--- src/backend/postmaster/pgstat.c 22 Mar 2007 14:40:36 -
***
*** 572,577
--- 572,581
return 0;
}
+ void allow_immediate_pgstat_restart(void)
+ {
+ last_pgstat_start_time = 0;
+ }
/*
* Public functions used by backends follow
Index: src/backend/postmaster/postmaster.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/postmaster.c,v
retrieving revision 1.526
diff -c -c -r1.526 postmaster.c
*** src/backend/postmaster/postmaster.c 7 Mar 2007 13:35:02 - 1.526
--- src/backend/postmaster/postmaster.c 22 Mar 2007 14:40:37 -
***
*** 1896,1902
--- 1896,1905
signal_child(PgArchPID, SIGQUIT);
/* Tell pgstat to shut down too; nothing left for it to
do */
if (PgStatPID != 0)
+ {
signal_child(PgStatPID, SIGQUIT);
+ allow_immediate_pgstat_restart();
+ }
/* Tell autovac launcher to shut down too */
if (AutoVacPID != 0)
signal_child(AutoVacPID, SIGTERM);
***
*** 1952,1958
--- 1955,1964
signal_child(PgArchPID, SIGQUIT);
/* Tell pgstat to shut down too; nothing left for it to
do */
if (PgStatPID != 0)
+ {
signal_child(PgStatPID, SIGQUIT);
+ allow_immediate_pgstat_restart();
+ }
/* Tell autovac launcher to shut down too */
if (AutoVacPID != 0)
signal_child(AutoVacPID, SIGTERM);
***
*** 2241,2247
--- 2247,2256
signal_child(PgArchPID, SIGQUIT);
/* Tell pgstat to shut down too; nothing left for it to do */
if (PgStatPID != 0)
+ {
signal_child(PgStatPID, SIGQUIT);
+ allow_immediate_pgstat_restart();
+ }
/* Tell autovac launcher to shut down too */
if (AutoVacPID != 0)
signal_child(AutoVacPID, SIGTERM);
***
*** 2404,2409
--- 2413,2419
"SIGQUIT",
(int)
PgStatPID)));
signal_child(PgStatPID, SIGQUIT);
+ allow_immediate_pgstat_restart();
}
/* We do NOT restart the syslogger */
Index: src/include/pgstat.h
===
RCS file: /cvsroot/pgsql/src/include/pgstat.h,v
retrieving revision 1.55
diff -c -c -r1.55 pgstat.h
*** src/include/pgstat.h16 Mar 2007 17:57:36 - 1.55
--- src/include/pgstat.h22 Mar 2007 14:40:38 -
***
*** 369,375
extern void pgstat_init(void);
extern intpgstat_start(void);
extern void pgstat_reset_all(void);
!
#ifdef EXEC_BACKEND
extern void PgstatCollectorMain(int argc, char *argv[]);
#endif
--- 369,375
extern void pgstat_init(void);
extern intpgstat_start(void);
extern void pgstat_reset_all(void);
! extern void allow_immediate_pgstat_restart(void);
#ifdef EXEC_BACKEND
extern void PgstatCollectorMain(int argc, char *argv[]);
#endif
---(end of broadcast)---
TIP 4:
[PATCHES] contrib/spi makefile inconsistency
Hi! contrib/spi has a Makefile that uses $(addsuffix) makefile rules for DATA_built and DOCS. It's the only Makefile in contrib that does it. I would like to change that to actually listing the modules instead. The reason for that is that parsing the Makefile for the msvc build will be a *lot* easier if I don't have to parse $addsuffix rules. And it's not like it's complex modules it's building. But I figured I'd post here for approval first. So - would a patch like the attached be acceptable? (Again, this only applies to contrib/SPI, I don't *expect* there to be more such requirements for the other ones) //Magnus Index: contrib/spi/Makefile === RCS file: /projects/cvsroot/pgsql/contrib/spi/Makefile,v retrieving revision 1.26 diff -c -r1.26 Makefile *** contrib/spi/Makefile27 Sep 2005 17:13:10 - 1.26 --- contrib/spi/Makefile22 Mar 2007 14:15:46 - *** *** 1,8 # $PostgreSQL: pgsql/contrib/spi/Makefile,v 1.26 2005/09/27 17:13:10 tgl Exp $ MODULES = autoinc insert_username moddatetime refint timetravel ! DATA_built = $(addsuffix .sql, $(MODULES)) ! DOCS = README.spi $(addsuffix .example, $(MODULES)) # this is needed for the regression tests; # comment out if you want a quieter refint package for other uses --- 1,8 # $PostgreSQL: pgsql/contrib/spi/Makefile,v 1.26 2005/09/27 17:13:10 tgl Exp $ MODULES = autoinc insert_username moddatetime refint timetravel ! DATA_built = autoinc.sql insert_username.sql moddatetime.sql refint.sql timetravel.sql ! DOCS = README.spi autoinc.example insert_username.example moddatetime.example refint.example timetravel.example # this is needed for the regression tests; # comment out if you want a quieter refint package for other uses ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
