Re: [pgsql-patches] guid/uuid datatype
I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is then going to be on the client side. The uuid type is very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). Regards, Gevik. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] pg_dump pretty_print
Greg Sabino Mullane wrote: Atached is a patch to allow pretty printing of system objects (constraints, indexes, rules, and views) when doing a pg_dump via a --pretty-print flag along with a warning in the docs to be careful about doing so :) Could you provide a less hand-waving specification of this feature? At the moment it sounds like This option does something fun, but we're not sure what it is. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] scrollable cursor sup. for SPI
Hello, I am working on new version. Old patch doesn't solve scrollability well. Regards Pavel Stehule Where are we on this patch? --- Pavel Stehule wrote: Pavel Stehule [EMAIL PROTECTED] writes: if I comprehended it well CURSOR_OPT_SCROLL is set only when SCROLL is cheap (not when is possible). It's true? Nope. If you want a scrollable plan you need to make sure you tell the planner about it. SPI_cursor_open is not in charge, it's merely looking at what the planner did. As for that other stuff, when and if we support it, it would be time to add a SPI entry point that supports it. I'm disinclined to add an API on speculation though --- by the time the feature actually exists, we might not like the API anymore anyway. I did step back and did some test. game with CURSOR_OPT_SCROLL has not sense in SPI_cursor_open. I didn't tests with table's joins where this problem is visible before. I propose add new function SPI_prepare_with_option(..) which allow set option for planner. Isn't problem add to SPI_open_cursor assert for holdable cursors. This needs propably rewriting functions pg_plan_query and pg_plan_queries. Or new function SPI_prepare_cursor(...) which can be similar PerformCursorOpen. This doesn't change others functions. All comments are welcome Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] O_DIRECT support for Windows
We're ok with the alignment issues provided the is code added to reject O_DIRECT if the sector size is too large. We also said we need to see some performance numbers on the effect of the patch before it goes in. //Magnus Bruce Momjian wrote: So, do we want this patch? Are we OK on WIN32 alignment issues? --- ITAGAKI Takahiro wrote: The attached is a patch to define O_DIRECT by ourselves on Windows, and to map O_DIRECT to FILE_FLAG_NO_BUFFERING. There will be a consistency in our support between Windows and other OSes that have O_DIRECT. Also, there is the following comment that says, I read, we should do so. | handle other flags? (eg FILE_FLAG_NO_BUFFERING/FILE_FLAG_WRITE_THROUGH) Is this worth doing? Do we need more performance reports for the change? Regards, --- ITAGAKI Takahiro NTT Open Source Software Center [ Attachment, skipping... ] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [pgsql-patches] guid/uuid datatype
Gevik Babakhani wrote: I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is then going to be on the client side. The uuid type is very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). But does it really help if you don't have the generator? I don't use UUIDs much myself, but I think in all cases I've seen that use the uuid type in SQL Server they're also using the generator function. Those that just store UUIDs in the database often just uses varchar - in order to be more portable, I guess. Not saying it wouldn't be good to have uuid for portability, I'm just a bit unsure of how much use it is without a generator function... //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [pgsql-patches] guid/uuid datatype
But does it really help if you don't have the generator? I don't use UUIDs much myself, but I think in all cases I've seen that use the uuid type in SQL Server they're also using the generator function. Those that just store UUIDs in the database often just uses varchar - in order to be more portable, I guess. There could be many algorithms to generate a guid. I guess we will get into a big debate on that, which is not much useful i guess (seeing the posts last year). In most cases I have seen the guid is generated by the client. In case of M$ Sql is also can be generated on the server but, in our case we generate the guids ourselves because with our algorithm we can trace the guid back to where it exactly was originated. (app requirement) One thing is for sure, having varchar to store guids ( varchar(32) ) is not that efficient. Regards, Gevik. ---(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: [pgsql-patches] guid/uuid datatype
Magnus Hagander wrote: Gevik Babakhani wrote: I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is then going to be on the client side. The uuid type is very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). But does it really help if you don't have the generator? We could have all the type code in core, and the generator in contrib or pgfoundry. That way the user can choose the most appropriate generator, even if it's platform-specific. Or he can choose to use a client-side generator. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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] guid/uuid datatype
Alvaro Herrera wrote: Magnus Hagander wrote: Gevik Babakhani wrote: I'd be willing to accept a core uuid type sans generator function, but is that really all that useful? This is also a point I remember from the last discussions. To not to include the generator in the core. The generation of the uuid is then going to be on the client side. The uuid type is very useful, especially when migrating from other systems to pg (ms-pg or syb-pg). But does it really help if you don't have the generator? We could have all the type code in core, and the generator in contrib or pgfoundry. That way the user can choose the most appropriate generator, even if it's platform-specific. Or he can choose to use a client-side generator. that seems like a good compromise - have the type in core and generators in contrib/pgfoundry. In one or two releases we might see some feedback on the portability and how people use those and could decide on leaving it that way or move the generators into core as well. Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] guid/uuid datatype
Gevik Babakhani wrote: There could be many algorithms to generate a guid. I guess we will get into a big debate on that, which is not much useful i guess (seeing the posts last year). There are a handful of standardized or established algorithms, so it doesn't hurt to provide them all. Compare pgcrypto -- certainly no one needs all those encryption algorithms, but we offer them. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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
[pgsql-patches] Code cleanup
Applied patch attached that moves code that places LOG error level
between ERROR and PANIC into new function is_log_level_output(), for
code clarity.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/error/elog.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/error/elog.c,v
retrieving revision 1.179
diff -c -c -r1.179 elog.c
*** src/backend/utils/error/elog.c 5 Jan 2007 22:19:43 - 1.179
--- src/backend/utils/error/elog.c 20 Jan 2007 14:34:25 -
***
*** 121,126
--- 121,127
static const char *useful_strerror(int errnum);
static const char *error_severity(int elevel);
static void append_with_tabs(StringInfo buf, const char *str);
+ static int is_log_level_output(int elevel, int log_min_level);
/*
***
*** 139,145
const char *funcname)
{
ErrorData *edata;
! bool output_to_server = false;
bool output_to_client = false;
int i;
--- 140,146
const char *funcname)
{
ErrorData *edata;
! bool output_to_server;
bool output_to_client = false;
int i;
***
*** 196,228
/* Determine whether message is enabled for server log output */
if (IsPostmasterEnvironment)
! {
! /* Complicated because LOG is sorted out-of-order for this purpose */
! if (elevel == LOG || elevel == COMMERROR)
! {
! if (log_min_messages == LOG)
! output_to_server = true;
! else if (log_min_messages FATAL)
! output_to_server = true;
! }
! else
! {
! /* elevel != LOG */
! if (log_min_messages == LOG)
! {
! if (elevel = FATAL)
! output_to_server = true;
! }
! /* Neither is LOG */
! else if (elevel = log_min_messages)
! output_to_server = true;
! }
! }
else
- {
/* In bootstrap/standalone case, do not sort LOG out-of-order */
output_to_server = (elevel = log_min_messages);
- }
/* Determine whether message is enabled for client output */
if (whereToSendOutput == DestRemote elevel != COMMERROR)
--- 197,206
/* Determine whether message is enabled for server log output */
if (IsPostmasterEnvironment)
! output_to_server = is_log_level_output(elevel, log_min_messages);
else
/* In bootstrap/standalone case, do not sort LOG out-of-order */
output_to_server = (elevel = log_min_messages);
/* Determine whether message is enabled for client output */
if (whereToSendOutput == DestRemote elevel != COMMERROR)
***
*** 2073,2075
--- 2051,2078
#endif
va_end(ap);
}
+
+
+ static int is_log_level_output(int elevel, int log_min_level)
+ {
+ /*
+ * Complicated because LOG is sorted out-of-order here, between
+ * ERROR and FATAL.
+ */
+ if (elevel == LOG || elevel == COMMERROR)
+ {
+ if (log_min_level == LOG || log_min_level = ERROR)
+ return true;
+ }
+ else if (log_min_level == LOG)
+ {
+ /* elevel != LOG */
+ if (elevel = FATAL)
+ return true;
+ }
+ /* Neither is LOG */
+ else if (elevel = log_min_level)
+ return true;
+
+ return false;
+ }
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [pgsql-patches] [PATCHES] Tablespace for temporary
Patch withdrawn by author; corrected version expected.
---
Jaime Casanova wrote:
On 1/13/07, Albert Cervera Areny [EMAIL PROTECTED] wrote:
It was already possible to set the guc on postgresql.conf when I posted the
patch...
ok... fixed... the problem was that this code only let
num_temp_tablespaces be greater than zero when we are in an
interactive command (eg. a SET command) but setting the guc from
postgresql.conf at startup time is not interactive so
num_temp_tablespaces is zero and when i try to get the first temp
tablespace to use (MyProcPid % num_temp_tablespaces) causes a floatin
exception (division by zero).
+ if (source = PGC_S_INTERACTIVE IsTransactionState())
+ {
+ /*
+* Verify that all the names are valid tablspace names
+* We do not check for USAGE rights should we?
+*/
+ foreach(l, namelist)
+ {
+ char *curname = (char *) lfirst(l);
+
+ if (get_tablespace_oid(curname) == InvalidOid)
+ ereport((source == PGC_S_TEST) ? NOTICE : ERROR,
+ (errcode(ERRCODE_UNDEFINED_OBJECT),
+ errmsg(tablespace \%s\ does not exist, curname)));
+
+ num_temp_tablespaces++;
+ }
+ }
new patch added, with that piece of code refactored to let
num_temp_tablespaces get a value greater than zero always that the guc
is setted, i also add some docs.
the patch passes all 104 regression tests and all my tests as well...
i think the patch is ready to be applied to HEAD, any committer want
to review it?
--
regards,
Jaime Casanova
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning.
Richard Cook
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(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: [pgsql-patches] guid/uuid datatype
On Fri, 2007-01-19 at 23:00 -0500, Tom Lane wrote: Per previous discussion, the main problem with a uuid type is the new-uuid generator function, which tends to involve a bunch of not-so-portable assumptions and code. RFC 4122 specifies several ways of generating UUIDs: * via the computer's MAC address and the time since the Gregorian epoch in nanoseconds * via MD5 or SHA1 hashing of a given string of URL, or similar identifier * via a PSRNG Only the first of these presents any portability concerns, AFAICS. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [PATCHES] psql \lo_* quiet mode patch
Patch applied by Neil. --- Jeremy Drake wrote: I sent this in rather late in the 8.2 cycle, so now that 8.3 development is underway I thought I'd try sending it again. This patch was necessary in the development of a large object regression test, but is logically seperate and reasonable even without that test, so I'm sending it in seperately for independant consideration. I'll save my pushing on the large object test until this one gets in ;) -- Forwarded message -- Date: Thu, 26 Oct 2006 15:58:07 -0700 (PDT) From: Jeremy Drake [EMAIL PROTECTED] To: PostgreSQL Patches pgsql-patches@postgresql.org Subject: [PATCHES] psql \lo_* quiet mode patch I sent this in a while back, but never heard anything about it. This patch makes psql's \lo_* commands respect the -q flag (or other methods of setting quiet mode) as well as HTML output mode. This came in very handy when writing a regression test which uses the \lo_import command since it would otherwise output the OID of the new large object which would be different every run. Please let me know if it is ok, or if I need to do it differently. -- Let me assure you that to us here at First National, you're not just a number. You're two numbers, a dash, three more numbers, another dash and another number. -- James Estes Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
[pgsql-patches] Clean up postgresql.conf
The attached, applied paqtch modifies max_fsm_pages in postgresql.conf.sample to show a typical value, rather than a value too high. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: backend/utils/misc/postgresql.conf.sample === RCS file: /cvsroot/pgsql/src/backend/utils/misc/postgresql.conf.sample,v retrieving revision 1.202 diff -c -r1.202 postgresql.conf.sample *** backend/utils/misc/postgresql.conf.sample 16 Jan 2007 18:26:02 - 1.202 --- backend/utils/misc/postgresql.conf.sample 20 Jan 2007 17:03:03 - *** *** 111,117 # - Free Space Map - ! #max_fsm_pages = 1638400 # min max_fsm_relations*16, 6 bytes each # (change requires restart) #max_fsm_relations = 1000 # min 100, ~70 bytes each # (change requires restart) --- 111,117 # - Free Space Map - ! #max_fsm_pages = 204800 # min max_fsm_relations*16, 6 bytes each # (change requires restart) #max_fsm_relations = 1000 # min 100, ~70 bytes each # (change requires restart) Index: bin/initdb/initdb.c === RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v retrieving revision 1.128 diff -c -r1.128 initdb.c *** bin/initdb/initdb.c 6 Jan 2007 19:40:00 - 1.128 --- bin/initdb/initdb.c 20 Jan 2007 17:03:04 - *** *** 1251,1257 conflines = replace_token(conflines, #shared_buffers = 32MB, repltok); snprintf(repltok, sizeof(repltok), max_fsm_pages = %d, n_fsm_pages); ! conflines = replace_token(conflines, #max_fsm_pages = 1638400, repltok); #if DEF_PGPORT != 5432 snprintf(repltok, sizeof(repltok), #port = %d, DEF_PGPORT); --- 1251,1257 conflines = replace_token(conflines, #shared_buffers = 32MB, repltok); snprintf(repltok, sizeof(repltok), max_fsm_pages = %d, n_fsm_pages); ! conflines = replace_token(conflines, #max_fsm_pages = 204800, repltok); #if DEF_PGPORT != 5432 snprintf(repltok, sizeof(repltok), #port = %d, DEF_PGPORT); ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [pgsql-patches] largeobject regression tests - updated patch
On Fri, 2007-01-19 at 17:08 -0800, Jeremy Drake wrote: Oops, that patch did not actually apply cleanly. Try this one instead, it should. Please disregard the previous copy. Sorry. I applied both the psql \lo quiet mode patch and this patch, both with some very minor revisions. Thanks for the patches. -Neil ---(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: [pgsql-patches] guid/uuid datatype
On Sat, 2007-01-20 at 14:56 +0100, Gevik Babakhani wrote: what is the next step now? is there going to be review by a committer? if so, please note that the OIDs in the patch have to be changed. I already suggested a few things you could improve in the patch. If this discussion concludes that the patch should be included in the core backend and you submit a revised patch, I'd be happy to review and apply it. -Neil ---(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] [PATCHES] currentItemData refactoring
Patch applied by Neil. Thanks.
---
Heikki Linnakangas wrote:
Here's a patch to remove currentItemData currentMarkpos from
IndexScanDesc, and add equivalent fields in access method specific
opaque structs for those access methods that need them. That makes the
index am API cleaner.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
[ text/x-patch is unsupported, treating like TEXT/PLAIN ]
Index: src/backend/access/gist/gistget.c
===
RCS file:
/home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/gist/gistget.c,v
retrieving revision 1.60
diff -c -r1.60 gistget.c
*** src/backend/access/gist/gistget.c 14 Jul 2006 14:52:16 - 1.60
--- src/backend/access/gist/gistget.c 12 Sep 2006 15:37:48 -
***
*** 106,113
* If we have produced an index tuple in the past and the executor has
* informed us we need to mark it as killed, do so now.
*/
! if (scan-kill_prior_tuple
ItemPointerIsValid((scan-currentItemData)))
! killtuple(scan-indexRelation, so, (scan-currentItemData));
/*
* Get the next tuple that matches the search key. If asked to skip
killed
--- 106,113
* If we have produced an index tuple in the past and the executor has
* informed us we need to mark it as killed, do so now.
*/
! if (scan-kill_prior_tuple ItemPointerIsValid((so-curpos)))
! killtuple(scan-indexRelation, so, (so-curpos));
/*
* Get the next tuple that matches the search key. If asked to skip
killed
***
*** 151,157
so = (GISTScanOpaque) scan-opaque;
! if (ItemPointerIsValid(scan-currentItemData) == false)
{
/* Being asked to fetch the first entry, so start at the root */
Assert(so-curbuf == InvalidBuffer);
--- 151,157
so = (GISTScanOpaque) scan-opaque;
! if (ItemPointerIsValid(so-curpos) == false)
{
/* Being asked to fetch the first entry, so start at the root */
Assert(so-curbuf == InvalidBuffer);
***
*** 226,232
}
if (!GistPageIsLeaf(p) || resetoffset ||
! !ItemPointerIsValid(scan-currentItemData))
{
if (ScanDirectionIsBackward(dir))
n = PageGetMaxOffsetNumber(p);
--- 226,232
}
if (!GistPageIsLeaf(p) || resetoffset ||
! !ItemPointerIsValid(so-curpos))
{
if (ScanDirectionIsBackward(dir))
n = PageGetMaxOffsetNumber(p);
***
*** 235,241
}
else
{
! n =
ItemPointerGetOffsetNumber((scan-currentItemData));
if (ScanDirectionIsBackward(dir))
n = OffsetNumberPrev(n);
--- 235,241
}
else
{
! n = ItemPointerGetOffsetNumber((so-curpos));
if (ScanDirectionIsBackward(dir))
n = OffsetNumberPrev(n);
***
*** 285,291
* we can efficiently resume the index scan
later.
*/
! ItemPointerSet((scan-currentItemData),
BufferGetBlockNumber(so-curbuf), n);
if (!(ignore_killed_tuples
ItemIdDeleted(PageGetItemId(p, n
--- 285,291
* we can efficiently resume the index scan
later.
*/
! ItemPointerSet((so-curpos),
BufferGetBlockNumber(so-curbuf), n);
if (!(ignore_killed_tuples
ItemIdDeleted(PageGetItemId(p, n
Index: src/backend/access/gist/gistscan.c
===
RCS file:
/home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/gist/gistscan.c,v
retrieving revision 1.64
diff -c -r1.64 gistscan.c
*** src/backend/access/gist/gistscan.c14 Jul 2006 14:52:16 -
1.64
--- src/backend/access/gist/gistscan.c12 Sep 2006 15:38:52 -
***
*** 42,53
GISTScanOpaque so;
int i;
- /*
- * Clear all the pointers.
- */
- ItemPointerSetInvalid(scan-currentItemData);
- ItemPointerSetInvalid(scan-currentMarkData);
-
so = (GISTScanOpaque) scan-opaque;
if (so != NULL)
{
---
Re: [pgsql-patches] [HACKERS] Indicate disabled triggers in \d
Patch applied by Neil. Thanks. --- Brendan Jurd wrote: On 11/7/06, Brendan Jurd [EMAIL PROTECTED] wrote: As discussed briefly on pgsql-hackers, the current psql \d command does not make any distinction between enabled and disabled triggers. The attached patch modifies psql's describeOneTableDetails() such that triggers and disabled triggers are displayed as two separate footer lists, for example: Minor fix to the previous patch; result7 was not being cleared at the end of the block. [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] [HACKERS] wal buffers documentation -errata
I have applied the attached patches to CVS HEAD and 8.2.X to mention defaults that match the contents of postgresql.conf. I also added a mention that pg_settings.unit shows the default units for a setting. One problem is that some settings use a default unit of seconds, but the default value is one minute, or 1m. shared_buffers has a similar problem, using 8k blocks as the default unit, but having a default value of 32MB or similar. I am unsure how we can really improve this. Saying the default units are measured in seconds, but the default value is 1 minute is pretty confusing. Hopefully the pg_settings.unit mention will help, and users will always use units for fields that have them in postgresql.conf. I have added lines documenting the memory and time units to postgresql.conf. Hopefully that will help too. --- Dave Cramer wrote: On 11-Jan-07, at 12:49 PM, Tom Lane wrote: Dave Cramer [EMAIL PROTECTED] writes: the point is that the documentation suggests that the default is 8 not 8MB, but 8, when in fact the defaults are now given in memory units not pages Oh, I thought you were complaining that the value was numerically wrong. Perhaps we should convert the documentation to show the defaults in a units-ified way, but if so it needs to be done consistently. Most of the entries seem not to have been changed; for example shared_buffers is still described in blocks. Yes, everything is described in blocks, but in the configuration file everything (I've looked at so far) is specified in memory units. While I appreciate the effort that went into making it somewhat easier to use memory units I can see this being very confusing for the average user. I would suggest that the documentation needs to be consistent with the example configuration file installed by initdb Dave regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: config.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.103 retrieving revision 1.104 diff -c -c -r1.103 -r1.104 *** config.sgml 19 Jan 2007 16:58:45 - 1.103 --- config.sgml 20 Jan 2007 21:30:26 - 1.104 *** *** 29,45 /para para ! Some settings specify a memory or time value. Each of these has ! an implicit unit, which is either kilobytes, blocks (typically 8 ! kilobytes), milliseconds, seconds, or minutes. For convenience, a ! (possibly different) unit can also be specified explicitly. Valid ! memory units are literalkB/literal (kilobytes), ! literalMB/literal (megabytes), and literalGB/literal ! (gigabytes); valid time units are literalms/literal ! (milliseconds), literals/literal (seconds), ! literalmin/literal (minutes), literalh/literal (hours), ! and literald/literal (days). Note that the multiplier for ! memory units is 1024, not 1000. /para para --- 29,45 /para para ! Some settings specify a memory or time value. Each of these has an ! implicit unit, which is either kilobytes, blocks (typically eight ! kilobytes), milliseconds, seconds, or minutes. Default units can be ! queried by referencing literalpg_settings.unit/. For convenience, ! a different unit can also be specified explicitly. Valid memory units ! are literalkB/literal (kilobytes), literalMB/literal ! (megabytes), and literalGB/literal (gigabytes); valid time units ! are literalms/literal (milliseconds), literals/literal ! (seconds), literalmin/literal (minutes), literalh/literal ! (hours), and literald/literal (days). Note that the multiplier ! for memory units is 1024, not 1000. /para para *** *** 347,356 listitem para Determines the maximum number of concurrent connections to the ! database server. The default is typically 100, but may be less ! if your kernel settings will not support it (as determined ! during applicationinitdb/). This parameter can only be ! set at server start. /para para --- 347,356 listitem para Determines the maximum number of concurrent connections to the ! database server. The default is typically 100 connections, but ! may be less
Re: [pgsql-patches] [HACKERS] [PATCHES] setseed() doc
FYI, Neil has corrected this in CVS HEAD. --- Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: On Mon, 2006-09-04 at 15:19 -0400, Tom Lane wrote: AFAICT it's just junk. It happens to be the input times MAX_RANDOM_VALUE, but what use is that? I wonder if we shouldn't change the function to return VOID I agree. Given how soon we want to get an 8.2 beta out the door, perhaps this change would be best postponed to 8.3 (unless there's another outstanding 8.2 patch that requires initdb?). Nothing outstanding at the moment. Although this is surely a small change, it's also pretty low-priority, so I'd counsel leaving it for 8.3 rather than trying to cram it in now. We have more important things to be worrying about ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- 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] pthread option of msvc build.
Is this ready to be applied?
---
Magnus Hagander wrote:
Hiroshi Saito wrote:
Hi Magnus-san.
I am trying simple construction by operating config.pl.
It has changed wonderfully now. however, I do not use ecpg, and see the
simplest construction. At that time, even pthread might not be needed.
It was simple.
Good point, but the patch doesn't work. Simply removing the check
doesn't work, it will cause warnings and errors all over when doing a
complete build.
Please try the attached patch which actually disables the building of
ecpg if pthreads is not specified.
//Magnus
Index: src\tools\msvc/Project.pm
===
RCS file: c:/prog/cvsrepo/pgsql/pgsql/src/tools/msvc/Project.pm,v
retrieving revision 1.5
diff -c -r1.5 Project.pm
*** src\tools\msvc/Project.pm 4 Jan 2007 17:58:19 - 1.5
--- src\tools\msvc/Project.pm 11 Jan 2007 18:54:19 -
***
*** 367,377
}
$libs =~ s/ $//;
$libs =~ s/__CFGNAME__/$cfgname/g;
print $f EOF;
Configuration Name=$cfgname|Win32
OutputDirectory=.\\$cfgname\\$self-{name}
IntermediateDirectory=.\\$cfgname\\$self-{name}
ConfigurationType=$cfgtype UseOfMFC=0
ATLMinimizesCRunTimeLibraryUsage=FALSE CharacterSet=2
WholeProgramOptimization=$p-{wholeopt}
Tool Name=VCCLCompilerTool Optimization=$p-{opt}
!
AdditionalIncludeDirectories=src/include;src/include/port/win32;src/include/port/win32_msvc;$self-{solution}-{options}-{pthread};$self-{includes}
PreprocessorDefinitions=WIN32;_WINDOWS;__WINDOWS__;__WIN32__;EXEC_BACKEND;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self-{defines}$p-{defs}
StringPooling=$p-{strpool}
RuntimeLibrary=$p-{runtime}
DisableSpecificWarnings=$self-{disablewarnings}
--- 367,379
}
$libs =~ s/ $//;
$libs =~ s/__CFGNAME__/$cfgname/g;
+ my $pth = $self-{solution}-{options}-{pthread};
+ $pth = '' unless $pth;
print $f EOF;
Configuration Name=$cfgname|Win32
OutputDirectory=.\\$cfgname\\$self-{name}
IntermediateDirectory=.\\$cfgname\\$self-{name}
ConfigurationType=$cfgtype UseOfMFC=0
ATLMinimizesCRunTimeLibraryUsage=FALSE CharacterSet=2
WholeProgramOptimization=$p-{wholeopt}
Tool Name=VCCLCompilerTool Optimization=$p-{opt}
!
AdditionalIncludeDirectories=src/include;src/include/port/win32;src/include/port/win32_msvc;$pth;$self-{includes}
PreprocessorDefinitions=WIN32;_WINDOWS;__WINDOWS__;__WIN32__;EXEC_BACKEND;WIN32_STACK_RLIMIT=4194304;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE$self-{defines}$p-{defs}
StringPooling=$p-{strpool}
RuntimeLibrary=$p-{runtime}
DisableSpecificWarnings=$self-{disablewarnings}
Index: src\tools\msvc/Solution.pm
===
RCS file: c:/prog/cvsrepo/pgsql/pgsql/src/tools/msvc/Solution.pm,v
retrieving revision 1.5
diff -c -r1.5 Solution.pm
*** src\tools\msvc/Solution.pm29 Dec 2006 16:49:02 - 1.5
--- src\tools\msvc/Solution.pm11 Jan 2007 18:52:16 -
***
*** 6,12
sub new {
my $junk = shift;
my $options = shift;
- die Pthreads is required.\n unless $options-{pthread};
my $self = {
projects = {},
options = $options,
--- 6,11
Index: src\tools\msvc/mkvcbuild.pl
===
RCS file: c:/prog/cvsrepo/pgsql/pgsql/src/tools/msvc/mkvcbuild.pl,v
retrieving revision 1.9
diff -c -r1.9 mkvcbuild.pl
*** src\tools\msvc/mkvcbuild.pl 9 Jan 2007 06:00:43 - 1.9
--- src\tools\msvc/mkvcbuild.pl 11 Jan 2007 18:52:32 -
***
*** 90,117
$pgtypes-AddReference($postgres,$libpgport);
$pgtypes-AddIncludeDir('src\interfaces\ecpg\include');
! my $libecpg =
$solution-AddProject('libecpg','dll','interfaces','src\interfaces\ecpg\ecpglib');
! $libecpg-AddDefine('FRONTEND');
! $libecpg-AddIncludeDir('src\interfaces\ecpg\include');
! $libecpg-AddIncludeDir('src\interfaces\libpq');
! $libecpg-AddIncludeDir('src\port');
! $libecpg-AddLibrary('wsock32.lib');
! $libecpg-AddLibrary($config-{'pthread'} . '\pthreadVC2.lib');
! $libecpg-AddReference($libpq,$pgtypes);
!
! my $libecpgcompat =
$solution-AddProject('libecpg_compat','dll','interfaces','src\interfaces\ecpg\compatlib');
! $libecpgcompat-AddIncludeDir('src\interfaces\ecpg\include');
! $libecpgcompat-AddIncludeDir('src\interfaces\libpq');
! $libecpgcompat-AddReference($pgtypes,$libecpg);
!
! my $ecpg =
$solution-AddProject('ecpg','exe','interfaces','src\interfaces\ecpg\preproc');
! $ecpg-AddIncludeDir('src\interfaces\ecpg\include');
!
Re: [pgsql-patches] guid/uuid datatype
I already suggested a few things you could improve in the patch. If this discussion concludes that the patch should be included in the core backend and you submit a revised patch, I'd be happy to review and apply it. So.. do we agree for uuid to be included in the core? If so.. I will change the assigned OIDs in the patch to match the current source-tree and update the code with the suggestions provided by Neil. Are we okay on this? Regards, Gevik. ---(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
