Re: [pgsql-patches] [PATCHES] Patch to log usage of temporary files
Hi all, Sorry for arriving so late into the discussion. I don't know if it's possible but it could be useful to have the text of the query which required the creation of the temporary files as an additional DETAIL line. At least, if it's possible to have it in this part of the code. Thoughts? -- Guillaume ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] [PATCHES] wal_checksum = on (default) | off
On Thu, Jan 11, 2007 at 11:10:38PM +, Simon Riggs wrote: On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote: Having a CRC in WAL but not in the heap seems kind of pointless. Yes... If your hardware is unreliable the corruption could anywhere. Agreed. I thought the point was that the WAL protects against unexpected power failure, that sort of thing. In that situation, the memory is the first to be corrupted, and an active DMA transfer will thus be corrupted also. We don't need to worry about the data, because the WAL is known to be accurate. The WAL does not protect against random data corruption, in normal operation it is never read. If we want to detect random corruption, we'd need checksum everywhere, yes. But that's not the goal here. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
[pgsql-patches] Allow dumping of roles or tablespaces
Per discussion on -hackers, the attached patch introduces an optional
parameter to pg_dumpall's -g (--globals-only) option to allow roles or
tablespaces to be dumped on their own.
eg.
pg_dumpall -g -- Dump roles and tablespaces per current behaviour
pg_dumpall -gr -- Dump roles only (or users and groups)
pg_dumpall -gt -- Dump tablespaces only
Regards, Dave.
Index: doc/src/sgml/ref/pg_dumpall.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_dumpall.sgml,v
retrieving revision 1.58
diff -c -r1.58 pg_dumpall.sgml
*** doc/src/sgml/ref/pg_dumpall.sgml7 Oct 2006 20:59:04 - 1.58
--- doc/src/sgml/ref/pg_dumpall.sgml12 Jan 2007 14:01:10 -
***
*** 130,140
/varlistentry
varlistentry
! termoption-g/option/term
! termoption--globals-only/option/term
listitem
para
! Dump only global objects (users and groups), no databases.
/para
/listitem
/varlistentry
--- 130,145
/varlistentry
varlistentry
! termoption-g[replaceable
class=parameterr/replaceable|replaceable
class=parametert/replaceable/option/term
! termoption--globals-only[=replaceable
class=parameterr/replaceable|replaceable
class=parametert/replaceable/option/term
listitem
para
! Dump only global objects (roles and/or tablespaces), no databases.
! The replaceable class=parameterr/replaceable parameter will
! cause only roles to be dumped, and the
! replaceable class=parametert/replaceable parameter will cause
! only tablespaces to be dumped. If no parameter is specified, all
! global object types will be dumped.
/para
/listitem
/varlistentry
Index: src/bin/pg_dump/pg_dumpall.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dumpall.c,v
retrieving revision 1.86
diff -c -r1.86 pg_dumpall.c
*** src/bin/pg_dump/pg_dumpall.c5 Jan 2007 22:19:48 - 1.86
--- src/bin/pg_dump/pg_dumpall.c12 Jan 2007 14:01:12 -
***
*** 78,83
--- 78,85
boolforce_password = false;
booldata_only = false;
boolglobals_only = false;
+ boolroles_only = false;
+ booltablespaces_only = false;
boolschema_only = false;
PGconn *conn;
int encoding;
***
*** 91,97
{inserts, no_argument, NULL, 'd'},
{attribute-inserts, no_argument, NULL, 'D'},
{column-inserts, no_argument, NULL, 'D'},
! {globals-only, no_argument, NULL, 'g'},
{host, required_argument, NULL, 'h'},
{ignore-version, no_argument, NULL, 'i'},
{oids, no_argument, NULL, 'o'},
--- 93,99
{inserts, no_argument, NULL, 'd'},
{attribute-inserts, no_argument, NULL, 'D'},
{column-inserts, no_argument, NULL, 'D'},
! {globals-only, optional_argument, NULL, 'g'},
{host, required_argument, NULL, 'h'},
{ignore-version, no_argument, NULL, 'i'},
{oids, no_argument, NULL, 'o'},
***
*** 161,167
pgdumpopts = createPQExpBuffer();
! while ((c = getopt_long(argc, argv, acdDgh:ioOp:sS:U:vWxX:,
long_options, optindex)) != -1)
{
switch (c)
{
--- 163,169
pgdumpopts = createPQExpBuffer();
! while ((c = getopt_long(argc, argv, acdDg::h:ioOp:sS:U:vWxX:,
long_options, optindex)) != -1)
{
switch (c)
{
***
*** 181,186
--- 183,203
case 'g':
globals_only = true;
+ if (optarg)
+ {
+ if (strcmp(optarg, r) == 0)
+ roles_only = true;
+ else if (strcmp(optarg, t) == 0)
+ tablespaces_only = true;
+ else
+ {
+ fprintf(stderr,
+ _(%s: invalid
-g option -- %s\n),
+ progname,
optarg);
+ fprintf(stderr, _(Try \%s
--help\ for more information.\n), progname);
+ exit(1);
+ }
+ }
break;
Re: [pgsql-patches] Allow dumping of roles or tablespaces
Dave Page [EMAIL PROTECTED] writes: pg_dumpall -g -- Dump roles and tablespaces per current behaviour pg_dumpall -gr -- Dump roles only (or users and groups) pg_dumpall -gt -- Dump tablespaces only This seems a bit ugly, mainly because (1) it doesn't have a natural translation to long-form switches, and (2) it screws up the usual habit of merging multiple single-letter switches into one argument. Perhaps something like --roles-only --tablespaces-only --globals-only Not sure if there are free single-letter codes for the first two, but on the whole I'm more interested in having sane long-form names than sane short ones ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [pgsql-patches] Allow dumping of roles or tablespaces
Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: pg_dumpall -g -- Dump roles and tablespaces per current behaviour pg_dumpall -gr -- Dump roles only (or users and groups) pg_dumpall -gt -- Dump tablespaces only This seems a bit ugly, mainly because (1) it doesn't have a natural translation to long-form switches, and (2) it screws up the usual habit of merging multiple single-letter switches into one argument. Perhaps something like --roles-only --tablespaces-only --globals-only Not sure if there are free single-letter codes for the first two, but on the whole I'm more interested in having sane long-form names than sane short ones ... I agree. In fact, as I understand the patch it would also allow -g r and -g t, and that seems ugly too. We don't have to have a short form for every long option - e.g. initdb has several like --no-locale for which there is no corresponding short form. I suggest we make the new options long form only, along the lines Tom suggests. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] vcbuild - conditional regeneration
On Thu, Jan 11, 2007 at 10:36:11PM +0100, Magnus Hagander wrote: The attached patch changes vcbuild so the project and solution files are only regenerated if they are actually changed. This helps when you're developing in the Visual Studio GUI, because updating the files (even to the same contents) will cause a reload and re-parse of all the projects in the solution. As a bonus, it doesn't trash the project file if it for some reason aborts half-way through. The patch includes part of the previously sent patch about pthreads requirements, because they change the same area. Should be workable without the other one as well, so it's no problem applying just one of them if the other one is troublesome. While reviewing this patch for conflicts that Neil reported (seems to have something to do with my local CVS repository. I think I need to switch back to using the network based CVS repo and just stop diffing things when not connected or during travel), I found a case where this simply breaks functionality completely. So please ignore this patch compeltely. //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] Allow dumping of roles or tablespaces
Andrew Dunstan wrote: Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: pg_dumpall -g -- Dump roles and tablespaces per current behaviour pg_dumpall -gr -- Dump roles only (or users and groups) pg_dumpall -gt -- Dump tablespaces only This seems a bit ugly, mainly because (1) it doesn't have a natural translation to long-form switches, and (2) it screws up the usual habit of merging multiple single-letter switches into one argument. Perhaps something like --roles-only --tablespaces-only --globals-only Not sure if there are free single-letter codes for the first two, but on the whole I'm more interested in having sane long-form names than sane short ones ... I agree. In fact, as I understand the patch it would also allow -g r and -g t, and that seems ugly too. We don't have to have a short form for every long option - e.g. initdb has several like --no-locale for which there is no corresponding short form. I suggest we make the new options long form only, along the lines Tom suggests. OK, no probs. I'll fix it up as Tom suggests. Regards, Dave. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] Allow dumping of roles or tablespaces
Am Freitag, 12. Januar 2007 15:08 schrieb Dave Page: pg_dumpall -g -- Dump roles and tablespaces per current behaviour pg_dumpall -gr -- Dump roles only (or users and groups) pg_dumpall -gt -- Dump tablespaces only Also note that optional argument specifications in getopt like g:: are not portable, so this cannot be implemented in the first place. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Maybe we could forcibly activate the freeze mode on a template database?
Might not be a bad idea. And even more to the point, forcibly disable
analyze.
Patch implementing this (albeit untested!) attached. I'll try to
reproduce the problem without the patch, and then test with the patch
applied.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: src/backend/postmaster/autovacuum.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/postmaster/autovacuum.c,v
retrieving revision 1.5.2.6
diff -c -p -r1.5.2.6 autovacuum.c
*** src/backend/postmaster/autovacuum.c 19 May 2006 15:15:38 - 1.5.2.6
--- src/backend/postmaster/autovacuum.c 12 Jan 2007 15:49:52 -
*** autovac_get_database_list(void)
*** 482,511
}
/*
! * Process a whole database. If it's a template database or is disallowing
! * connection by means of datallowconn=false, then issue a VACUUM FREEZE.
! * Else use a plain VACUUM.
*/
! static void
! process_whole_db(void)
{
! Relation dbRel;
ScanKeyData entry[1];
SysScanDesc scan;
HeapTuple tup;
- Form_pg_database dbForm;
- bool freeze;
-
- /* Start a transaction so our commands have one to play into. */
- StartTransactionCommand();
-
- /* functions in indexes may want a snapshot set */
- ActiveSnapshot = CopySnapshot(GetTransactionSnapshot());
-
- /*
- * Clean up any dead statistics collector entries for this DB.
- */
- pgstat_vacuum_tabstat();
dbRel = heap_open(DatabaseRelationId, AccessShareLock);
--- 482,500
}
/*
! * Return a palloc'ed copy of the pg_database entry for the given database.
! * Note that no lock is retained on the entry whatsoever, so it may be stale by
! * the time the caller inspects it. This is sufficient for our purposes
! * however.
*/
! static Form_pg_database
! get_pg_database_entry(Oid dbid)
{
! Form_pg_database dbForm;
ScanKeyData entry[1];
+ Relation dbRel;
SysScanDesc scan;
HeapTuple tup;
dbRel = heap_open(DatabaseRelationId, AccessShareLock);
*** process_whole_db(void)
*** 523,539
if (!HeapTupleIsValid(tup))
elog(ERROR, could not find tuple for database %u, MyDatabaseId);
! dbForm = (Form_pg_database) GETSTRUCT(tup);
!
! if (!dbForm-datallowconn || dbForm-datistemplate)
! freeze = true;
! else
! freeze = false;
systable_endscan(scan);
heap_close(dbRel, AccessShareLock);
elog(DEBUG2, autovacuum: VACUUM%s whole database,
(freeze) ? FREEZE : );
--- 512,555
if (!HeapTupleIsValid(tup))
elog(ERROR, could not find tuple for database %u, MyDatabaseId);
! dbForm = (Form_pg_database) palloc(sizeof(FormData_pg_database));
! memcpy(dbForm, GETSTRUCT(tup), sizeof(FormData_pg_database));
systable_endscan(scan);
heap_close(dbRel, AccessShareLock);
+ return dbForm;
+ }
+
+ /*
+ * Process a whole database. If it's a template database or is disallowing
+ * connection by means of datallowconn=false, then issue a VACUUM FREEZE.
+ * Else use a plain VACUUM.
+ */
+ static void
+ process_whole_db(void)
+ {
+ Form_pg_database dbForm;
+ bool freeze;
+
+ /* Start a transaction so our commands have one to play into. */
+ StartTransactionCommand();
+
+ /* functions in indexes may want a snapshot set */
+ ActiveSnapshot = CopySnapshot(GetTransactionSnapshot());
+
+ /*
+ * Clean up any dead statistics collector entries for this DB.
+ */
+ pgstat_vacuum_tabstat();
+
+ dbForm = get_pg_database_entry(MyDatabaseId);
+
+ freeze = (!dbForm-datallowconn || dbForm-datistemplate);
+
+ pfree(dbForm);
+
elog(DEBUG2, autovacuum: VACUUM%s whole database,
(freeze) ? FREEZE : );
*** do_autovacuum(PgStat_StatDBEntry *dbentr
*** 564,569
--- 580,587
List *toast_table_ids = NIL;
ListCell *cell;
PgStat_StatDBEntry *shared;
+ Form_pg_database dbForm;
+ bool istemplate;
/* Start a transaction so our commands have one to play into. */
StartTransactionCommand();
*** do_autovacuum(PgStat_StatDBEntry *dbentr
*** 579,584
--- 597,610
pgstat_vacuum_tabstat();
/*
+ * In a template database, we need to avoid putting our Xid in any table,
+ * so disallow analyzes and force use of VACUUM FREEZE.
+ */
+ dbForm = get_pg_database_entry(MyDatabaseId);
+ istemplate = (!dbForm-datallowconn || dbForm-datistemplate);
+ pfree(dbForm);
+
+ /*
* StartTransactionCommand and CommitTransactionCommand will automatically
* switch to other contexts. We need this one to keep the list of
* relations to vacuum/analyze across transactions.
*** do_autovacuum(PgStat_StatDBEntry *dbentr
*** 694,703
VacuumCostDelay = tab-vacuum_cost_delay;
VacuumCostLimit =
Re: [pgsql-patches] [HACKERS] [PATCHES] Patch to log usage of
Simon Riggs wrote: On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote: The trace probe was incorrect Yes, incomplete, no doubt. On that point you were 100% right to reject. and kind of at an odd place. I don't think we want to go down the road of throwing trace in everwhere, do we? I would like to see a more systematic approach to it. I guess my systematic approach was to add PG_TRACE to all new log points from now on, so we have a choice of which trace/log mechanism to use. I think the right approach is to look at our existing code and come up with places we want them, and add them in one shot. Doing thing in small parts doesn't work too well with a project this size. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] [HACKERS] [PATCHES] Patch to log usage oftemporary files
On Fri, 2007-01-12 at 11:44 -0500, Bruce Momjian wrote: I think the right approach is to look at our existing code and come up with places we want them, and add them in one shot. Doing thing in small parts doesn't work too well with a project this size. Will do. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of temporary files
Guillaume Smet [EMAIL PROTECTED] writes: On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote: (2) there is already a generalized solution to this, it's called log_min_error_statement. I didn't think of that when posting my message but Bruce seems to say that we can't use it in this case. Dunno why he thinks that. But there is a point here that could use improvement: shouldn't log_min_error_statement be measured on the same scale as log_min_messages, ie, LOG is relatively high priority rather than relatively low priority? As the code stands, you'd have to knock it down to DEBUG1 in order to see the statement generating a LOG message. This might be harmless (since messages below log_min_messages won't generate log output at all), but it's surely a bit confusing. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [pgsql-patches] [PATCHES] Patch to log usage of temporary
Guillaume Smet wrote: On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: Usually people don't want th query unless they ask for it. One nify trick would be to print the query as DETAIL unless they are already logging queries, but that just seems too complex. If you want the query, why not just log them all? Because they can't? On a highly loaded production server, people usually don't log all the queries. Anyway, if it's too complicated to implement it, perhaps it's not worth it. I'm just curious to see how people will use this information if they don't know why the temp file was created. We have to balance functionality and ease of use. That is the way I analyze these issue. We usually wait for a few people to request additional functionality of this type, and then figure out the cleanest way to implement it. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [PATCHES] Patch to log usage of temporary files
On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: Usually people don't want th query unless they ask for it. One nify trick would be to print the query as DETAIL unless they are already logging queries, but that just seems too complex. If you want the query, why not just log them all? Because they can't? On a highly loaded production server, people usually don't log all the queries. Anyway, if it's too complicated to implement it, perhaps it's not worth it. I'm just curious to see how people will use this information if they don't know why the temp file was created. -- Guillaume ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Alvaro Herrera wrote: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Maybe we could forcibly activate the freeze mode on a template database? Might not be a bad idea. And even more to the point, forcibly disable analyze. Patch implementing this (albeit untested!) attached. I'll try to reproduce the problem without the patch, and then test with the patch applied. Ok, it does what it's intended to do. But in testing it I also confirmed that a database-wide vacuum creates a pgstat entry for it and for all tables in it. Is this something we want to prevent? I'll apply this patch later today to the 8.1 branch unless somebody objects. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Alvaro Herrera [EMAIL PROTECTED] writes: Ok, it does what it's intended to do. But in testing it I also confirmed that a database-wide vacuum creates a pgstat entry for it and for all tables in it. Is this something we want to prevent? That's odd, because I didn't see any such thing when I tested in CVS tip the other day. Or did you have stats_block_level turned on? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-patches] [PATCHES] Patch to log usage of
Tom Lane wrote: Guillaume Smet [EMAIL PROTECTED] writes: On 1/12/07, Tom Lane [EMAIL PROTECTED] wrote: (2) there is already a generalized solution to this, it's called log_min_error_statement. I didn't think of that when posting my message but Bruce seems to say that we can't use it in this case. Dunno why he thinks that. But there is a point here that could use improvement: shouldn't log_min_error_statement be measured on the same scale as log_min_messages, ie, LOG is relatively high priority rather than relatively low priority? As the code stands, you'd have to knock it down to DEBUG1 in order to see the statement generating a LOG message. This might be harmless (since messages below log_min_messages won't generate log output at all), but it's surely a bit confusing. I assume log_min_error_messages wasn't supported because it isn't listed in the postgresql.conf file as a valid value. Let me look at adding LOG in there in the place you suggest. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Ok, it does what it's intended to do. But in testing it I also confirmed that a database-wide vacuum creates a pgstat entry for it and for all tables in it. Is this something we want to prevent? That's odd, because I didn't see any such thing when I tested in CVS tip the other day. Or did you have stats_block_level turned on? Yes, I turned it on for this test. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] [PATCHES] Patch to log usage of temporary files
In response to Guillaume Smet [EMAIL PROTECTED]: On 1/12/07, Bruce Momjian [EMAIL PROTECTED] wrote: Usually people don't want th query unless they ask for it. One nify trick would be to print the query as DETAIL unless they are already logging queries, but that just seems too complex. If you want the query, why not just log them all? Because they can't? On a highly loaded production server, people usually don't log all the queries. Anyway, if it's too complicated to implement it, perhaps it's not worth it. I'm just curious to see how people will use this information if they don't know why the temp file was created. I can only speak for myself but: * I'm already using the patch in our lab. Since the lab is the same hardware/config/etc as production, I can use the information to fine tune configs that then get migrated to production after careful testing. Since it's a lab environment, I'm free to turn on and off all sorts of stuff that would be unwise in production. Thus the lab frequently has full query logging turned on. * Currently, our production systems have plenty of spare IO. The result is that I _do_ log queries on production servers, and will continue to do so until it becomes an issue. Additionally, we have lots of room to grow with this hardware, so I can use the data collected about temp file usage to justify additional RAM. Don't know how long I'll be able to leave query logging enabled on the production systems, but I'm taking advantage of it as long as possible. * This variable can be tweaked per-session, which means if I've got queries that I suspect are causing unwarranted temp files on a production server, I can enable it on a per-connection basis to track down the problem and work on a specific query, on production systems, without too much disruption of the rest of the work that's going on: set log_temp_files = 0; run suspect query set log_temp_files = -1; investigate logs At least, those are my current plans ... -- Bill Moran Collaborative Fusion Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] [HACKERS] NaN behavior
On Thu, 2007-01-11 at 21:04 -0500, Neil Conway wrote: Comments? I'll write up a doc patch, barring any objections. I'll apply the attached doc patch to CVS tomorrow, barring any objections. -Neil Index: doc/src/sgml/datatype.sgml === RCS file: /home/neilc/postgres/cvs_root/pgsql/doc/src/sgml/datatype.sgml,v retrieving revision 1.183 diff -c -p -r1.183 datatype.sgml *** doc/src/sgml/datatype.sgml 22 Dec 2006 22:09:31 - 1.183 --- doc/src/sgml/datatype.sgml 12 Jan 2007 21:52:22 - *** *** 438,447 sect2 id=datatype-numeric-decimal titleArbitrary Precision Numbers/title ! indexterm zone=datatype-numeric-decimal primarynumeric (data type)/primary /indexterm indexterm primarydecimal/primary seenumeric/see --- 438,451 sect2 id=datatype-numeric-decimal titleArbitrary Precision Numbers/title ! indexterm primarynumeric (data type)/primary /indexterm +indexterm + primaryarbitrary precision numbers/primary +/indexterm + indexterm primarydecimal/primary seenumeric/see *** NUMERIC *** 515,520 --- 519,529 plus eight bytes overhead. /para + indexterm + primarynot a number/primary + secondarynumeric (data type)/secondary + /indexterm + para In addition to ordinary numeric values, the typenumeric/type type allows the special value literalNaN/, meaning *** NUMERIC *** 525,530 --- 534,551 the string literalNaN/ is recognized in a case-insensitive manner. /para + note + para + In most implementations of the quotenot-a-number/ concept, + literalNaN/ is not considered equal to any other numeric + value (including literalNaN/). In order to allow + typenumeric/ values to be sorted and used in tree-based + indexes, productnamePostgreSQL/ treats literalNaN/ + values as equal, and greater than all non-literalNaN/ + values. + /para + /note + para The types typedecimal/type and typenumeric/type are equivalent. Both types are part of the acronymSQL/acronym *** NUMERIC *** 613,618 --- 634,644 from zero will cause an underflow error. /para + indexterm + primarynot a number/primary + secondarydouble precision/secondary + /indexterm + para In addition to ordinary numeric values, the floating-point types have several special values: *** NUMERIC *** 631,636 --- 657,673 these strings are recognized in a case-insensitive manner. /para + note + para + IEEE754 specifies that literalNaN/ should not compare equal + to any other floating-point value (including literalNaN/). + In order to allow floating-point values to be sorted and used + in tree-based indexes, productnamePostgreSQL/ treats + literalNaN/ values as equal, and greater than all + non-literalNaN/ values. + /para + /note + para productnamePostgreSQL/productname also supports the SQL-standard notations typefloat/type and ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
