Re: [PATCHES] [HACKERS] Inefficiency in recent pgtz patch
Do you agree that using a hashtable for it in general is a good idea assuming this sideeffect is removed, though? I have no problem with the hashtable, only with preloading it with everything. What I'd like to see is that the table inherited at fork() contains just the data for the default timezone. (At least in the normal case where that setting hasn't been changed since postmaster start.) Here's a patch doing this. Changes score_timezone not to use pg_tzset(), and thus not loading all the zones in the cache. The actual timezone being picked will be set using set_global_timezone() which in turn calls pg_tzset() and loads it in the cache. //Magnus tzcache.patch Description: tzcache.patch ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Simplify Win32 Signaling code
Revised patch to avoid lost signals before signaling mechanism is set up
in Win32. This was tested by plus a line:
Sleep(10*1000);
in the front of pgwin32_signal_initialize().
Regards,
Qingqing
Index: src/port/kill.c
===
RCS file: /projects/cvsroot/pgsql/src/port/kill.c,v
retrieving revision 1.6
diff -c -r1.6 kill.c
*** src/port/kill.c 31 Dec 2004 22:03:53 - 1.6
--- src/port/kill.c 4 Jun 2005 12:16:07 -
***
*** 17,61
#include c.h
#ifdef WIN32
! /* signal sending */
int
pgkill(int pid, int sig)
{
! charpipename[128];
! BYTEsigData = sig;
! BYTEsigRet = 0;
! DWORD bytes;
! /* we allow signal 0 here, but it will be ignored in pg_queue_signal */
if (sig = PG_SIGNAL_COUNT || sig 0)
! {
! errno = EINVAL;
! return -1;
! }
if (pid = 0)
! {
! /* No support for process groups */
! errno = EINVAL;
! return -1;
! }
! wsprintf(pipename, .\\pipe\\pgsignal_%i, pid);
! if (!CallNamedPipe(pipename, sigData, 1, sigRet, 1, bytes, 1000))
! {
! if (GetLastError() == ERROR_FILE_NOT_FOUND)
! errno = ESRCH;
! else if (GetLastError() == ERROR_ACCESS_DENIED)
! errno = EPERM;
! else
! errno = EINVAL;
! return -1;
! }
! if (bytes != 1 || sigRet != sig)
! {
! errno = ESRCH;
! return -1;
! }
! return 0;
}
#endif
--- 17,120
#include c.h
#ifdef WIN32
!
! /* Convenience macro to set errno and return */
! #define set_error_and_return(e) \
! do{ \
! if (shmem) UnmapViewOfFile(shmem); \
! if (hShmem) CloseHandle(hShmem);\
! if (hEvent) CloseHandle(hEvent);\
! if (hMutex) CloseHandle(hMutex);\
! \
! errno = (e); \
! return ((e) == 0)? 0 : -1; \
! } while (0)
!
! /*
! * pgkill
! *kill() win32 emulation.
! *
! *pgkill() will fail if:
! *[EINVAL] The value of the sig argument is an invalid
! * or target process id = 0.
! *[ESRCH] No process can be found corresponding to that
! * specified by pid.
! *[EPERM] Any other win32 system call fails.
! */
int
pgkill(int pid, int sig)
{
! charname[64];
! HANDLE hShmem, hMutex, hEvent;
! Win32SignalShmemStruct *shmem;
!
! shmem = NULL;
! hShmem = NULL;
! hMutex = NULL;
! hEvent = NULL;
! /* we allow signal 0 here, and handle later */
if (sig = PG_SIGNAL_COUNT || sig 0)
! set_error_and_return(EINVAL);
!
! /* No support for process groups */
if (pid = 0)
! set_error_and_return(EINVAL);
!
! /*
!* Attach to the signaling shared memory. If it is attachable,
!* we decide that the process is alive.
!*/
! wsprintf(name, %s.%d, SIGNAL_SHMEM_PREFIX, pid);
! if (NULL == (hShmem = OpenFileMapping(FILE_MAP_ALL_ACCESS,
! FALSE,
! name)))
! set_error_and_return(ESRCH);
!
! if (sig == 0)
! set_error_and_return(0);
!
! if (NULL == (shmem = MapViewOfFile(hShmem,
! FILE_MAP_ALL_ACCESS,
! 0, 0, 0)))
! set_error_and_return(EPERM);
!
! /* Grab the mutex */
! wsprintf(name, %s.%d, SIGNAL_MUTEX_PREFIX, pid);
! if (NULL == (hMutex = OpenMutex(MUTEX_ALL_ACCESS,
! FALSE, name)))
! set_error_and_return(EPERM);
!
! if (WaitForSingleObject(hMutex, INFINITE) != WAIT_OBJECT_0)
! set_error_and_return(EPERM);
!
! /* Write down the signal number */
! shmem-queue |= sigmask(sig);
!
! /*
!* If we can't release the mutex, we have to exit the
!* process to make mutex released by the system. If we
!* can't set the event, that's really awkward, but the
!* target process would find out the signal when next
!* set event is successfully done.
!*/
! if (!ReleaseMutex(hMutex))
! set_error_and_return(EPERM);
!
! if (!UnmapViewOfFile(shmem))
! set_error_and_return(EPERM);
!
! /* Set event */
! wsprintf(name, %s.%d, SIGNAL_EVENT_PREFIX, pid);
! if (NULL == (hEvent =
Re: [PATCHES] Simplify Win32 Signaling code
Hi! A quick-check (haven't checked any details) - your unconditional use of Global\ will not work on NT4. With 8.0 we said we wanted to support NT4 with some limits (IIRC, tablespaces don't work, and the intaller definitly doesn't work). If we want to continue doing that (which I think we do), the global\ has to be conditional - used on 2000+, not used on = NT4. //Magnus -Original Message- From: Qingqing Zhou [mailto:[EMAIL PROTECTED] Sent: den 4 juni 2005 15:26 To: Magnus Hagander Cc: pgsql-patches@postgresql.org Subject: Re: Simplify Win32 Signaling code Revised patch to avoid lost signals before signaling mechanism is set up in Win32. This was tested by plus a line: Sleep(10*1000); in the front of pgwin32_signal_initialize(). Regards, Qingqing ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] O_DIRECT for WAL writes
I think the conclusion from the discussion is that O_DIRECT is in addition to the sync method, rather than in place of it, because O_DIRECT doesn't have the same media write guarantees as fsync(). Would you update the patch to do O_DIRECT in addition to O_SYNC or fsync() and see if there is a performance win? Thanks. --- ITAGAKI Takahiro wrote: Neil Conway [EMAIL PROTECTED] wrote: The patch adds a new choice open_direct to wal_sync_method. Have you looked at what the performance difference of this option is? Yes, I've tested pgbench and dbt2 and their performances have improved. The two results are as follows: 1. pgbench -s 100 on one Pentium4, 1GB mem, 2 ATA disks, Linux 2.6.8 (attached image) tps | wal_sync_method ---+--- 147.0 | open_direct + write multipage (previous patch) 147.2 | open_direct (this patch) 109.9 | open_sync 2. dbt2 100WH on two opterons, 8GB mem, 12 SATA-RAID disks, Linux 2.4.20 tpm | wal_sync_method +-- 1183.9 | open_direct (this patch) 911.3 | fsync http://www.mail-archive.com/pgsql-patches@postgresql.org/msg07186.html Is this data still applicable to the revised patch? Direct-IO might be good on some machines, and bad on others. This data is another reason that I revised the patch; If you don't use open_direct, WAL writer behaves quite similarly to former. However, the performances did not go down at least on my benchmarks. I have no idea why the above data was bad... --- ITAGAKI Takahiro NTT Cyber Space Laboratories [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] Server instrumentation: pg_terminate_backend, pg_reload_conf
Andreas Pflug wrote: This patch reenables pg_terminate_backend, allowing (superuser only, of course) to terminate a backend. As taken from the discussion some weeks earlier, SIGTERM seems to be used quite widely, without a report of misbehavior so while the code path is officially not too well tested, in practice it's working ok and helpful. I thought we had a discussion that the places we accept SIGTERM might be places that can exit if the postmaster is shutting down, but might not be places we can exit if the postmaster continues running, e.g. holding locks. Have you checked all the places we honor SIGTERM to check that we are safe to exit? I know Tom had concerns about that. Looking at ProcessInterrupts() and friends, when it is called with QueryCancelPending(), it does elog(ERROR) and longjumps out of elog, and that cleans up some stuff. The problem with SIGTERM/ProcDiePending is that it just does a FATAL and I assume doesn't do the same cleanups that elog(ERROR) does to cancel a query. Ideally we would use another signal number, that would do a query cancel, then up in the recovery code after the longjump, after we had reset everything, we could then exit. The problem, I think, is that we don't have another signal available for use. I see this in postgres.c: pqsignal(SIGHUP, SigHupHandler);/* set flag to read config file */ pqsignal(SIGINT, StatementCancelHandler); /* cancel current query */ pqsignal(SIGTERM, die); /* cancel current query and exit */ pqsignal(SIGQUIT, quickdie);/* hard crash time */ pqsignal(SIGALRM, handle_sig_alarm);/* timeout conditions */ /* * Ignore failure to write to frontend. Note: if frontend closes * connection, we will notice it and exit cleanly when control next * returns to outer loop. This seems safer than forcing exit in the * midst of output during who-knows-what operation... */ pqsignal(SIGPIPE, SIG_IGN); pqsignal(SIGUSR1, CatchupInterruptHandler); pqsignal(SIGUSR2, NotifyInterruptHandler); pqsignal(SIGFPE, FloatExceptionHandler); It would be neat if we could do a combined Cancel/Terminate signal, but signals don't work that way. Any ideas on how we can do a combined cancel/terminate? Do we have a shared area that both the postmaster and the backends can see? Could we set a flag when the postmaster is shutting down and then when a backend sets a SIGTERM, it could either shut down right away or do the cancel and then shut down? I don't think we can do query cancel for server-wide backend shutdowns --- it should be as quick as possible. -- 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 8: explain analyze is your friend
Re: [PATCHES] Simplify Win32 Signaling code
Magnus Hagander wrote: Hi! A quick-check (haven't checked any details) - your unconditional use of Global\ will not work on NT4. With 8.0 we said we wanted to support NT4 with some limits (IIRC, tablespaces don't work, and the intaller definitly doesn't work). If we want to continue doing that (which I think we do), the global\ has to be conditional - used on 2000+, not used on = NT4. How should he make this change? Test OS version or use a different feature? -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] Simplify Win32 Signaling code
Hi! A quick-check (haven't checked any details) - your unconditional use of Global\ will not work on NT4. With 8.0 we said we wanted to support NT4 with some limits (IIRC, tablespaces don't work, and the intaller definitly doesn't work). If we want to continue doing that (which I think we do), the global\ has to be conditional - used on 2000+, not used on = NT4. How should he make this change? Test OS version or use a different feature? Test the OS version. The other feature that can be used is named pipes, and that's what we have today ;-) All other kernel objects that we could use all use the namespaces in the new format, but not back on NT4 //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Simplify Win32 Signaling code
A quick-check (haven't checked any details) - your unconditional use of Global\ will not work on NT4. With 8.0 we said we wanted to support NT4 with some limits (IIRC, tablespaces don't work, and the intaller definitly doesn't work). If we want to continue doing that (which I think we do), the global\ has to be conditional - used on 2000+, not used on = NT4. How should he make this change? Test OS version or use a different feature? Test the OS version. The other feature that can be used is named pipes, and that's what we have today ;-) All other kernel objects that we could use all use the namespaces in the new format, but not back on NT4 Do we have any place now were we test the Win32 version, that he could use as an example, or is this configure.in stuff? It *must* be done at runtime. Because you use the same binary on NT4 and more recent versions! Nope, we don't have any checks like that today. It's fairly trivial, but if examples are needed, look at pginstca.c in the pginstaller project where we do this. //Magnus ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] AllocSetReset improvement
Patch applied. Thanks. (The first if == NULL test was already in CVS). --- a_ogawa wrote: Tom Lane [EMAIL PROTECTED] writes: a_ogawa [EMAIL PROTECTED] writes: It is a reasonable idea. However, the majority part of MemSet was not able to be avoided by this idea. Because the per-tuple contexts are used at the early stage of executor. Drat. Well, what about changing that? We could introduce additional contexts or change the startup behavior so that the ones that are frequently reset don't have any data in them unless you are working with pass-by-ref values inside the inner loop. That might be possible. However, I think that we should change only aset.c about this article. I thought further: We can check whether context was used from the last reset even when blocks list is not empty. Please see attached patch. The effect of the patch that I measured is as follows: o Execution time that executed the SQL ten times. (1)Linux(CPU: Pentium III, Compiler option: -O2) - original: 24.960s - patched : 23.114s (2)Linux(CPU: Pentium 4, Compiler option: -O2) - original: 8.730s - patched : 7.962s (3)Solaris(CPU: Ultra SPARC III, Compiler option: -O2) - original: 37.0s - patched : 33.7s regards, --- Atsushi Ogawa [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] return_next for plperl (was Re: call for help)
Mega-patch version applied. Thanks.
---
Abhijit Menon-Sen wrote:
At 2005-05-21 20:18:50 +0530, [EMAIL PROTECTED] wrote:
The second issue is where plperl returns a large result set.
I have attached the following seven patches to address this problem:
1. Trivial. Replaces some errant spaces with tabs.
2. Trivial. Fixes the spelling of Jan's name, and gets rid of many
inane, useless, annoying, and often misleading comments. Here's
a sample: plperl_init_all() - Initialize all.
(I have tried to add some useful comments here and there, and will
continue to do so now and again.)
3. Trivial. Splits up some long lines.
4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize
to return the result set, based on the PL/PgSQL model.
There are two major consequences: result sets will spill to disk when
they can no longer fit in work_mem; and select foo_srf() no longer
works. (I didn't lose sleep over the latter, since that form is not
valid in PL/PgSQL, and it's not documented in PL/Perl.)
5. Trivial, but important. Fixes use of undef instead of undef. This
would cause empty functions to fail in bizarre ways. I suspect that
there's still another (old) bug here. I'll investigate further.
6. Moves the majority of (4) out into a new plperl_return_next()
function, to make it possible to expose the functionality to
Perl; cleans up some of the code besides.
7. Add an spi_return_next function for use in Perl code.
If you want to apply the patches and try them out, 8-composite.diff is
what you should use. (Note: my patches depend upon Andrew's use-strict
and %_SHARED patches being applied.)
Here's something to try:
create or replace function foo() returns setof record as $$
$i = 0;
for (World, PostgreSQL, PL/Perl) {
spi_return_next({f1=++$i, f2='Hello', f3=$_});
}
return;
$$ language plperl;
select * from foo() as (f1 integer, f2 text, f3 text);
(Many thanks to Andrews Dunstan and Supernews for their help.)
Questions, comments, and suggestions welcome.
-- ams
Just Another Cut-and-Paste Hacker
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
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 8: explain analyze is your friend
Re: [PATCHES] character type value is not padded with spaces
I see Tatsuo already applied this, which is great. I added a little
comment:
/* if multi-byte, take len and find # characters */
---
Yoshiyuki Asaba wrote:
Character type value including multibyte characters is not padded
with spaces. It reproduces at 7.3.x, 7.4.x and 8.0.x.
create table t (a char(10));
insert into t values ('X'); -- X is 2byte character.
I expect that 'X ' is inserted. But 'X' is inserted.
select a, octed_length(a) from t;
a | octet_length
---+--
X | 10
If padded with spaces, octet_length(a) is 15. This problem is caused
that string length is calculated by byte length(VARSIZE) in
exprTypmod().
I attache the patch for this problem.
Regards,
--
Yoshiyuki Asaba
[EMAIL PROTECTED]
*** parse_expr.c.orig 2005-01-13 02:32:36.0 +0900
--- parse_expr.c 2005-05-22 17:12:37.0 +0900
***
*** 18,23
--- 18,24
#include catalog/pg_operator.h
#include catalog/pg_proc.h
#include commands/dbcommands.h
+ #include mb/pg_wchar.h
#include miscadmin.h
#include nodes/makefuncs.h
#include nodes/params.h
***
*** 34,40
#include utils/lsyscache.h
#include utils/syscache.h
-
boolTransform_null_equals = false;
static Node *transformColumnRef(ParseState *pstate, ColumnRef *cref);
--- 35,40
***
*** 1491,1497
{
case BPCHAROID:
if (!con-constisnull)
! return
VARSIZE(DatumGetPointer(con-constvalue));
break;
default:
break;
--- 1491,1503
{
case BPCHAROID:
if (!con-constisnull)
! {
! int32 len =
VARSIZE(DatumGetPointer(con-constvalue)) - VARHDRSZ;
!
! if
(pg_database_encoding_max_length() 1)
! len =
pg_mbstrlen_with_len(VARDATA(DatumGetPointer(con-constvalue)), len);
! return len + VARHDRSZ;
! }
break;
default:
break;
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] return_next for plperl (was Re: call for help)
This has broken the regression tests for plperl - see for example
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pandadt=2005-06-04%2021:20:01
That's because, as Abhijit noted in point 4 below, select foo_srf() no
longer works.
At a minimum those calls need to be removed from the regression tests.
See also my later comments in response to Neil's request of a few days ago.
In particular, I would very much like the callback function renamed to a
simple return_next.
cheers
andrew
Bruce Momjian said:
Mega-patch version applied. Thanks.
---
Abhijit Menon-Sen wrote:
At 2005-05-21 20:18:50 +0530, [EMAIL PROTECTED] wrote:
The second issue is where plperl returns a large result set.
I have attached the following seven patches to address this problem:
1. Trivial. Replaces some errant spaces with tabs.
2. Trivial. Fixes the spelling of Jan's name, and gets rid of many
inane, useless, annoying, and often misleading comments. Here's a
sample: plperl_init_all() - Initialize all.
(I have tried to add some useful comments here and there, and will
continue to do so now and again.)
3. Trivial. Splits up some long lines.
4. Converts SRFs in PL/Perl to use a Tuplestore and SFRM_Materialize
to return the result set, based on the PL/PgSQL model.
There are two major consequences: result sets will spill to disk
when they can no longer fit in work_mem; and select foo_srf() no
longer works. (I didn't lose sleep over the latter, since that form
is not valid in PL/PgSQL, and it's not documented in PL/Perl.)
5. Trivial, but important. Fixes use of undef instead of undef. This
would cause empty functions to fail in bizarre ways. I suspect that
there's still another (old) bug here. I'll investigate further.
6. Moves the majority of (4) out into a new plperl_return_next()
function, to make it possible to expose the functionality to
Perl; cleans up some of the code besides.
7. Add an spi_return_next function for use in Perl code.
If you want to apply the patches and try them out, 8-composite.diff is
what you should use. (Note: my patches depend upon Andrew's use-strict
and %_SHARED patches being applied.)
Here's something to try:
create or replace function foo() returns setof record as $$
$i = 0;
for (World, PostgreSQL, PL/Perl) {
spi_return_next({f1=++$i, f2='Hello', f3=$_});
}
return;
$$ language plperl;
select * from foo() as (f1 integer, f2 text, f3 text);
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] AllocSetReset improvement
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Patch applied. Thanks. (The first if == NULL test was already in CVS).
The first if == NULL test was the only part I wanted to apply ...
I do not think this patch is a performance win in general.
Attached is the part I backed out of CVS.
--
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
Index: aset.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/mmgr/aset.c,v
retrieving revision 1.60
retrieving revision 1.61
diff -c -c -r1.60 -r1.61
*** aset.c 14 May 2005 20:29:13 - 1.60
--- aset.c 4 Jun 2005 20:14:12 - 1.61
***
*** 399,404
--- 399,415
if (block == NULL)
return;
+ /*
+* When blocks list has only keeper block and freeptr of the block
+* is initial value, the context is not used from last reset.
+*/
+ if (block == set-keeper block-next == NULL)
+ {
+ char *datastart = ((char *) block) + ALLOC_BLOCKHDRSZ;
+ if (block-freeptr == datastart)
+ return;
+ }
+
/* Clear chunk freelists */
MemSetAligned(set-freelist, 0, sizeof(set-freelist));
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] return_next for plperl (was Re: call for help)
Andrew Dunstan wrote: This has broken the regression tests for plperl - see for example http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pandadt=2005-06-04%2021:20:01 That's because, as Abhijit noted in point 4 below, select foo_srf() no longer works. At a minimum those calls need to be removed from the regression tests. See also my later comments in response to Neil's request of a few days ago. In particular, I would very much like the callback function renamed to a simple return_next. OK, would you please submit a patch to fix it. Thanks. -- 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 7: don't forget to increase your free space map settings
Re: [PATCHES] AllocSetReset improvement
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Patch applied. Thanks. (The first if == NULL test was already in CVS). The first if == NULL test was the only part I wanted to apply ... I do not think this patch is a performance win in general. OK, patch reverted. a_ogawa, would you run tests with just the part I reverted to see if it is a win. Thanks. -- 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 4: Don't 'kill -9' the postmaster
Re: [PATCHES] regexp_replace
I will add the documentation and make sure your oids are not duplicates.
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.
---
a_ogawa00 wrote:
This patch provides a new function regexp_replace.
regexp_replace extends a replace function and enables text search
by the regular expression. And, a back reference can be used within
a replace string.
(This patch for PostgreSQL 7.4.3)
Function: regexp_replace(str, pattern, replace_str)
Retuen Type: text
Description: Replace all matched string in str.
pattern is regular expression pattern.
replace_str is replace string that can use '\1' - '\9', and
'\'.
'\1' - '\9' is back reference to the n'th subexpression.
'\' is matched string.
(example1)
select regexp_replace('ABC-DEF', '(\\w+)-(\\w+)', '\\2-\\1')
result: DEF-ABC
(example2)
update tab1 set col1 = regexp_replace(col1, '[A-Z]', '');
---
Atsushi Ogawa
[EMAIL PROTECTED]
--- cut here ---
*** ./src/backend/regex/regexec.c.origTue Jul 20 08:45:39 2004
--- ./src/backend/regex/regexec.c Tue Jul 20 08:49:36 2004
***
*** 110,115
--- 110,116
regmatch_t *pmatch;
rm_detail_t *details;
chr*start; /* start of string */
+ chr*search_start; /* search start of string */
chr*stop; /* just past end of
string */
int err;/* error code if any (0
none) */
regoff_t *mem;/* memory vector for
backtracking */
***
*** 168,173
--- 169,175
pg_regexec(regex_t *re,
const chr *string,
size_t len,
+size_t search_start,
rm_detail_t *details,
size_t nmatch,
regmatch_t pmatch[],
***
*** 219,224
--- 221,227
v-pmatch = pmatch;
v-details = details;
v-start = (chr *) string;
+ v-search_start = (chr *) string + search_start;
v-stop = (chr *) string + len;
v-err = 0;
if (backref)
***
*** 288,294
NOERR();
MDEBUG((\nsearch at %ld\n, LOFF(v-start)));
cold = NULL;
! close = shortest(v, s, v-start, v-start, v-stop, cold, (int *)
NULL);
freedfa(s);
NOERR();
if (v-g-cflags REG_EXPECT)
--- 291,298
NOERR();
MDEBUG((\nsearch at %ld\n, LOFF(v-start)));
cold = NULL;
! close = shortest(v, s, v-search_start, v-search_start, v-stop,
! cold, (int *) NULL);
freedfa(s);
NOERR();
if (v-g-cflags REG_EXPECT)
***
*** 415,421
assert(d != NULL s != NULL);
cold = NULL;
! close = v-start;
do
{
MDEBUG((\ncsearch at %ld\n, LOFF(close)));
--- 419,425
assert(d != NULL s != NULL);
cold = NULL;
! close = v-search_start;
do
{
MDEBUG((\ncsearch at %ld\n, LOFF(close)));
*** ./src/backend/utils/adt/regexp.c.orig Tue Jul 20 08:50:08 2004
--- ./src/backend/utils/adt/regexp.c Tue Jul 20 09:00:05 2004
***
*** 80,116
/*
! * RE_compile_and_execute - compile and execute a RE, caching if possible
*
! * Returns TRUE on match, FALSE on no match
*
! * text_re --- the pattern, expressed as an *untoasted* TEXT object
! * dat --- the data to match against (need not be null-terminated)
! * dat_len --- the length of the data string
! * cflags --- compile options for the pattern
! * nmatch, pmatch --- optional return area for match details
*
! * Both pattern and data are given in the database encoding. We
internally
! * convert to array of pg_wchar which is what Spencer's regex package
wants.
*/
! static bool
! RE_compile_and_execute(text *text_re, unsigned char *dat, int dat_len,
!int cflags, int nmatch, regmatch_t
*pmatch)
{
int text_re_len = VARSIZE(text_re);
- pg_wchar *data;
- size_t data_len;
pg_wchar *pattern;
size_t pattern_len;
int i;
int regcomp_result;
- int regexec_result;
cached_re_str re_temp;
- /* Convert data string to wide characters */
- data = (pg_wchar *) palloc((dat_len + 1) * sizeof(pg_wchar));
- data_len = pg_mb2wchar_with_len(dat, data, dat_len);
-
/*
* Look for a match among previously compiled REs.
Re: [PATCHES] return_next for plperl (was Re: call for help)
Bruce Momjian said: Andrew Dunstan wrote: This has broken the regression tests for plperl - see for example http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=pandadt=2005-06-04%2021:20:01 That's because, as Abhijit noted in point 4 below, select foo_srf() no longer works. At a minimum those calls need to be removed from the regression tests. See also my later comments in response to Neil's request of a few days ago. In particular, I would very much like the callback function renamed to a simple return_next. OK, would you please submit a patch to fix it. Thanks. I will unless someone beats me to it in the next 2 weeks - I am currently travelling and don't really have development facilities available. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] log_line_prefix additions
Patch additions added to the patch queue.
---
Andrew Dunstan wrote:
Ed L. wrote:
Attached also is a patch to comments in sample postgresql.conf file.
Subject: [PATCHES] log_line_prefix additions
Date: Wednesday August 25 2004 3:26
From: Ed L. [EMAIL PROTECTED]
To: pgsql-patches@postgresql.org
This patch against 8.0.0beta1 source adds log_line_prefix options for
millisecond timestamps (%m), remote host (%h), and remote port (%P). The
milliseconds are useful for QPS measurements, and the remote port is
worthless to us as part of %r.
[snip]
+struct timezone tz = {0, 0};
+
+gettimeofday(tv, tz);
The timezone is pointless. Just pass NULL as the second argument to
gettimeofday().
Also, I don't understand what you mean by the remote port being
worthless to us as part of %r. Please explain.
cheers
andrew
---(end of broadcast)---
TIP 8: explain analyze is your friend
--
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 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] PGPASSWORD and client tools
I will add documentation for it. 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. --- Andrew Dunstan wrote: Here's a patch that I think (hope) does this right, by using the file pointed to by the environment var PGPASSFILE, if set, in preference to $HOME/.pgpass. I assume that at this stage it would be held over for 8.1 as a new feature - if not I'll put together some docco in a hurry. cheers andrew Andrew Dunstan wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: How about an environment variable that points to a .pgpass type file. You can do that today: point $HOME at some temp directory or other. AFAIR pg_dump doesn't make any other use of $HOME ... Or we could even play games with PGPASSWORD - if it names an existing file that satisfies the .pgpass criteria then it will be taken as the location of the .pgpass file instead of $HOME/.pgpass - otherwise its value will be considered to be the password itself. Gaack... if you want a separate variable, we can talk about that, but let's not overload PGPASSWORD like that. Consider even just the implications of whether libpq error messages should echo back the filename ... Yeah. as usual you're right :-) So let's go woth PGPASSFILE cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] WAL bypass for CTAS
Bruce Momjian wrote: Could we do your NOLOGGING automatically in COPY if we test to see if anyone else is connected to our current database? That seems pretty fragile -- what happens if someone connects after the COPY has started? Considering that many COPY operations can take many minutes or hours, I don't think it is wise to make assumptions based on the initial state of the system. I would _love_ to see pg_dump loads use this automatically, without having to add clauses to pg_dump output. What's wrong with adding clauses to the pg_dump output? -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Faster install-sh in C
I am using 'cp' in current CVS for this. I assume it is as fast as the C implementation, but if not, please let me know. --- Alvaro Herrera wrote: Patchers, I wrote an install program in C. It's supposed to replace the config/install-sh script, limited to the functionality we need, i.e. what is in Makefiles in the Pg main source tree. The main objective of this exercise is to reduce make install execution time; a part of that is being able to install multiple files with one command. Portability testing right now is limited to my machine, which is Linux with glibc 2.3.2 (Debian Sid). With this in place, make install in src/include takes 17 seconds on this machine, where the script version takes more than a minute. I think this is a useful improvement. Right now I'm missing a Makefile rule for it. It needs the pg_progname symbol from src/port, and the includes from $(srcdir)/src/include and $(builddir)/src/include. From the config directory, this works: $(CC) $(CFLAGS) -I$(top_srcdir)/src/include -I$(top_builddir)/src/include ../src/port/path.o ../src/port/exec.o $ -o $@ Also, I don't know how to force it to build before executing install, short of putting it as a dependency in every makefile (which sounds silly to me). I attach the source code, and a src/include/Makefile modification to use the multi-file install feature. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Hay quien adquiere la mala costumbre de ser infeliz (M. A. Evans) [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Optional REFERENCES Feature in CREATE TRIGGER Command
[EMAIL PROTECTED] wrote: I must be missing something, but AFAICS this patch doesn't actually *do* anything useful. It looks to me like you've implemented a write-only addition to the system catalogs. (And not even done a very good job of that --- no documentation, no pg_dump support.) What's the point? I just want to emphasis one thing. The point is this implementation is the fundamental, necessary, and critical preparation and step for implementing execution of standard SQL commands in trigger action in future, instead of using user-defined functions in trigger action. OK, but we usually don't add stuff to CVS until the feature is ready to be useful. -- 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 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Bgwriter behavior
Later version of this patch added to the patch queue. 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 Sat, 2005-01-01 at 17:47, Simon Riggs wrote: On Sat, 2005-01-01 at 17:01, Bruce Momjian wrote: Simon Riggs wrote: Well, I think we're saying: its not in 8.0 now, and we take our time to consider patches for 8.1 and accept the situation that the parameter names/meaning will change in next release. I have no problem doing something for 8.0 if we can find something that meets all the items I mentioned. One idea would be to just remove bgwriter_percent. Beta/RC users would still have it in their postgresql.conf, but it is commented out so it should be OK. If they uncomment it their server would not start but we could just tell testers to remove it. I see that as better than having conflicting parameters. Can't say I like that at first thought. I'll think some more though... Another idea is to have bgwriter_percent be the percent of the buffer it will scan. Hmmmwell that was my original suggestion (bg2.patch on 12 Dec) (...though with a bug, as Neil pointed out) We could default that to 50% or 100%, but we then need to make sure all beta/RC users update their postgresql.conf with the new default because the commented-out default will not be correct. ...we just differ/ed on what the default should be... At this point I see these as our only two viable options, aside from doing nothing. I realize our current behavior requires a full scan of the buffer cache, but how often is the bgwriter_maxpages limit met? If it is not a full scan is done anyway, right? Well, if you heavy a very heavy read workload then that would be a problem. I was more worried about concurrency in a heavy write situation, but I can see your point, and agree. (Idea #1 still suffers from this, so we should rule it out...) It seems the only way to really add functionality is to change bgwriter_precent to control how much of the buffer is scanned. OK. I think you've persuaded me on idea #2, if I understand you right: bgwriter_percent = 50 (default) bgwriter_maxpages = 100 (default) percent is the number of shared_buffers we scan, limited by maxpages. (I'll code it up in a couple of hours when the kids are in bed) Here's the basic patch - no changes to current default values or docs. Not sure if this is still interesting or not... -- Best Regards, Simon Riggs [ Attachment, skipping... ] ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] return_next for plperl
Patch applied. Thanks. --- Abhijit Menon-Sen wrote: At 2005-06-04 17:27:10 -0500, [EMAIL PROTECTED] wrote: OK, would you please submit a patch to fix it. Thanks. I will unless someone beats me to it in the next 2 weeks Here's a patch to do the following: 1. Rename spi_return_next to return_next. 2. Add a new test for return_next. 3. Update the expected output. 4. Update the documentation. -- ams Content-Description: 1-rn-testdoc.diff [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] WAL: O_DIRECT and multipage-writer (+ memory
ITAGAKI Takahiro wrote: Hello everyone. I fixed two bugs in the patch that I sent before. Check and test new one, please. 1. Fix update timing of Write-curridx. (pointed by Tom) Change to update it soon after write(). 2. Fix buffer alignment routine on 64bit cpu. (pointed by Mark) I checked it on Xeon EM64T and it worked properly, but I don't have IA64... BTW, I found memory leak in BootStrapXLOG(). The buffer allocated by malloc() is not free()ed. ISSUE_BOOTSTRAP_MEMORYLEAK in this patch points out it. (But this leak is not serious, because this function is called only once.) Does the following patch fix the memory leak you described? -- 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 Index: src/backend/access/transam/xlog.c === RCS file: /cvsroot/pgsql/src/backend/access/transam/xlog.c,v retrieving revision 1.195 diff -c -c -r1.195 xlog.c *** src/backend/access/transam/xlog.c 2 Jun 2005 05:55:28 - 1.195 --- src/backend/access/transam/xlog.c 5 Jun 2005 03:38:23 - *** *** 3754,3759 --- 3754,3760 BootStrapCLOG(); BootStrapSUBTRANS(); BootStrapMultiXact(); + free(buffer); } static char * ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] Implementing RESET CONNECTION ...
What would be absolutely ideal is a reset connection command, plus some way of knowing via the protocol if it's needed or not. Chris Bruce Momjian wrote: What did we decide on RESET CONNECTION. Do we want an SQL command or something only the protocol can do? --- Oliver Jowett wrote: (cc'ing -hackers) Karel Zak wrote: I think command status is common and nice feedback for client. I think it's more simple change something in JDBC than change protocol that is shared between more tools. There is a bit of a queue of changes that would be nice to have but require a protocol version change. If we're going to change the protocol for any of those we might as well handle RESET CONNECTION cleanly too. We need some common way how detect on client what's happen on server -- a way that doesn't mean change protocol always when we add some feature/command to backend. The command status is possible use for this. Command status only works if commands are directly executed. If you can execute the command indirectly, e.g. via a PL, then you'll miss the notification. Making RESET a top-level-only command isn't unreasonable, but using command status won't work as a general approach for notifying clients. We have a mechanism for GUC changes that uses a separate message (ParameterStatus). Perhaps that should be generalized to report different sorts of connection-related changes. -O ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] (8.1) to_timestamp correction (epoch to timestamptz)
Bruce, Please note that this patch is a correction and replacement for an earlier patch in the queue. The patch accompanying the message http://candle.pha.pa.us/mhonarc/patches/msg8.html should be removed from the queue and not applied. The one (originally) attached to this message should be applied. Thanks! Michael Glaesemann grzm myrealbox com On Jun 5, 2005, at 9:17 AM, 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. -- - Michael Glaesemann wrote: Note: This patch is intended for 8.1 (as was the original). I believe the previous patch I submitted to convert Unix epoch to timestamptz contains a bug relating to its use of AT TIME ZONE. Please find attached a corrected patch diffed against HEAD, which includes documentation. The original function was equivalent to CREATE FUNCTION to_timestamp (DOUBLE PRECISION) RETURNS timestamptz LANGUAGE SQL AS ' select ( (\'epoch\'::timestamptz + $1 * \'1 second\'::interval) at time zone \'UTC\' ) '; The AT TIME ZONE 'UTC' removes the time zone from the timestamptz, returning timestamp. However, the function is declared to return timestamptz. The original patch appeared to work, but creating this equivalent function fails as it doesn't return the declared datatype. The corrected function restores the time zone with an additional AT TIME ZONE 'UTC': CREATE FUNCTION to_timestamp (double precision) returns timestamptz language sql as ' select ( (\'epoch\'::timestamptz + $1 * \'1 second\'::interval) at time zone \'UTC\' ) at time zone \'UTC\' '; Michael Glaesemann grzm myrealbox com [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] regexp_replace
Bruce Momjian pgman@candle.pha.pa.us writes: Your patch has been added to the PostgreSQL unapplied patches list at: a_ogawa00 wrote: This patch provides a new function regexp_replace. regexp_replace extends a replace function and enables text search by the regular expression. And, a back reference can be used within a replace string. (This patch for PostgreSQL 7.4.3) Don't we have this functionality already? It's even SQL-spec ... regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] WAL: O_DIRECT and multipage-writer (+ memory
Bruce Momjian pgman@candle.pha.pa.us writes: BTW, I found memory leak in BootStrapXLOG(). The buffer allocated by malloc() is not free()ed. ISSUE_BOOTSTRAP_MEMORYLEAK in this patch points out it. (But this leak is not serious, because this function is called only once.) Does the following patch fix the memory leak you described? You realize this is a waste of code, no? It's not like the bootstrap subprocess frees every single bit of memory it ever allocates, and even less like it'd be profitable to try to make it do so ... the memory will go away anyway when the subprocess exits. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] WAL bypass for CTAS
On Sun, 5 Jun 2005 10:29 am, Neil Conway wrote: Bruce Momjian wrote: Well, it isn't going to help us for 8.1 because 8.0 will not have it, and if we add the clause we make loading the data into previous releases harder. pg_dump output in general is not compatible with prior releases. It would be a nice feature to have, but until we have it, I don't see that changing or not changing the COPY syntax will make a major difference to dump backward compatibility. Don't we usually suggest using the new pg_dump to dump the old database anyway? If that's the case, then we just add the locking options in there. Otherwise, yes you are stuck with the original locking mechanism. But if people are smart and want faster loading they will play with sed and friends to make it work. Even if people for 8.1 just get the supposed 500% speed increase because of a better parser, lots of people will be happy. Regards Russell Smith ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Unicode characters above 0x10000 #2
Bruce,
Attached patch replaces the original, applied today against CVS HEAD.
Fixes the surrogates, and limits to 4 byte utf8 as per spec.
Also extends UtfToLocal to 4 byte characters (tho, it does not add any,
just enables the code to handle them. If my interpretation of this code
is wrong, please let me know, and correct it).
... John
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 05, 2005 11:23 AM
To: pgman@candle.pha.pa.us
Cc: John Hansen; pgsql-hackers@postgresql.org; PostgreSQL-patches
Subject: Re: [PATCHES] Unicode characters above 0x1 #2
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.
--
-
pgman wrote:
I have backed out this patch. It is unclear it is a bug fix.
It will be saved for 8.1.
--
-
pgman wrote:
Patch applied. Thanks.
---
John Hansen wrote:
3 times lucky?
Last one broke utf8 G
This one works, Too tired, sorry for the inconvenience..
... John
Content-Description: cvs.diff
[ Attachment, skipping... ]
---(end of
broadcast)---
TIP 9: the planner will ignore your desire to choose an
index scan if your
joining column's datatypes do not match
--
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
--
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
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/mb/wchar.c,v
retrieving revision 1.38
diff -c -r1.38 wchar.c
*** src/backend/utils/mb/wchar.c17 Sep 2004 21:59:57
- 1.38
--- src/backend/utils/mb/wchar.c21 Nov 2004 09:58:36 -
***
*** 343,348
--- 343,373
return (pg_euc_dsplen(s));
}
+ bool isLegalUTF8(const UTF8 *source, int len) {
+ UTF8 a;
+ const UTF8 *srcptr = source+len;
+ if(!source || (pg_utf_mblen(source) != len)) return false;
+ switch (len) {
+ default: return false;
+ /* Everything else falls through when true... */
+ case 6: if ((a = (*--srcptr)) 0x80 || a
0xBF) return false;
+ case 5: if ((a = (*--srcptr)) 0x80 || a
0xBF) return false;
+ case 4: if ((a = (*--srcptr)) 0x80 || a
0xBF) return false;
+ case 3: if ((a = (*--srcptr)) 0x80 || a
0xBF) return false;
+ case 2: if ((a = (*--srcptr)) 0xBF) return false;
+ switch (*source) {
+ /* no fall-through in this inner switch */
+ case 0xE0: if (a 0xA0) return false; break;
+ case 0xF0: if (a 0x90) return false; break;
+ case 0xF4: if (a 0x8F) return false; break;
+ default: if (a 0x80) return false;
+ }
+ case 1: if (*source = 0x80 *source
0xC2) return false;
+ if (*source 0xFD) return false;
+ }
+ return true;
+ }
+
/*
* convert UTF-8 string to pg_wchar (UCS-2)
* caller should allocate enough space for to
***
*** 398,404
* returns the byte length of a UTF-8 word pointed to by s
*/
int
! pg_utf_mblen(const unsigned char *s)
{
int len = 1;
--- 423,429
* returns the byte length of a UTF-8 word pointed to by s
*/
int
! pg_utf_mblen(const UTF8 *s)
{
int len = 1;
***
*** 406,418
len = 1;
else if ((*s 0xe0) == 0xc0)
len = 2;
! else if ((*s 0xe0) == 0xe0)
! len = 3;
return (len);
}
static int
! pg_utf_dsplen(const unsigned char *s)
{
return 1; /* XXX
fix me! */
}
--- 431,449
len = 1;
else if ((*s 0xe0) == 0xc0)
len = 2;
! else if ((*s 0xf0) == 0xe0)
! len = 3;
Re: [PATCHES] lastval()
On Thu, 2 Jun 2005, Neil Conway wrote: Here is a small patch that implements a function lastval() that Have you had a chance to respin this patch per my earlier comments on the implementation, Dennis? I've been spending my free time on another project and I don't multitask very well :-) Anyway, let me take a look at it in a minute. My main comment is that it's not the code that's the main thing to fix but to decide is if we want the feature at all. -- /Dennis Björklund ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
