Re: [PATCHES] Display Pg buffer cache (WIP)
Neil Conway wrote:
I don't like accessing shared data structures without acquiring the
appropriate locks; even if it doesn't break anything, it seems like just
asking for trouble. In order to be able to inspect a buffer's tag in
Tom's new locking scheme (not yet in HEAD, but will be in 8.1), you need
only hold a per-buffer lock. That will mean acquiring and releasing a
spinlock for each buffer, which isn't _too_ bad...
That means the data reported by the function might still be
inconsistent; not sure how big a problem that is.
It might be nice for the patch to indicate whether the buffers are
dirty, and what their shared reference count is.
Yeah - sounds good, will do.
+extern Datum dump_cache(PG_FUNCTION_ARGS);
Yep.
This declaration belongs in a header file (such as
include/utils/builtins.h).
+typedef struct {
+intbuffer;
+AttInMetadata*attinmeta;
+BufferDesc*bufhdr;
+RelFileNodernode;
+char*values[3];
+} dumpcache_fctx;
This should be values[4], no?
Arrg... surprised there wasn't crashes everywhere
This is trivial, but I think most type names use camel case
(NamesLikeThis).
Why does `rnode' need to be in the struct? You can also fetch the buffer
number from the buffer desc, so you needn't store another copy of it.
I thought it made readability a bit better, but yeah, could take it out.
+/* allocate the strings for tuple formation */
+fctx->values[0] = (char *) palloc(NAMEDATALEN + 1);
+fctx->values[1] = (char *) palloc(NAMEDATALEN + 1);
+fctx->values[2] = (char *) palloc(NAMEDATALEN + 1);
+fctx->values[3] = (char *) palloc(NAMEDATALEN + 1);
Is there a reason for choosing NAMEDATALEN + 1 as the size of these
buffers? (There is no relation between NAMEDATALEN and the number of
characters an OID will consume when converted via sprintf("%u") )
Hmmm... good spot, originally I was returning TEXTOID and relation names
etc...and then it was "big enough" after converting to oid during
testing, so err, yes - I will change that (as well) !
The patch doesn't treat unassigned buffers specially (i.e. those buffers
whose tag contains of InvalidOids). Perhaps it should return NULL for
their OID fields, rather than InvalidOid (which will be 0)? (An
alternative would be to not include those rows in the result set,
although perhaps administrators might want this information.)
I thought it might be handy to explicitly see unused (or belonging to
another db) buffers. Clearly joining to pg_class will project 'em out!
Finally, thanks for the excellent feedback (fast too)
regards
Mark
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Display Pg buffer cache (WIP)
Mark Kirkwood wrote:
does not worry too much about a consistent view of the buffer
contents (as I didn't want it to block all other activity!).
I don't like accessing shared data structures without acquiring the
appropriate locks; even if it doesn't break anything, it seems like just
asking for trouble. In order to be able to inspect a buffer's tag in
Tom's new locking scheme (not yet in HEAD, but will be in 8.1), you need
only hold a per-buffer lock. That will mean acquiring and releasing a
spinlock for each buffer, which isn't _too_ bad...
That means the data reported by the function might still be
inconsistent; not sure how big a problem that is.
It might be nice for the patch to indicate whether the buffers are
dirty, and what their shared reference count is.
+extern Datum dump_cache(PG_FUNCTION_ARGS);
This declaration belongs in a header file (such as
include/utils/builtins.h).
+typedef struct {
+ int buffer;
+ AttInMetadata *attinmeta;
+ BufferDesc *bufhdr;
+ RelFileNode rnode;
+ char*values[3];
+} dumpcache_fctx;
This should be values[4], no?
This is trivial, but I think most type names use camel case (NamesLikeThis).
Why does `rnode' need to be in the struct? You can also fetch the buffer
number from the buffer desc, so you needn't store another copy of it.
+ /* allocate the strings for tuple formation */
+ fctx->values[0] = (char *) palloc(NAMEDATALEN + 1);
+ fctx->values[1] = (char *) palloc(NAMEDATALEN + 1);
+ fctx->values[2] = (char *) palloc(NAMEDATALEN + 1);
+ fctx->values[3] = (char *) palloc(NAMEDATALEN + 1);
Is there a reason for choosing NAMEDATALEN + 1 as the size of these
buffers? (There is no relation between NAMEDATALEN and the number of
characters an OID will consume when converted via sprintf("%u") )
The patch doesn't treat unassigned buffers specially (i.e. those buffers
whose tag contains of InvalidOids). Perhaps it should return NULL for
their OID fields, rather than InvalidOid (which will be 0)? (An
alternative would be to not include those rows in the result set,
although perhaps administrators might want this information.)
-Neil
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[PATCHES] Display Pg buffer cache (WIP)
I found it useful to be able to look at what relations are occupying the
cache (mainly for debugging and comparing with page estimates).
I am wondering if it might be a useful addition generally?
How it works a SRF called dump_cache() is created, which is then exposed
as system view pg_dump_cache. So stuff like the following can be
performed (cache of 2000 immediately after 'make installcheck'):
regression=# SELECT c.relname, count(*) AS buffers
regression-# FROM pg_class c, pg_dump_cache d
regression-# WHERE d.relfilenode = c.relfilenode
regression-# GROUP BY c.relname
regression-# ORDER BY 2 DESC LIMIT 10;
relname | buffers
-+-
tenk1 | 345
tenk2 | 345
onek| 138
pg_attribute| 102
road| 81
pg_attribute_relid_attnam_index | 74
onek2 | 69
pg_proc | 59
pg_proc_proname_args_nsp_index | 56
hash_f8_heap| 49
(10 rows)
regression=#
As of now the patch breaks 1 regression test (rules - that new view...)
and does not peek into the contents of the buffers themselves (I was
mainly interested in which relations were there), and does not worry too
much about a consistent view of the buffer contents (as I didn't want it
to block all other activity!).
If it seems like a worthwhile addition I will amend the regression
expected and resubmit.
Any comments?
Mark
diff -Naur pgsql.orig/src/backend/catalog/system_views.sql
pgsql/src/backend/catalog/system_views.sql
--- pgsql.orig/src/backend/catalog/system_views.sql Thu Mar 3 11:29:55 2005
+++ pgsql/src/backend/catalog/system_views.sql Thu Mar 3 11:41:24 2005
@@ -277,3 +277,8 @@
DO INSTEAD NOTHING;
GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;
+
+CREATE VIEW pg_dump_cache AS
+ SELECT D.* FROM pg_dump_cache() AS D
+ (bufferid integer, relfilenode oid, reltablespace oid, reldatabase oid);
+
diff -Naur pgsql.orig/src/backend/utils/adt/Makefile
pgsql/src/backend/utils/adt/Makefile
--- pgsql.orig/src/backend/utils/adt/Makefile Thu Mar 3 11:29:53 2005
+++ pgsql/src/backend/utils/adt/MakefileThu Mar 3 11:32:10 2005
@@ -24,7 +24,7 @@
tid.o timestamp.o varbit.o varchar.o varlena.o version.o xid.o \
network.o mac.o inet_net_ntop.o inet_net_pton.o \
ri_triggers.o pg_lzcompress.o pg_locale.o formatting.o \
- ascii.o quote.o pgstatfuncs.o encode.o
+ ascii.o quote.o pgstatfuncs.o encode.o dumpcache.o
like.o: like.c like_match.c
diff -Naur pgsql.orig/src/backend/utils/adt/dumpcache.c
pgsql/src/backend/utils/adt/dumpcache.c
--- pgsql.orig/src/backend/utils/adt/dumpcache.cThu Jan 1 12:00:00 1970
+++ pgsql/src/backend/utils/adt/dumpcache.c Thu Mar 3 11:51:53 2005
@@ -0,0 +1,119 @@
+/*-
+ *
+ * dumpcache.c
+ *display some contents for the buffer cache
+ *
+ *-
+ */
+#include "postgres.h"
+#include "funcapi.h"
+#include "catalog/pg_type.h"
+#include "storage/buf_internals.h"
+#include "storage/bufmgr.h"
+#include "utils/relcache.h"
+
+
+extern Datum dump_cache(PG_FUNCTION_ARGS);
+
+
+/*
+ * Function context for data persisting over repeated calls.
+ */
+typedef struct {
+ int buffer;
+ AttInMetadata *attinmeta;
+ BufferDesc *bufhdr;
+ RelFileNode rnode;
+ char*values[3];
+} dumpcache_fctx;
+
+
+/*
+ * Return a tuple that has bufferid, relfilenoide, reltablespace and
+ * reldatabase OIDs.
+ */
+Datum
+dump_cache(PG_FUNCTION_ARGS)
+{
+ FuncCallContext *funcctx;
+ Datum result;
+ MemoryContext oldcontext;
+ dumpcache_fctx *fctx; /* User function context. */
+ TupleDesc tupledesc;
+ HeapTuple tuple;
+
+ if (SRF_IS_FIRSTCALL())
+ {
+ funcctx = SRF_FIRSTCALL_INIT();
+
+ /* Switch context when allocating stuff to be used in later
calls */
+ oldcontext =
MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
+
+ /* construct a tuple to return */
+ tupledesc = CreateTemplateTupleDesc(4, false);
+ TupleDescInitEntry(tupledesc, (AttrNumber) 1, "bufferid",
+
INT4OID, -1, 0);
+ TupleDescInitEntry(tupledesc, (AttrNumber) 2, "relfilenode",
+ OIDOID,
-1, 0);
+ TupleDescInitEntry(tupledesc, (AttrNumber) 3, "reltablesp
Re: [PATCHES] WIP: buffer manager rewrite (take 2)
Bruce Momjian writes: > Was it a big benefit only for SMP machines? Probably. I did some simple pgbench checks and found that the new code seemed no better than the old on a one-processor machine. However, as long as it's not worse for a uniprocessor, who cares? It would be good to try to get some more measurements to verify this. Never did trust pgbench ... 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] WIP: buffer manager rewrite (take 2)
Tom Lane wrote: > Bruce Momjian writes: > > This is HUGE. Was it because of the clock sweep? > > No, it was because of the elimination of the global BufMgrLock. > Clock sweep is the price we had to pay to get that ... Wow, certainly stunning. Was it a big benefit only for SMP machines? -- 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] WIP: buffer manager rewrite (take 2)
Bruce Momjian writes: > This is HUGE. Was it because of the clock sweep? No, it was because of the elimination of the global BufMgrLock. Clock sweep is the price we had to pay to get that ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] WIP: buffer manager rewrite (take 2)
Tom Lane wrote: > Mark Wong <[EMAIL PROTECTED]> writes: > > CVS from 20050301 [ plus clock-sweep buffer manager ] : > > http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/ > > throughput 5483.01 > > I only ran this for 30 minutes, as opposed to 60, but it looks > > promising. > > > So about a 50% increase in throughput for my test. Not to shabby. ;) > > Sweet ... and the response-time improvement is just stunning. I think > we may have a winner. Is there a reason you didn't run the test longer > though? This is HUGE. Was it because of the clock sweep? -- 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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] WIP: buffer manager rewrite (take 2)
On Wed, Mar 02, 2005 at 08:48:35PM -0500, Tom Lane wrote: > Mark Wong <[EMAIL PROTECTED]> writes: > > CVS from 20050301 [ plus clock-sweep buffer manager ] : > > http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/ > > throughput 5483.01 > > I only ran this for 30 minutes, as opposed to 60, but it looks > > promising. > > > So about a 50% increase in throughput for my test. Not to shabby. ;) > > Sweet ... and the response-time improvement is just stunning. I think > we may have a winner. Is there a reason you didn't run the test longer > though? I would normally run for 1 hour, but I guess my fingers were thinking something different at the time. =P Mark ---(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] WIP: buffer manager rewrite (take 2)
Mark Wong <[EMAIL PROTECTED]> writes: > CVS from 20050301 [ plus clock-sweep buffer manager ] : > http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/ > throughput 5483.01 > I only ran this for 30 minutes, as opposed to 60, but it looks > promising. > So about a 50% increase in throughput for my test. Not to shabby. ;) Sweet ... and the response-time improvement is just stunning. I think we may have a winner. Is there a reason you didn't run the test longer though? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] snprintf improvements
Tom Lane wrote: > Bruce Momjian writes: > > This patch uses our own snprintf() only when NLS support is enabled, > > I see no point in this; it does not solve any problem we need solved, > only complicate the configuration behavior even more. Peter answered this. > > I added support for %qd and %I64d in snprintf. > > I consider this an awful idea as well. Moved into a NOT_USED block so we can keep it in case we want it later. -- 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] snprintf improvements
Tom Lane wrote: > Bruce Momjian writes: > > This patch uses our own snprintf() only when NLS support is > > enabled, > > I see no point in this; it does not solve any problem we need solved, > only complicate the configuration behavior even more. I think this is analogous to checking for snprintf() support of 64-bit integers only if we previously found 64-bit integers to be supported. We don't need to include our own snprintf() if we don't need the extra features it provides. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] snprintf improvements
Bruce Momjian writes: > This patch uses our own snprintf() only when NLS support is enabled, I see no point in this; it does not solve any problem we need solved, only complicate the configuration behavior even more. > I added support for %qd and %I64d in snprintf. I consider this an awful idea as well. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [BUGS] typos in the docu
On Wed, Mar 02, 2005 at 06:35:01PM +0100, Stefan Hans wrote: > http://developer.postgresql.org/docs/postgres/kernel-resources.html > > 16.5.1 > > "FreeBSD" > > ... > > $ systcl -w kern.ipc.shmall=32768 > $ systcl -w kern.ipc.shmmax=134217728 > $ systcl -w kern.ipc.semmap=256 > > "Linux" > ... > > $ systcl -w kernel.shmmax=134217728 > $ systcl -w kernel.shmall=2097152 > > systcl is wrong sysctl notStefan Patch attached. Thanks, Stefan :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ? sysctl.diff Index: doc/src/sgml/runtime.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v retrieving revision 1.305 diff -c -r1.305 runtime.sgml *** doc/src/sgml/runtime.sgml 26 Feb 2005 23:19:05 - 1.305 --- doc/src/sgml/runtime.sgml 2 Mar 2005 18:27:17 - *** *** 4360,4368 loader interfaces. The following parameters can be set using sysctl: ! $ systcl -w kern.ipc.shmall=32768 ! $ systcl -w kern.ipc.shmmax=134217728 ! $ systcl -w kern.ipc.semmap=256 To have these settings persist over reboots, modify /etc/sysctl.conf. --- 4360,4368 loader interfaces. The following parameters can be set using sysctl: ! $ sysctl -w kern.ipc.shmall=32768 ! $ sysctl -w kern.ipc.shmmax=134217728 ! $ sysctl -w kern.ipc.semmap=256 To have these settings persist over reboots, modify /etc/sysctl.conf. *** *** 4466,4473 and explicitly set the maximum total shared memory size to 2097152 pages (the default): ! $ systcl -w kernel.shmmax=134217728 ! $ systcl -w kernel.shmall=2097152 In addition these settings can be saved between reboots in /etc/sysctl.conf. --- 4466,4473 and explicitly set the maximum total shared memory size to 2097152 pages (the default): ! $ sysctl -w kernel.shmmax=134217728 ! $ sysctl -w kernel.shmall=2097152 In addition these settings can be saved between reboots in /etc/sysctl.conf. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] snprintf causes regression
Peter Eisentraut wrote: > Am Mittwoch, 2. M?rz 2005 16:50 schrieb Bruce Momjian: > > Right. It is Unix that has the problem. It seems we are supplying a > > special snprintf() only so gettext() in libintl will use ours instead of > > the operating system's. Isn't there a way to target just that library > > for our replacement snprintf()? Our code itself doesn't need the > > positional parameters. > > No, it's exactly our code that needs the snprintf(). libintl does not need > it. OK, I figured that out later. gettext() gets the string, but we are the ones to match the string to the args. > > Could we read the snprintf translation string and process positional > > parameters _before_ we sent it to gettext()? > > That would defeat the entire point of this exercise. Then translators would > have to translate each possible substitution separately and we wouldn't need > positional parameters at all. Right. Should we consider using a macro for snprintf/vsnprintf/printf in our code and map those to pg_* names so we don't let those symbols out of our code? The big problem is that client apps like psql need the port/snprintf functions we have. We actually have libpgport on the link line for clients so it is really only libpq exporting it that is a problem. If we could prevent that we would be fine. I think we got away with replacing system functions in the past because we were replacing either broken or missing functions. In this case, snprintf has a variety of format flags, some OS-specific, and the functionality we are adding is not critical in most applications. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] UTF8 or Unicode
Bruce Momjian writes: >> The correct encoding name is "UTF-8". > True, but Peter says the ANSI standard calls it UTF8 so that's what I > used. What SQL99 actually says is - UTF8 specifies the name of a character repertoire that consists of every character represented by The Unicode Standard Version 2.0 and by ISO/IEC 10646 UTF-8, where each character is encoded using the UTF-8 encoding, occupying from 1 (one) through 6 octets. That is, "UTF8" is an identifier chosen to refer to an encoding which they know perfectly well is really called UTF-8. We should probably follow the same convention of using UTF8 in code identifiers and UTF-8 in documentation. In particular, UTF_8 with an underscore is sanctioned by nobody and should be avoided. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] WIP: buffer manager rewrite (take 2)
On Wed, Feb 16, 2005 at 07:50:28PM -0500, Tom Lane wrote: > Second iteration of buffer manager rewrite. This uses the idea of a > usage counter instead of just a recently-used flag bit. I allowed the > counter to go up to 5, but some playing around with that value would > be interesting. (Tweak BM_MAX_USAGE_COUNT in > src/include/storage/buf_internals.h, then recompile the files in > src/backend/storage/buffer/.) Also there are more GUC variables now > for controlling the bgwriter. > I see a huge performance increase, when applied to CVS from 20050301. Baseline against 8.0.1: http://www.osdl.org/projects/dbt2dev/results/dev4-010/309/ throughput 3639.97 CVS from 20050301: http://www.osdl.org/projects/dbt2dev/results/dev4-010/314/ throughput 5483.01 I only ran this for 30 minutes, as opposed to 60, but it looks promising. So about a 50% increase in throughput for my test. Not to shabby. ;) Mark ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] snprintf causes regression tests
Am Mittwoch, 2. März 2005 16:50 schrieb Bruce Momjian: > Right. It is Unix that has the problem. It seems we are supplying a > special snprintf() only so gettext() in libintl will use ours instead of > the operating system's. Isn't there a way to target just that library > for our replacement snprintf()? Our code itself doesn't need the > positional parameters. No, it's exactly our code that needs the snprintf(). libintl does not need it. > Could we read the snprintf translation string and process positional > parameters _before_ we sent it to gettext()? That would defeat the entire point of this exercise. Then translators would have to translate each possible substitution separately and we wouldn't need positional parameters at all. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [pgsql-hackers-win32] [HACKERS] snprintf causes regression tests
Magnus Hagander wrote: > > Hmm ... > > > > First line of thought: we surely must not insert a snprintf > > into libpq.so unless it is 100% up to spec *and* has no > > performance issues ... neither of which can be claimed of the > > CVS-tip version. > > > > Second line of thought: libpq already feels free to insert > > allegedly up-to-spec versions of a number of things, and no > > one has complained. > > Maybe the linker prevents problems by not linking these > > versions to any calls from outside libpq? > > > > Third thought: Windows' linker seems to be broken enough that > > it may create problems of this ilk that exist on no other platform. > > If you're takling the combination of libpq and Windows, we are definitly > safe for dynamic linking, which is what most ppl will use. Because the > DLL will only export the entrypoitns that we explicitly define in the > DEF files, and those are also the only ones that are present in the > "import library". Right. It is Unix that has the problem. It seems we are supplying a special snprintf() only so gettext() in libintl will use ours instead of the operating system's. Isn't there a way to target just that library for our replacement snprintf()? Our code itself doesn't need the positional parameters. Could we read the snprintf translation string and process positional parameters _before_ we sent it to gettext()? -- 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] snprintf improvements
Peter Eisentraut wrote: > Am Mittwoch, 2. M?rz 2005 15:48 schrieb Bruce Momjian: > > This patch uses our own snprintf() only when NLS support is enabled, and > > I added support for %qd and %I64d in snprintf. We might need those in > > the final version if it is exported to apps. > > test -a is not portable. Thanks, fixed: if test "$enable_nls" = yes && test $pgac_need_repl_snprintf = no; then -- 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] snprintf improvements
Am Mittwoch, 2. März 2005 15:48 schrieb Bruce Momjian: > This patch uses our own snprintf() only when NLS support is enabled, and > I added support for %qd and %I64d in snprintf. We might need those in > the final version if it is exported to apps. test -a is not portable. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] snprintf improvements
This patch uses our own snprintf() only when NLS support is enabled, and
I added support for %qd and %I64d in snprintf. We might need those in
the final version if it is exported to apps.
--
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: configure
===
RCS file: /cvsroot/pgsql/configure,v
retrieving revision 1.430
diff -c -c -r1.430 configure
*** configure 28 Feb 2005 20:55:18 - 1.430
--- configure 2 Mar 2005 14:30:16 -
***
*** 14527,14533
# Force use of our snprintf if system's doesn't do arg control
! if test $pgac_need_repl_snprintf = no; then
echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
echo $ECHO_N "checking whether printf supports argument control... $ECHO_C"
>&6
if test "${pgac_cv_printf_arg_control+set}" = set; then
--- 14527,14534
# Force use of our snprintf if system's doesn't do arg control
! # This feature is used by NLS
! if test "$enable_nls" = yes -a $pgac_need_repl_snprintf = no; then
echo "$as_me:$LINENO: checking whether printf supports argument control" >&5
echo $ECHO_N "checking whether printf supports argument control... $ECHO_C"
>&6
if test "${pgac_cv_printf_arg_control+set}" = set; then
Index: configure.in
===
RCS file: /cvsroot/pgsql/configure.in,v
retrieving revision 1.403
diff -c -c -r1.403 configure.in
*** configure.in28 Feb 2005 20:55:18 - 1.403
--- configure.in2 Mar 2005 14:30:20 -
***
*** 1067,1073
# Force use of our snprintf if system's doesn't do arg control
! if test $pgac_need_repl_snprintf = no; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes
--- 1067,1074
# Force use of our snprintf if system's doesn't do arg control
! # This feature is used by NLS
! if test "$enable_nls" = yes -a $pgac_need_repl_snprintf = no; then
PGAC_FUNC_PRINTF_ARG_CONTROL
if test $pgac_cv_printf_arg_control != yes ; then
pgac_need_repl_snprintf=yes
Index: src/port/snprintf.c
===
RCS file: /cvsroot/pgsql/src/port/snprintf.c,v
retrieving revision 1.12
diff -c -c -r1.12 snprintf.c
*** src/port/snprintf.c 2 Mar 2005 05:22:22 - 1.12
--- src/port/snprintf.c 2 Mar 2005 14:30:26 -
***
*** 259,264
--- 259,281
else
longflag = 1;
goto nextch;
+ /*
+* We might export this to client
apps so we should
+* support 'qd' and 'I64d'(MinGW)
also in case the
+* native version does.
+*/
+ case 'q':
+ longlongflag = 1;
+ longflag = 1;
+ goto nextch;
+ case 'I':
+ if (*(format+1) == '6' &&
*(format+2) == '4')
+ {
+ format += 2;
+ longlongflag = 1;
+ longflag = 1;
+ goto nextch;
+ }
case 'u':
case 'U':
/*
fmtnum(value,base,dosign,ljust,len,zpad,&output) */
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] UTF8 or Unicode
Markus Bertheau ? wrote: > ? ???, 26/02/2005 ? 15:50 -0500, Bruce Momjian ?: > > > Other than that the other conversion files were already named fine, e.g. > > ascii_to_utf_8 (no UNICODE), however it is utf_8 and not utf8. I am > > unsure how to handle these. > > General remark about the spelling of this encoding: > > The correct encoding name is "UTF-8". > > "The official name and spelling of this encoding is UTF-8, where UTF > stands for UCS Transformation Format. Please do not write UTF-8 in any > documentation text in other ways (such as utf8 or UTF_8), unless of > course you refer to a variable name and not the encoding itself." > > from > > http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 True, but Peter says the ANSI standard calls it UTF8 so that's what I used. -- 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] [pgsql-hackers-win32] [HACKERS] snprintf causes regression tests to fail
> Hmm ... > > First line of thought: we surely must not insert a snprintf > into libpq.so unless it is 100% up to spec *and* has no > performance issues ... neither of which can be claimed of the > CVS-tip version. > > Second line of thought: libpq already feels free to insert > allegedly up-to-spec versions of a number of things, and no > one has complained. > Maybe the linker prevents problems by not linking these > versions to any calls from outside libpq? > > Third thought: Windows' linker seems to be broken enough that > it may create problems of this ilk that exist on no other platform. If you're takling the combination of libpq and Windows, we are definitly safe for dynamic linking, which is what most ppl will use. Because the DLL will only export the entrypoitns that we explicitly define in the DEF files, and those are also the only ones that are present in the "import library". //Magnus ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] UTF8 or Unicode
Ð ÐÐÑ, 26/02/2005 Ð 15:50 -0500, Bruce Momjian ÐÐÑÐÑ: > Other than that the other conversion files were already named fine, e.g. > ascii_to_utf_8 (no UNICODE), however it is utf_8 and not utf8. I am > unsure how to handle these. General remark about the spelling of this encoding: The correct encoding name is "UTF-8". "The official name and spelling of this encoding is UTF-8, where UTF stands for UCS Transformation Format. Please do not write UTF-8 in any documentation text in other ways (such as utf8 or UTF_8), unless of course you refer to a variable name and not the encoding itself." from http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8 Thanks -- Markus Bertheau â <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
