Re: [HACKERS] autovacuum and reloptions
On Fri, Feb 6, 2009 at 5:45 PM, Euler Taveira de Oliveira wrote: > Alvaro Herrera escreveu: >>> (ii) I think we should change the expression "storage parameters" for >>> something else because autovacuum is related to maintenance. My suggestion >>> is >>> a general expression like "relation parameters"; >> >> I'm not sure I agree with this idea, because the term "storage >> parameter" has been used for several releases already. This would be a >> relatively major terminology change. >> > I don't buy your argument. 'fillfactor' is a _storage_ parameter but > 'autovacuum_enabled' is not. I don't like terminology changes too but in this > case it sounds strange calling autovacuum_* as storage parameters. > +1 -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Column-Level Privileges
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > [ column privs cleanup patch ] > > Applied with revisions, as per previous messages. Great, thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] new GUC var: autovacuum_process_all_tables
Alvaro, On the other hand, I'd been keen on a runtime suset autovaccum=on/off which we could call from a cron job or the pgadmin scheduler in order to have maintenance windows. Unless that's already becoming possible? autovacuum=on/off is already SIGHUP as of 8.3 (not SUSET, since it makes no sense to change it in a single connection). Right. What I'm saying is that if it *didn't* require a sighup, then users could cronjob starting and stopping Autovac themselves. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autovacuum and reloptions
Alvaro Herrera escreveu: >> (ii) I think we should change the expression "storage parameters" for >> something else because autovacuum is related to maintenance. My suggestion is >> a general expression like "relation parameters"; > > I'm not sure I agree with this idea, because the term "storage > parameter" has been used for several releases already. This would be a > relatively major terminology change. > I don't buy your argument. 'fillfactor' is a _storage_ parameter but 'autovacuum_enabled' is not. I don't like terminology changes too but in this case it sounds strange calling autovacuum_* as storage parameters. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
On Mon, 2009-01-19 at 21:41 +0300, Teodor Sigaev wrote: > > gin_numeric_cmp() can be called from regular SQL. I missed this before, > > but that function will segfault if you call gin_numeric_cmp(NULL, 1) (in > > v0.7 at least). > > Fixed, gin_numeric_cmp is marked as strict. > > > And how does GIN handle SQL NULL values in the column? Does it index > > them at all, or just ignore them? > SQL NULL: GIN doesn't support it (amindexnulls/amsearchnulls == false) > C NULL: NULL-numeric could be returned only by gin_extract_query_numeric > which > cannot be called by user directly because of internal type of argument. > GIN doesn't do anything with values returned by gin_extract_query_numeric > except > providing they as an argument for comparing functions. Looking through the code again, gin_compare_prefix_##type looks a little confusing. Is there a reason for using: (data->strategy == BTLessStrategyNumber || data->strategy == BTLessEqualStrategyNumber ) ? PointerGetDatum(data->datum) : a rather than just using: PointerGetDatum(data->datum) Also, it might be a little less confusing if you used two separate variables rather than using "res" for two purposes. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] KOI8-U support (was Re: [BUGS] create database warning)
> diff -Nur ../cvs-pgsql/src/backend/utils/mb/wchar.c
> ./src/backend/utils/mb/wchar.c
> --- ../cvs-pgsql/src/backend/utils/mb/wchar.c 2009-01-30 10:35:27.0
> +0200
> +++ ./src/backend/utils/mb/wchar.c2009-02-06 18:19:48.0 +0200
> @@ -1373,6 +1373,7 @@
> {pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen,
> pg_latin1_verifier, 1}, /* 31; PG_WIN1254 */
> {pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen,
> pg_latin1_verifier, 1}, /* 32; PG_WIN1255 */
> {pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen,
> pg_latin1_verifier, 1}, /* 33; PG_WIN1257 */
> + {pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen,
> pg_latin1_verifier, 1}, /* 34; PG_KOI8U */
> {0, pg_sjis_mblen, pg_sjis_dsplen, pg_sjis_verifier, 2},/* 34;
> PG_SJIS */
> {0, pg_big5_mblen, pg_big5_dsplen, pg_big5_verifier, 2},/* 35;
> PG_BIG5 */
> {0, pg_gbk_mblen, pg_gbk_dsplen, pg_gbk_verifier, 2}, /* 36;
> PG_GBK */
I'm not convinced that putting the encoding numbers in these comments
is useful; if it is you need to update them. Or we could just remove
them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Column-Level Privileges
Stephen Frost writes: > [ column privs cleanup patch ] Applied with revisions, as per previous messages. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Review: B-Tree emulation for GIN
On Wed, 2009-02-04 at 20:22 +0300, Teodor Sigaev wrote: > > The description of extractQuery's extra_data parameter seems confusing > > too. AFAICS it is incorrect, or at least misleading, to describe it as > > void ** extra_data[]; it is really void ***extra_data, because there is > > only one object there not an array. > > It's really array, see fillScanKey() in ginscan.c, line 61 of patched file. > extractQuery could provide data for each returned key. > If I understand correctly, the extra_data parameter to extractQuery() should mean "a pointer to an array of void*". "void **extra_data[]" might be misinterpreted as "an array of void**". Would "void *(*extra_data)[]" be more descriptive? I'm not an expert on style questions like this, but it seems to match the parameter lists for comparePartial() and consistent(). "void ***extra_data" seems reasonable, too. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
Andrew Chernow wrote: > Bruce Momjian wrote: > > Andrew Chernow wrote: > >> Andrew Chernow wrote: > >>> Tom Lane wrote: > Andrew Chernow writes: > > I can try. Where should this be documented? ISTM that the best > > place is at the top of "30.1 Database Connection Control Functions", > > since the issue pertains to any connect/disconnect function. Does > > that sound correct? Should it be a warning or just regular text? > Minor platform-specific performance nits are not that important. Think > "footnote", not "warning at the top of the page". > > >>> Its a footnote at the end of the first paragraph in 30.1. > >> Fixed a few things. > > > > I have applied a modified version of this documentation patch, attached. > > Thanks. > > > > "connection is repeated started and shutdown." > > "repeated" should be "repeatedly". Thanks, fixed. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
On Feb 6, 2009, at 9:43 AM, Bruce Momjian wrote: Oh. That seems kind of odd?can you hang onto the patch until 8.4 is released, then? This must happen all the time, no? OK, I will hang on to it, but I will have to mention it is only in 8.4 too. Ah, yeah, I didn't put that in the patch… Thanks! David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
Bruce Momjian wrote: Andrew Chernow wrote: Andrew Chernow wrote: Tom Lane wrote: Andrew Chernow writes: I can try. Where should this be documented? ISTM that the best place is at the top of "30.1 Database Connection Control Functions", since the issue pertains to any connect/disconnect function. Does that sound correct? Should it be a warning or just regular text? Minor platform-specific performance nits are not that important. Think "footnote", not "warning at the top of the page". Its a footnote at the end of the first paragraph in 30.1. Fixed a few things. I have applied a modified version of this documentation patch, attached. Thanks. "connection is repeated started and shutdown." "repeated" should be "repeatedly". -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] libpq WSACleanup is not needed
Andrew Chernow wrote: > Andrew Chernow wrote: > > Tom Lane wrote: > >> Andrew Chernow writes: > >>> I can try. Where should this be documented? ISTM that the best > >>> place is at the top of "30.1 Database Connection Control Functions", > >>> since the issue pertains to any connect/disconnect function. Does > >>> that sound correct? Should it be a warning or just regular text? > >> > >> Minor platform-specific performance nits are not that important. Think > >> "footnote", not "warning at the top of the page". > >> > > Its a footnote at the end of the first paragraph in 30.1. > > Fixed a few things. I have applied a modified version of this documentation patch, attached. Thanks. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/libpq.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.275 diff -c -c -r1.275 libpq.sgml *** doc/src/sgml/libpq.sgml 10 Jan 2009 20:14:30 - 1.275 --- doc/src/sgml/libpq.sgml 6 Feb 2009 18:17:55 - *** *** 63,68 --- 63,83 The PQstatus function should be called to check whether a connection was successfully made before queries are sent via the connection object. + + + + On Windows, there is a way to improve performance if a single + database connection is repeated started and shutdown. Internally, + libpq calls WSAStartup() and WSACleanup() for connection startup + and shutdown, respectively. WSAStartup() increments an internal + Windows library reference count which is decremented by WSACleanup(). + When the reference count is just one, calling WSACleanup() frees + all resources and all DLLs are unloaded. This is an expensive + operation. To avoid this, an application can manually call + WSAStartup() so resources will not be freed when the last database + connection is closed. + + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] new GUC var: autovacuum_process_all_tables
Ron Mayer wrote: > Joshua D. Drake wrote: > >> The main remaining use-case seems to me to make vacuuming work adhere > >> to some business-determined schedule, hence maintenance windows seem > >> like the next thing to do. > > Also agreed. > > Somewhat agreed - since in many cases the business-determined schedule > is just a rough estimate of measurable attributes of the machine. When > we say "vacuum between midnight and 5am" we often actually mean "vacuum > when the I/O subsystem has bandwidth to spare and the machine's otherwise > lightly loaded, and we guess that means late at night". The current state of the system is not necessarily a good indicator of the immediately future state. If we were to collect history (I/O load versus time of day and day of week) that would be another matter, but I'm not sure that's a productive use of our development time. If we could guess what's going to be the load of the server in the near future, that would help scheduling considerable. Since we can't, we have to trust that the user can provide an educated guess, which is what "maintenance windows" are all about. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A single escape required for log_filename
On Fri, Feb 6, 2009 at 12:44 PM, Bruce Momjian wrote: > Peter Eisentraut wrote: >> On Wednesday 14 January 2009 05:23:53 Tom Lane wrote: >> > However, since there's no standard strftime escape for epoch, >> > Robert's proposal to rip out the functionality would break any existing >> > code that still depends on this formatting option. >> >> If it came down to this, then I'd say rip it out. Naming log files by epoch >> isn't exactly a user-friendly practice anyway, and there are equivalent but >> more readable formatting options available. > > Are we doing anything about this for 8.4? The patch is trivial and unlikely to break anything, but Tom wasn't sure it made sense to change the behavior. I believe he's in the minority, though. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
On Feb 6, 2009, at 9:12 AM, Bruce Momjian wrote: Quick patch to mention CITEXT in the parts of the FAQ that discuss case-insensitive comparisons. I think it is too early to mention /contrib/citext in the FAQ because 8.4 is not released yet. Oh, is the FAQ on the site built from CVS tip? Is there not a branch for 8.3 from which it's built? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] A single escape required for log_filename
Peter Eisentraut wrote: > On Wednesday 14 January 2009 05:23:53 Tom Lane wrote: > > However, since there's no standard strftime escape for epoch, > > Robert's proposal to rip out the functionality would break any existing > > code that still depends on this formatting option. > > If it came down to this, then I'd say rip it out. Naming log files by epoch > isn't exactly a user-friendly practice anyway, and there are equivalent but > more readable formatting options available. Are we doing anything about this for 8.4? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
David E. Wheeler wrote: > On Feb 6, 2009, at 9:33 AM, Bruce Momjian wrote: > > >> Oh, is the FAQ on the site built from CVS tip? Is there not a branch > >> for 8.3 from which it's built? > > > > There are FAQ's in each branch, but the one that is put on the web > > site > > is from CVS HEAD. > > Oh. That seems kind of odd?can you hang onto the patch until 8.4 is > released, then? This must happen all the time, no? OK, I will hang on to it, but I will have to mention it is only in 8.4 too. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] new GUC var: autovacuum_process_all_tables
Joshua D. Drake wrote: > On Thu, 2009-02-05 at 17:08 -0500, Tom Lane wrote: >> My feeling is that we should be trying to eliminate use-cases for >> cron-driven vacuuming, not trying to make sure that cron-driven >> scripts can do anything autovacuum can. > Agreed. IMO, the user should only have to think about "vacuum" in an > abstract sense. +1 >> The main remaining use-case seems to me to make vacuuming work adhere >> to some business-determined schedule, hence maintenance windows seem >> like the next thing to do. > Also agreed. Somewhat agreed - since in many cases the business-determined schedule is just a rough estimate of measurable attributes of the machine. When we say "vacuum between midnight and 5am" we often actually mean "vacuum when the I/O subsystem has bandwidth to spare and the machine's otherwise lightly loaded, and we guess that means late at night". -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] autovacuum and reloptions
Euler Taveira de Oliveira escribió: > (i) I don't like this construction "by entries by changing storage > parameters". I prefer "by changing storage parameters" or "by entries in > pg_class.reloptions"; Heh, obvious "by entries by" is a cut'n'pasto; fixed. Maybe an xref would be better there. I attach the doc patch again; I fiddled a bit with it this morning. Comments? > (ii) I think we should change the expression "storage parameters" for > something else because autovacuum is related to maintenance. My suggestion is > a general expression like "relation parameters"; I'm not sure I agree with this idea, because the term "storage parameter" has been used for several releases already. This would be a relatively major terminology change. > (iii) I noticed that GUC defaults and relopt defaults are different > (autovacuum_cost_delay and autovacuum_cost_limit). Is there any reason for not > using -1? Yeah, -1 does not make sense. It made sense in pg_autovacuum because otherwise you didn't have to specify "skip this setting and use the default". In reloptions, if you don't want to specify the setting, just don't specify it. > (iv) Maybe we should document that pg_dump will only dump reloptions like > toast.foo iff the relation has an associated TOAST table. This seems obvious > but ... Well, if it doesn't have a toast table, then there's no need for toast settings, is there? I mean, you could construe it as a gotcha: if you CREATE TABLE with only fixed-length columns and specify some reloptions, and later add a column that requires a toast table, it won't have the options you set at CREATE time. However, it seems to me to be very low in the importance scale. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. *** doc/src/sgml/catalogs.sgml 4 Feb 2009 21:30:41 - 2.194 --- doc/src/sgml/catalogs.sgml 5 Feb 2009 18:32:40 - *** *** 89,99 - pg_autovacuum - per-relation autovacuum configuration parameters - - - pg_cast casts (data type conversions) --- 89,94 *** *** 1256,1433 - - pg_autovacuum - - -pg_autovacuum - - - -autovacuum -table-specific configuration - - - -The catalog pg_autovacuum stores optional -per-relation configuration parameters for the autovacuum daemon. -If there is an entry here for a particular relation, the given -parameters will be used for autovacuuming that table. If no entry -is present, the system-wide defaults will be used. For more information -about the autovacuum daemon, see . - - - - - It is likely that pg_autovacuum will disappear - in a future release, with the information instead being kept in - pg_class.reloptions entries. - - - - -pg_autovacuum Columns - - - - - Name - Type - References - Description - - - - - - vacrelid - oid - pg_class.oid - The table this entry is for - - - - enabled - bool - - If false, this table will not be autovacuumed, except -to prevent transaction ID wraparound - - - - vac_base_thresh - integer - - Minimum number of modified tuples before vacuum - - - - vac_scale_factor - float4 - - Multiplier for reltuples to add to -vac_base_thresh - - - - anl_base_thresh - integer - - Minimum number of modified tuples before analyze - - - - anl_scale_factor - float4 - - Multiplier for reltuples to add to -anl_base_thresh - - - - vac_cost_delay - integer - - Custom vacuum_cost_delay parameter - - - - vac_cost_limit - integer - - Custom vacuum_cost_limit parameter - - - - freeze_min_age - integer - - Custom vacuum_freeze_min_age parameter - - - - freeze_max_age - integer - - Custom autovacuum_freeze_max_age parameter - - - - freeze_table_age - integer - - Custom vacuum_freeze_table_age parameter - - - - - - -The autovacuum daemon will initiate a VACUUM operation -on a particular table when the number of updated or deleted tuples -exceeds vac_base_thresh plus -vac_scale_factor times the number of -live tuples currently estimated to be in the relation. -Similarly, it will initiate an ANALYZE operation -when the number of inserted, updated or deleted tuples -exceeds anl_base_thresh plus -anl_scale_factor times the number of -live tuples currently estimated to be in the relation. - - - -Also, the autovacuum daemon
[HACKERS] KOI8-U support (was Re: [BUGS] create database warning)
Peter Eisentraut wrote:
Mykola Stryebkov wrote:
template1=# create database inf with encoding 'windows-1251';
WARNING: could not determine encoding for locale "uk_UA.KOI8-U":
codeset is "KOI8-U"
DETAIL: Please report this to .
CREATE DATABASE
template1=#
What's wrong with it?
PostgreSQL does not support the KOI8-U encoding. You could try to use
uk_UA.utf8.
We get these complaints about missing KOI8-U support once in a while.
Attached is a patch to add KOI8-U support with UTF-8 conversion. It
should be enough to help this class of users, but more fancy features
such as conversion between KOI8U and KOI8R or KOI8U and various WIN
encodings is not there yet. I propose to add this patch to PostgreSQL 8.4.
Mykola, if you have a 8.3 or 8.4 source code lying around, please test
this patch.
diff -Nur ../cvs-pgsql/doc/src/sgml/charset.sgml ./doc/src/sgml/charset.sgml
--- ../cvs-pgsql/doc/src/sgml/charset.sgml 2008-10-02 10:50:13.0 +0300
+++ ./doc/src/sgml/charset.sgml 2009-02-06 18:26:09.0 +0200
@@ -457,12 +457,20 @@
- KOI8
- KOI8-R(U)
- Cyrillic
+ KOI8R
+ KOI8-R
+ Cyrillic (Russian)
Yes
1
- KOI8R
+ KOI8
+
+
+ KOI8U
+ KOI8-U
+ Cyrillic (Ukrainian)
+ Yes
+ 1
+
LATIN1
diff -Nur ../cvs-pgsql/src/backend/utils/mb/conversion_procs/Makefile ./src/backend/utils/mb/conversion_procs/Makefile
--- ../cvs-pgsql/src/backend/utils/mb/conversion_procs/Makefile 2008-08-23 23:31:37.0 +0300
+++ ./src/backend/utils/mb/conversion_procs/Makefile 2009-02-06 19:03:20.0 +0200
@@ -84,6 +84,8 @@
utf8_to_big5 UTF8 BIG5 utf8_to_big5 utf8_and_big5 \
utf8_to_koi8_r UTF8 KOI8R utf8_to_koi8r utf8_and_cyrillic \
koi8_r_to_utf8 KOI8R UTF8 koi8r_to_utf8 utf8_and_cyrillic \
+ utf8_to_koi8_u UTF8 KOI8U utf8_to_koi8u utf8_and_cyrillic \
+ koi8_u_to_utf8 KOI8U UTF8 koi8u_to_utf8 utf8_and_cyrillic \
utf8_to_windows_866 UTF8 WIN866 utf8_to_win utf8_and_win \
windows_866_to_utf8 WIN866 UTF8 win_to_utf8 utf8_and_win \
utf8_to_windows_874 UTF8 WIN874 utf8_to_win utf8_and_win \
diff -Nur ../cvs-pgsql/src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/utf8_and_cyrillic.c ./src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/utf8_and_cyrillic.c
--- ../cvs-pgsql/src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/utf8_and_cyrillic.c 2009-01-30 10:35:27.0 +0200
+++ ./src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/utf8_and_cyrillic.c 2009-02-06 19:20:06.0 +0200
@@ -16,15 +16,23 @@
#include "mb/pg_wchar.h"
#include "../../Unicode/utf8_to_koi8r.map"
#include "../../Unicode/koi8r_to_utf8.map"
+#include "../../Unicode/utf8_to_koi8u.map"
+#include "../../Unicode/koi8u_to_utf8.map"
PG_MODULE_MAGIC;
PG_FUNCTION_INFO_V1(utf8_to_koi8r);
PG_FUNCTION_INFO_V1(koi8r_to_utf8);
+PG_FUNCTION_INFO_V1(utf8_to_koi8u);
+PG_FUNCTION_INFO_V1(koi8u_to_utf8);
+
extern Datum utf8_to_koi8r(PG_FUNCTION_ARGS);
extern Datum koi8r_to_utf8(PG_FUNCTION_ARGS);
+extern Datum utf8_to_koi8u(PG_FUNCTION_ARGS);
+extern Datum koi8u_to_utf8(PG_FUNCTION_ARGS);
+
/* --
* conv_proc(
* INTEGER, -- source encoding id
@@ -65,3 +73,33 @@
PG_RETURN_VOID();
}
+
+Datum
+utf8_to_koi8u(PG_FUNCTION_ARGS)
+{
+ unsigned char *src = (unsigned char *) PG_GETARG_CSTRING(2);
+ unsigned char *dest = (unsigned char *) PG_GETARG_CSTRING(3);
+ int len = PG_GETARG_INT32(4);
+
+ CHECK_ENCODING_CONVERSION_ARGS(PG_UTF8, PG_KOI8U);
+
+ UtfToLocal(src, dest, ULmapKOI8U, NULL,
+ sizeof(ULmapKOI8U) / sizeof(pg_utf_to_local), 0, PG_KOI8U, len);
+
+ PG_RETURN_VOID();
+}
+
+Datum
+koi8u_to_utf8(PG_FUNCTION_ARGS)
+{
+ unsigned char *src = (unsigned char *) PG_GETARG_CSTRING(2);
+ unsigned char *dest = (unsigned char *) PG_GETARG_CSTRING(3);
+ int len = PG_GETARG_INT32(4);
+
+ CHECK_ENCODING_CONVERSION_ARGS(PG_KOI8U, PG_UTF8);
+
+ LocalToUtf(src, dest, LUmapKOI8U, NULL,
+ sizeof(LUmapKOI8U) / sizeof(pg_local_to_utf), 0, PG_KOI8U, len);
+
+ PG_RETURN_VOID();
+}
diff -Nur ../cvs-pgsql/src/backend/utils/mb/encnames.c ./src/backend/utils/mb/encnames.c
--- ../cvs-pgsql/src/backend/utils/mb/encnames.c 2007-11-15 23:14:40.0 +0200
+++ ./src/backend/utils/mb/encnames.c 2009-02-06 18:18:28.0 +0200
@@ -123,6 +123,9 @@
"koi8r", PG_KOI8R
}, /* KOI8-R; RFC1489 */
{
+ "koi8u", PG_KOI8U
+ }, /* KOI8-U; RFC2319 */
+ {
"latin1", PG_LATIN1
}, /* alias for ISO-8859-1 */
{
@@ -366,7 +369,7 @@
"WIN874", PG_WIN874
},
{
- "KOI8", PG_KOI8R
+ "KOI8R", PG_KOI8R
},
{
"WIN1251", PG_WIN1251
@@ -402,6 +405,9 @@
"WIN1257", PG_WIN1257
},
{
+ "KOI8U", PG_KOI8U
+ },
+ {
"SJIS", PG_SJIS
},
{
diff -Nur ../cvs-pgsql/src/backend/utils/mb/Unicode/koi8u_to_utf8.map ./src/backend/utils/mb/Unicode/koi8u_to_utf8.map
--- ../cvs-pgsql/src/backen
Re: [HACKERS] Mention CITEXT in the FAQ
On Feb 6, 2009, at 9:12 AM, Bruce Momjian wrote: Quick patch to mention CITEXT in the parts of the FAQ that discuss case-insensitive comparisons. I think it is too early to mention /contrib/citext in the FAQ because 8.4 is not released yet. Oh, is the FAQ on the site built from CVS tip? Is there not a branch for 8.3 from which it's built? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
On Feb 6, 2009, at 9:33 AM, Bruce Momjian wrote: Oh, is the FAQ on the site built from CVS tip? Is there not a branch for 8.3 from which it's built? There are FAQ's in each branch, but the one that is put on the web site is from CVS HEAD. Oh. That seems kind of odd…can you hang onto the patch until 8.4 is released, then? This must happen all the time, no? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
David E. Wheeler wrote: > On Feb 6, 2009, at 9:12 AM, Bruce Momjian wrote: > > >> Quick patch to mention CITEXT in the parts of the FAQ that discuss > >> case-insensitive comparisons. > > > > I think it is too early to mention /contrib/citext in the FAQ because > > 8.4 is not released yet. > > Oh, is the FAQ on the site built from CVS tip? Is there not a branch > for 8.3 from which it's built? There are FAQ's in each branch, but the one that is put on the web site is from CVS HEAD. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] new GUC var: autovacuum_process_all_tables
Josh Berkus wrote: > I can't imagine, nor have I encountered in the 3 years of consulting I > did since Autovaccum became available, such a use case. Ok, so due to popular demand, I'm not implementing this new GUC. > On the other hand, I'd been keen on a runtime suset autovaccum=on/off > which we could call from a cron job or the pgadmin scheduler in order to > have maintenance windows. Unless that's already becoming possible? autovacuum=on/off is already SIGHUP as of 8.3 (not SUSET, since it makes no sense to change it in a single connection). -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] So, what locale should the regression tests run in?
Peter Eisentraut wrote:
> While regress/GNUmakefile appears to make an effort to run the regressions
> tests with or without locale depending on the users choice, .e.g.,
>
> # locale
> NOLOCALE =
> ifdef NO_LOCALE
> NOLOCALE += --no-locale
> endif
>
> the pg_regress.c implementation spoils that completely by unconditionally
> unsetting all locale-related environment variables before initdb. One part
> of the code doesn't know what the other is doing here.
>
> To make it work as designed in GNUmakefile, the patch below would have to
> be applied.
>
> This leaves the question, what should really be the default behavior?
Has this been resolved?
---
>
>
> diff -u -3 -p -r1.57 pg_regress.c
> --- src/test/regress/pg_regress.c 8 Jan 2009 20:09:06 - 1.57
> +++ src/test/regress/pg_regress.c 13 Jan 2009 21:53:07 -
> @@ -689,19 +689,22 @@ initialize_environment(void)
> /*
> * Clear out any non-C locale settings
> */
> - unsetenv("LC_COLLATE");
> - unsetenv("LC_CTYPE");
> - unsetenv("LC_MONETARY");
> - unsetenv("LC_MESSAGES");
> - unsetenv("LC_NUMERIC");
> - unsetenv("LC_TIME");
> - unsetenv("LC_ALL");
> - unsetenv("LANG");
> - unsetenv("LANGUAGE");
> - /* On Windows the default locale cannot be English, so force it */
> + if (nolocale)
> + {
> + unsetenv("LC_COLLATE");
> + unsetenv("LC_CTYPE");
> + unsetenv("LC_MONETARY");
> + unsetenv("LC_MESSAGES");
> + unsetenv("LC_NUMERIC");
> + unsetenv("LC_TIME");
> + unsetenv("LC_ALL");
> + unsetenv("LANG");
> + unsetenv("LANGUAGE");
> + /* On Windows the default locale cannot be English, so force
> it */
> #if defined(WIN32) || defined(__CYGWIN__)
> - putenv("LANG=en");
> + putenv("LANG=en");
> #endif
> + }
>
> /*
> * Set multibyte as requested
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] per-database locale: createdb switches
Tom Lane wrote: > Alvaro Herrera writes: > > Heikki Linnakangas wrote: > >> Hmm, I remember I pondered for a long time if it should be COLLATE and > >> CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was > >> that a) COLLATE/CTYPE looks nicer and b) if we add support for ICU or > >> some other collation implementation, the association with LC_* > >> environment variables becomes misleading. > >> > >> Being consistent would be nice, though. > > > I think consistency could be reached by renaming the GUC setting to > > ctype. > > I think this is a bad idea, particularly if you also rename the other > GUC to COLLATE (which is a reserved word that we're going to have to > implement someday). People know what LC_CTYPE and LC_COLLATE do, > at least if they've heard of Unix locale support at all (and if not > they can google those names successfully). > > If we want consistency then the right answer is to rename the *new* > things to lc_xxx, not break compatibility on the names of the > existing things. Is anyone working on resolving this? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [COMMITTERS] pgsql: Implement prefetching via posix_fadvise() for bitmap index scans.
Tom Lane wrote: > Log Message: > --- > Implement prefetching via posix_fadvise() for bitmap index scans. A new > GUC variable effective_io_concurrency controls how many concurrent block > prefetch requests will be issued. > > (The best way to handle this for plain index scans is still under debate, > so that part is not applied yet --- tgl) Where are we on completing this feature? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Mention CITEXT in the FAQ
David E. Wheeler wrote: > Quick patch to mention CITEXT in the parts of the FAQ that discuss > case-insensitive comparisons. I think it is too early to mention /contrib/citext in the FAQ because 8.4 is not released yet. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Python 3.0 does not work with PL/Python
Peter Eisentraut wrote: > I have recently fixed the configure script to recognize Python 3.0. But > note that building and running PL/Python with Python 3.0 does not > actually work. It looks like several symbols have been removed or > changed. It would be good if the Python pundits around here could take > a look. > > (I have found Python 3.0 to be very quick and easy to install from > source, in case your distribution doesn't have it packaged yet.) Any progress on this? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] confirm timezone changes for new releases was Fwd: Re: [pgsql-slavestothewww] New News Entry (id: 1055)
Bruce Momjian writes: > Robert Treat wrote: >> I know that the fedora tzdata-2009a packages have the Argentian changes (as >> well as some others depending on version of fedora), but I'm not sure what >> is >> includedin the original package, or exactly where we pull our changes in >> from >> Note our release notes dont specify those changes, so I am inclined to think >> they aren't in there, but can someone confirm for our release announcement >> if >> 8.3.6 et al have Argentinian timezone updates? (Or any other updates we >> should mention) TIA > The commit messages is: Also, our release notes do so specify the tzdata updates --- it's usually the last item, see for instance http://developer.postgresql.org/pgdocs/postgres/release-8-3-6.html regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] confirm timezone changes for new releases was Fwd: Re: [pgsql-slavestothewww] New News Entry (id: 1055)
On Friday 06 February 2009 10:43:30 Bruce Momjian wrote: > Bruce Momjian wrote: > > Robert Treat wrote: > > > I know that the fedora tzdata-2009a packages have the Argentian changes > > > (as well as some others depending on version of fedora), but I'm not > > > sure what is includedin the original package, or exactly where we pull > > > our changes in from Note our release notes dont specify those changes, > > > so I am inclined to think they aren't in there, but can someone confirm > > > for our release announcement if 8.3.6 et al have Argentinian timezone > > > updates? (Or any other updates we should mention) TIA > > > > The commit messages is: > > > > Update time zone data files to tzdata release 2009a: introduces > > Asia/Kathmandu as the preferred spelling of that zone name, corrects > > historical DST information for Switzerland and Cuba. > > > > We get our data files as mentioned in /pgtop/src/timezone/README: > > > > ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz > > To better answer your specific question, I see Argentina timezone > changes added CVS for in 2008i: > > revision 1.13 > date: 2008/10/30 13:16:52; author: tgl; state: Exp; lines: +91 -16 > Update time zone data files to tzdata release 2008i (DST law changes in > Argentina, Brazil, Mauritius, Syria). > > Those changes would have been included in 8.3.5 released on 2008-11-03. > Thanks Bruce! -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] confirm timezone changes for new releases was Fwd: Re: [pgsql-slavestothewww] New News Entry (id: 1055)
Bruce Momjian wrote: > Robert Treat wrote: > > I know that the fedora tzdata-2009a packages have the Argentian changes (as > > well as some others depending on version of fedora), but I'm not sure what > > is > > includedin the original package, or exactly where we pull our changes in > > from > > Note our release notes dont specify those changes, so I am inclined to > > think > > they aren't in there, but can someone confirm for our release announcement > > if > > 8.3.6 et al have Argentinian timezone updates? (Or any other updates we > > should mention) TIA > > The commit messages is: > > Update time zone data files to tzdata release 2009a: introduces > Asia/Kathmandu as the preferred spelling of that zone name, corrects > historical DST information for Switzerland and Cuba. > > We get our data files as mentioned in /pgtop/src/timezone/README: > > ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz To better answer your specific question, I see Argentina timezone changes added CVS for in 2008i: revision 1.13 date: 2008/10/30 13:16:52; author: tgl; state: Exp; lines: +91 -16 Update time zone data files to tzdata release 2008i (DST law changes in Argentina, Brazil, Mauritius, Syria). Those changes would have been included in 8.3.5 released on 2008-11-03. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] confirm timezone changes for new releases was Fwd: Re: [pgsql-slavestothewww] New News Entry (id: 1055)
Robert Treat wrote: > I know that the fedora tzdata-2009a packages have the Argentian changes (as > well as some others depending on version of fedora), but I'm not sure what is > includedin the original package, or exactly where we pull our changes in from > Note our release notes dont specify those changes, so I am inclined to think > they aren't in there, but can someone confirm for our release announcement if > 8.3.6 et al have Argentinian timezone updates? (Or any other updates we > should mention) TIA The commit messages is: Update time zone data files to tzdata release 2009a: introduces Asia/Kathmandu as the preferred spelling of that zone name, corrects historical DST information for Switzerland and Cuba. We get our data files as mentioned in /pgtop/src/timezone/README: ftp://elsie.nci.nih.gov/pub/tzdata*.tar.gz -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] new GUC var: autovacuum_process_all_tables
Simon Riggs wrote: All I'm saying is *if* we put scheduling inside Postgres for autovacuum *then* we should make it general purpose scheduling. If anybody uses the argument that "we have external schedulers, so don't put them in the database" then that argument applies equally to scheduling autovacuum. It's easy to turn autovacuum on/off via an external scheduler, yet look upthread and see how many people think it should be in the database. Whichever way you think the decision should go, the same arguments apply to scheduling autovacuum and scheduling other database maintenance tasks. OK, I agree with that. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] confirm timezone changes for new releases was Fwd: Re: [pgsql-slavestothewww] New News Entry (id: 1055)
I know that the fedora tzdata-2009a packages have the Argentian changes (as well as some others depending on version of fedora), but I'm not sure what is includedin the original package, or exactly where we pull our changes in from Note our release notes dont specify those changes, so I am inclined to think they aren't in there, but can someone confirm for our release announcement if 8.3.6 et al have Argentinian timezone updates? (Or any other updates we should mention) TIA Robert Treat -- Forwarded Message -- Subject: Re: [pgsql-slavestothewww] New News Entry (id: 1055) Date: Thursday 05 February 2009 From: Guido Barosio To: PostgreSQL Webmaster . Included as well are Daylight Savings Time changes for Nepal, Switzerland and Cuba Isn't there a change for Argentina? Just asking because we had 2 changes during the last 6 months and I am not sure if we are handling this properly. gb.- On Fri, Feb 6, 2009 at 1:15 AM, Guido Barosio wrote: >> These update releases also include patches for several low-risk security holes, as well as up to 17 other minor fixes, depending on your major version of PostgreSQL. Included as well are Daylight Savings Time changes for Nepal, Switzerland and Cuba. See the release notes for full details. >> -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Synch Replication
Hi Niranjan, On Fri, Feb 6, 2009 at 6:46 PM, K, Niranjan (NSN - IN/Bangalore) wrote: > Hi, > >> Please retry new synch-rep code and report the following information. >> >> * server log >> * /sbydata/walreceiver_trace.out >> * tcpdump -i lo -n tcp >> > > Refer attachments. I'm afraid that the message length may be greater than INT_MAX, which might cause the trouble on your machine. I changed my code again, in order to test my hypothesis. http://senduit.com/3ccd93 Please run new synch-rep again and report the following information. Thank you very much for testing it repeatedly! * server log * /sbydata/walreceiver_trace.out * tcpdump -i lo -n tcp Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Synch Replication
Hi, On Fri, Feb 6, 2009 at 2:14 PM, K, Niranjan (NSN - IN/Bangalore) wrote: > Hi, > >> * server log >> * walreceiver_trace.out >> * netstat -nap (before and after replication crashes) >> * tcpdump -i lo -n tcp >> > In addition to the requested logs, I have provided the network interface > information. Your tcpdump.log shows that walsender doesn't send any invalid messages, but walreceiver seems to receive it. So, I suspect libpq functions which walreceiver uses as the cause of the trouble. I changed synch-rep to dump all the behaviors of those libpq functions. http://senduit.com/42da75 Please retry new synch-rep code and report the following information. * server log * /sbydata/walreceiver_trace.out * tcpdump -i lo -n tcp Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot standby, recovery infra
On Fri, 2009-02-06 at 10:06 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-02-05 at 21:54 +0200, Heikki Linnakangas wrote:
> >> - If you perform a fast shutdown while startup process is waiting for
> >> the restore command, startup process sometimes throws a FATAL error
> >> which leads escalates into an immediate shutdown. That leads to
> >> different messages in the logs, and skipping of the shutdown
> >> restartpoint that we now otherwise perform.
> >
> > Sometimes?
>
> I think what happens is that if the restore command receives the SIGTERM
> and dies before the startup process that's waiting for the restore
> command receives the SIGTERM, the startup process throws a FATAL error
> because the restore command died unexpectedly. I put this
>
> > if (shutdown_requested && InRedo)
> > {
> > /* XXX: Is EndRecPtr always the right value here? */
> > UpdateMinRecoveryPoint(EndRecPtr);
> > proc_exit(0);
> > }
>
> right after the "system(xlogRestoreCmd)" call, to exit gracefully if we
> were requested to shut down while restore command was running, but it
> seems that that's not enough because of the race condition.
Can we trap the death of the restorecmd and handle it differently from
the death of the startup process?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Hot standby, recovery infra
Simon Riggs wrote:
On Thu, 2009-02-05 at 21:54 +0200, Heikki Linnakangas wrote:
- If you perform a fast shutdown while startup process is waiting for
the restore command, startup process sometimes throws a FATAL error
which leads escalates into an immediate shutdown. That leads to
different messages in the logs, and skipping of the shutdown
restartpoint that we now otherwise perform.
Sometimes?
I think what happens is that if the restore command receives the SIGTERM
and dies before the startup process that's waiting for the restore
command receives the SIGTERM, the startup process throws a FATAL error
because the restore command died unexpectedly. I put this
if (shutdown_requested && InRedo)
{
/* XXX: Is EndRecPtr always the right value here? */
UpdateMinRecoveryPoint(EndRecPtr);
proc_exit(0);
}
right after the "system(xlogRestoreCmd)" call, to exit gracefully if we
were requested to shut down while restore command was running, but it
seems that that's not enough because of the race condition.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
