Re: [PATCHES] gettime() - a timeofday() alternative
On 8/7/05, Brendan Jurd [EMAIL PROTECTED] wrote: Hi all, I propose to add an internal function gettime() that transparently returns the current system time, as a timestamptz with maximum precision. Here's the patch. The changes to pg_proc.h, timestamp.h and timestamp.c are trivial. The changes to func.sgml are more comprehensive; I've split the section on Current Date/Time into two subsections, one that explains the transaction time functions and one for the system time functions. -- BJ timestamp.h.diff Description: Binary data pg_proc.h.diff Description: Binary data timestamp.c.diff Description: Binary data func.sgml.diff Description: Binary data ---(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] enable/disable trigger (Re: Fwd: [HACKERS] Open items)
On Mon, Aug 08, 2005 at 02:13:28PM +0900, Satoshi Nagayasu wrote:
Alvaro Herrera wrote:
+ elog(NOTICE, %d trigger(s) on %s %s.,
+changed,
+NameStr(rel-rd_rel-relname),
+enable ? enabled : disabled);
should really be two messages (Maybe even four: disabled-plural,
disabled-singular, enabled-plural, enabled-singular)
What does really be two messages mean?
I mean you should do this:
if (enabled)
{
if (changed == 1)
ereport(One trigger on %s enabled)
else
ereport(%d triggers on %d enabled)
}
etc.
--
Alvaro Herrera (alvherre[a]alvh.no-ip.org)
I personally became interested in Linux while I was dating an English major
who wouldn't know an operating system if it walked up and bit him.
(Val Henson)
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)
Alvaro Herrera [EMAIL PROTECTED] writes:
What does really be two messages mean?
I mean you should do this:
if (enabled)
{
if (changed == 1)
ereport(One trigger on %s enabled)
else
ereport(%d triggers on %d enabled)
}
This isn't really a gain in localizability because it assumes that there
are only singular and plural forms. I do agree that plugging words like
enabled or disabled into a string is not good style. Please read
the message style guidelines at
http://developer.postgresql.org/docs/postgres/error-style-guide.html
particularly the section about writing localization-friendly messages
http://developer.postgresql.org/docs/postgres/nls-programmer.html#NLS-GUIDELINES
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Autovacuum loose ends
On Sun, Jul 31, 2005 at 07:36:36PM -0400, Alvaro Herrera wrote:
Updated this patch:
- vacuum_cost_delay and vacuum_cost_limit can be set per table, as well
as globally with autovacuum_vacuum_cost_{limit,delay}
- pgstat is reset if recovery is required
- pgstat reset at postmaster start is disabled by default
- Xid-wraparound VACUUM is now FREEZE without ANALYZE, iff the database
has datallowconn=false or datistemplate=true
--
Alvaro Herrera (alvherre[a]alvh.no-ip.org)
No hay cielo posible sin hundir nuestras raíces
en la profundidad de la tierra(Malucha Pinto)
Index: doc/src/sgml/catalogs.sgml
===
RCS file: /home/alvherre/cvs/pgsql/doc/src/sgml/catalogs.sgml,v
retrieving revision 2.110
diff -c -r2.110 catalogs.sgml
*** doc/src/sgml/catalogs.sgml 31 Jul 2005 17:19:16 - 2.110
--- doc/src/sgml/catalogs.sgml 7 Aug 2005 19:03:22 -
***
*** 1197,1202
--- 1197,1216
entryMultiplier for reltuples to add to
structfieldanl_base_thresh//entry
/row
+
+row
+ entrystructfieldvac_cost_delay/structfield/entry
+ entrytypeinteger/type/entry
+ entry/entry
+ entryCustom variablevacuum_cost_delay/ parameter/entry
+/row
+
+row
+ entrystructfieldvac_cost_limit/structfield/entry
+ entrytypeinteger/type/entry
+ entry/entry
+ entryCustom variablevacuum_cost_limit/ parameter/entry
+/row
/tbody
/tgroup
/table
***
*** 1217,1223
para
Any of the numerical fields can contain literal-1/ (or indeed
any negative value) to indicate that the system-wide default should
!be used for this particular value.
/para
/sect1
--- 1231,1241
para
Any of the numerical fields can contain literal-1/ (or indeed
any negative value) to indicate that the system-wide default should
!be used for this particular value. Observe that the
!structfieldvac_cost_delay/ variable inherits its default value from the
!varnameautovacuum_vacuum_cost_delay/ configuration parameter,
!or from varnamevacuum_cost_delay/ if the former is set to a negative
!value. The same applies to structfieldvac_cost_limit/.
/para
/sect1
Index: doc/src/sgml/runtime.sgml
===
RCS file: /home/alvherre/cvs/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.341
diff -c -r1.341 runtime.sgml
*** doc/src/sgml/runtime.sgml 30 Jul 2005 17:15:35 - 1.341
--- doc/src/sgml/runtime.sgml 31 Jul 2005 23:22:11 -
***
*** 3399,3404
--- 3399,3436
/listitem
/varlistentry
+ varlistentry id=guc-autovacuum-vacuum-cost-delay
xreflabel=autovacuum_vacuum_cost_delay
+ termvarnameautovacuum_vacuum_cost_delay/varname
(typeinteger/type)/term
+ indexterm
+primaryvarnameautovacuum_vacuum_cost_delay/ configuration
parameter/primary
+ /indexterm
+ listitem
+para
+ Specifies the default value that will be applied to each
+ commandVACUUM/ operation, for tables that do not have
+ a default value set in structnamepg_autovacuum/. If a
+ negative value is specified (like the default value of -1),
+ the varnamevacuum_cost_delay/ value will be applied instead.
+/para
+ /listitem
+ /varlistentry
+
+ varlistentry id=guc-autovacuum-cost-limit
xreflabel=autovacuum_vacuum_cost_limit
+ termvarnameautovacuum_vacuum_cost_limit/varname
(typeinteger/type)/term
+ indexterm
+primaryvarnameautovacuum_vacuum_cost_limit/ configuration
parameter/primary
+ /indexterm
+ listitem
+para
+ Specifies the default value that will be applied to each
+ commandVACUUM/ operation, for tables that do not have
+ a default value set in structnamepg_autovacuum/. If a
+ negative value is specified (like the default value of -1),
+ the varnamevacuum_cost_limit/ value will be applied instead.
+/para
+ /listitem
+ /varlistentry
+
/variablelist
/sect2
Index: src/backend/access/transam/xlog.c
===
RCS file: /home/alvherre/cvs/pgsql/src/backend/access/transam/xlog.c,v
retrieving revision 1.214
diff -c -r1.214 xlog.c
*** src/backend/access/transam/xlog.c 30 Jul 2005 14:15:44 - 1.214
--- src/backend/access/transam/xlog.c 31 Jul 2005 21:36:45 -
***
*** 33,38
--- 33,39
#include catalog/catversion.h
#include catalog/pg_control.h
#include miscadmin.h
+ #include pgstat.h
#include postmaster/bgwriter.h
#include storage/bufpage.h
#include storage/fd.h
***
*** 48,54
/*
! *Becauase O_DIRECT bypasses the kernel buffers, and
Re: [PATCHES] Implementing SELECT FOR UPDATE [NOWAIT]
Patch applied by Tom. Thanks. --- Karel Zak wrote: This is new version of SELECT FOR UPDATE NOWAIT patch. Karel On Sat, 2005-06-25 at 08:40 +0200, Hans-Juergen Schoenig wrote: yes, i think we can do it in time. regards, hans Bruce Momjian wrote: Are you working on a updated version of this? --- Bruce Momjian wrote: Uh, seems the code has drifted too much and now I can't apply this. Would you redo this against current CVS? Thanks. --- Hans-Juergen Schoenig wrote: Folks, We have implemented SELECT FOR UPDATE NOWAIT for PostgreSQL. -- Karel Zak [EMAIL PROTECTED] [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] PL/pgSQL: SELECT INTO EXACT
On Fri, 2005-07-29 at 17:52 -0400, Tom Lane wrote: Matt Miller [EMAIL PROTECTED] writes: This patch implements an optional EXACT keyword after the INTO keyword of the PL/pgSQL SELECT INTO command. ... when SELECTing INTO ... leave the targets untouched if the query does not return exactly one row. I dislike the choice of EXACT, too, as it (a) adds a new reserved word and (b) doesn't seem to convey quite what is happening anyway. Not sure about a better word though ... anyone? I don't know how to avoid adding a keyword, unless the proposed EXACT behavior just replaces the current behavior, potentially breaking existing code. Is there a precedent for language-specific GUC vars? I think the EXACT behavior is more reasonable overall, and maybe a stepped approach can replace the current behavior with the EXACT flavor. To that end the option could support either EXACT or NOEXACT, with NOEXACT initially being the default. Eventually EXACT could become the default, and finally the NOEXACT option could be dropped altogether. At that point the EXACT keyword would be dropped as well. I can attach a patch that supports [EXACT | NOEXACT]. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] PL/pgSQL: SELECT INTO EXACT
Matt Miller [EMAIL PROTECTED] writes: On Fri, 2005-07-29 at 17:52 -0400, Tom Lane wrote: I dislike the choice of EXACT, too, as it (a) adds a new reserved word and (b) doesn't seem to convey quite what is happening anyway. Not sure about a better word though ... anyone? I can attach a patch that supports [EXACT | NOEXACT]. Somehow, proposing two new reserved words instead of one doesn't seem very responsive to my gripe :-(. If you think that this should be a global option instead of a per-statement one, something like the (undocumented) #option hack might be a good way to specify it; that would give it per-function scope, which seems reasonable. create function myfn(...) returns ... as $$ #option select_into_1_row declare ... $$ language plpgsql; 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] PL/pgSQL: SELECT INTO EXACT
On Mon, 2005-08-08 at 17:18 -0400, Tom Lane wrote: Matt Miller [EMAIL PROTECTED] writes: On Fri, 2005-07-29 at 17:52 -0400, Tom Lane wrote: I dislike the choice of EXACT, too, as it (a) adds a new reserved word and (b) doesn't seem to convey quite what is happening anyway. Not sure about a better word though ... anyone? I can attach a patch that supports [EXACT | NOEXACT]. Somehow, proposing two new reserved words instead of one doesn't seem very responsive to my gripe :-(. My intention was to introduce the idea that the current behavior should be changed, and to then suggest a path that eventually eliminates all the new reserved words. If you think that this should be a global option instead of a per-statement one, something like the (undocumented) #option hack might be a good way to specify it; that would give it per-function scope, which seems reasonable. create function myfn(...) returns ... as $$ #option select_into_1_row declare ... $$ language plpgsql; Thanks, I'll take a look at this. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] enable/disable trigger (Re: Fwd: [HACKERS] Open items)
This isn't really a gain in localizability because it assumes that there are only singular and plural forms. I do agree that plugging words like enabled or disabled into a string is not good style. Please read the message style guidelines at http://developer.postgresql.org/docs/postgres/error-style-guide.html particularly the section about writing localization-friendly messages http://developer.postgresql.org/docs/postgres/nls-programmer.html#NLS-GUIDELINES I did not know about this. I'll check my code for this style. Thanks. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(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] PL/pgSQL: SELECT INTO EXACT
Matt Miller [EMAIL PROTECTED] writes: I can attach a patch that supports [EXACT | NOEXACT]. Somehow, proposing two new reserved words instead of one doesn't seem very responsive to my gripe :-(. My intention was to introduce the idea that the current behavior should be changed, and to then suggest a path that eventually eliminates all the new reserved words. Once you put 'em in, you can't ever really get rid of 'em :-( ... so I'd prefer to investigate a path that doesn't use that syntax in the first place. 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
Re: [PATCHES] prevent encoding conversion recursive error
Qingqing Zhou [EMAIL PROTECTED] writes: Yeah, it is not a very clean solution. Do you mean the general problem is prevent recursive error reporting because of the error in transalting error message? I put the image of the reporting email here: http://www.cs.toronto.edu/~zhouqq/encode.jpg Actually, I believe the general problem is that the gettext software is doing the wrong internal character-set conversion for translated message texts. I can get this same crash on a Linux machine if I have server encoding = utf8 and client encoding = gb18030 and I set lc_messages = zh_TW ... but if I instead make lc_messages = zh_CN, no problem. The backend zh_TW.po file contains msgid ignoring unconvertible UTF-8 character 0x%04x msgstr 忽ç¥ç¡æ³è½æçUTF-8åå 0x%04x and if I read the header correctly, this is claimed to be in UTF8 encoding. So it ought to be delivered as-is when in a UTF8 database. But tracing through the failure with gdb, I see that what is actually delivered back from gettext() is (gdb) p str $1 = 0x82e8a74 ºöÂÔ?·¨??µÄUTF-8×ÖÔª0xd4da (gdb) x/32cx str 0x82e8a74: 0xba0xf60xc20xd40x3f0xb70xa80x3f 0x82e8a7c: 0x3f0xb50xc40x550x540x460x2d0x38 0x82e8a84: 0xd70xd60xd40xaa0x300x780x640x34 0x82e8a8c: 0x640x610x000x7e0x7f0x7f0x7f0x7f (gdb) so some sort of conversion has taken place. I had initially initialized the database with initdb --locale=zh_CN, which was interpreted by Postgres as requesting EUC_CN encoding. I suspect the above is the EUC_CN equivalent of the message text from the .po file, and that the real problem is that gettext() has not been told the correct character set to convert messages to. ISTM we've seen this issue before and Peter had an idea how to fix it, but I forget the details. Peter? 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] prevent encoding conversion recursive error
I wrote: ...real problem is that gettext() has not been told the correct character set to convert messages to. ISTM we've seen this issue before and Peter had an idea how to fix it, but I forget the details. Peter? A little bit of digging in the list archives located http://archives.postgresql.org/pgsql-hackers/2003-11/msg01299.php in which Peter opines : - lc_collate and lc_ctype need to be held fixed in the entire cluster. : : - Gettext relies on iconv character set conversion, which relies on : lc_ctype, which leads to a complete screw-up in the server because of : the previous item. which seems to fit with my observation: the message texts are being converted to the cluster's original encoding rather than the encoding that's active in the current database. This does not look real easy to fix. Who's up for reimplementing gettext and a few other pieces from scratch? There is a separate line of thought here, which is that we are unlikely ever to get this completely perfect, and so it'd be good if errors during error processing didn't lead to recursion and PANIC. I don't have an idea how to solve that one either. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] prevent encoding conversion recursive error
I wrote: This does not look real easy to fix. Who's up for reimplementing gettext and a few other pieces from scratch? However, I did find http://gnu.miscellaneousmirror.org/software/libc/manual/html_node/Charset-conversion-in-gettext.html#Charset-conversion-in-gettext which leads to the question why aren't we using bind_textdomain_codeset() to tell gettext what character set it should produce? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[PATCHES] Allow WAL information to recover corrupted pg_controldata patch
Hi All The patch had been posted at hacker list for review, no comments until now. I had added an option -r to pg_resetxlog to enable the tool can rebuild thecorrupted pg_control file from the old xlog files. here is the link:http://www.geocities.com/yuanjia_pg/pg_resetxlog.diff.txt There are also some changes in the logic of other options.Option -n: only print out the control values in the existing pg_control file, if the file is corrupted , inform the use to rebuild it first only.Option -f: if pg_control file is fine, then reset the xlog file; if pg_control is corrupted , then try to rebuild the control file from old xlog file, if it fails, then just guessing the value, then reset the xlog file. The algorithm of restoring the pg_control value from old xlog file:1. Retrieve all of the active xlog files from xlog directory into a list by increasing order, according their timeline, log id, segment id. (Tom had informed me that we can not know which segment file is latest just by the name itself, so before adding the segment file to the list, it should be checked that it is an active segment file.)2. Search the list to find the oldest xlog file of the latest time line. (Although it is better to let the user to select the time line which is used for rebuild the xlog file, but I think there is not so necessary. I had tried to use only the last file in the latest time line, but I found that in many cases, there are possible that the last checkpoint record and the previous checkpoint record are stored separately in different segment file, so I had to search from the oldest one.)3. Search the records from the oldest xlog file of latest time line to the latest xlog file of latest time line, if the checkpoint record has been found, update the latest checkpoint and previous checkpoint. Some of the code is borrowed from Tom Lane xlogdump.c file. Hope for your advice. Best RegardsYuanjia Lee Start your day with Yahoo! - make it your home page
[PATCHES] Fix oversight in pts_error_callback()
Since we will invoke callback functions unconditionally in errfinish(), so
pts_error_callback() should not report invalid type name without checking
current error status.
Regards,
Qingqing
Index: src/backend/parser/parse_type.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/parser/parse_type.c,v
retrieving revision 1.76
diff -c -r1.76 parse_type.c
*** src/backend/parser/parse_type.c 1 Aug 2005 20:31:10 - 1.76
--- src/backend/parser/parse_type.c 9 Aug 2005 05:53:08 -
***
*** 359,373
pts_error_callback(void *arg)
{
const char *str = (const char *) arg;
!
! errcontext(invalid type name \%s\, str);
/*
* Currently we just suppress any syntax error position report,
rather
* than transforming to an internal query error. It's
unlikely that
* a type name is complex enough to need positioning.
*/
! errposition(0);
}
/*
--- 359,379
pts_error_callback(void *arg)
{
const char *str = (const char *) arg;
! int syntaxerrposition;
/*
* Currently we just suppress any syntax error position report,
rather
* than transforming to an internal query error. It's
unlikely that
* a type name is complex enough to need positioning.
*/
! syntaxerrposition = geterrposition();
! if (syntaxerrposition 0)
! {
! errcontext(invalid type name \%s\, str);
! errposition(0);
! }
! else
! errcontext(parse type string \%s\, str);
}
/*
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
