Re: [HACKERS] message string fixes
For example, in regis.c there are several strings talking about regis pattern. I had never heard of regis patterns. Turns out they are a fast regex subset, used AFAICT only by the ispell code. Searching the web I don't find any other reference to regises (regisen? reges?), so I think we should avoid using the term. How about just changing the messages to just say regular expression instead? It's just a combination of regular expression for ispell. It implements subset of regex. It much faster that any other implementation, and uses subset widely used in ispell. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Transaction Snapshot Cloning
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote: To do something like that the user would have to create a prepared transaction to save the snapshot. I think that makes sense though since effectively it's just requiring that the user explicitly do what would otherwise be a hidden implicit requirement -- that the user do something to hold globalxmin back to avoid having the snapshots expire. This is a good idea which I will want to develop in the future, not yet though. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Transaction Snapshot Cloning
On Thu, 2008-01-17 at 11:56 +0100, Florian G. Pflug wrote: Tom Lane wrote: I'm not sure what the most convenient user API would be for an on-demand hard-read-only mode, but we can't use SET TRANSACTION READ ONLY for it. It'd have to be some other syntax. Maybe just use a GUC variable instead of bespoke syntax? SET TRANSACTION is really just syntactic sugar for GUC SET operations anyway ... We could reuse the transaction_read_only GUC, adding strict as a 3rd allowed value beside on and off. And maybe make ansi an alias for on to emphasize that one behavior is what the standard wants, and the other is a postgres extension. Sounds OK to me. We need this to be enforced for Hot Standby, though it seems useful of itself. If we can break down the Hot Standby stuff into smaller chunks, it will make it easier for everybody to agree. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Transaction Snapshot Cloning
Simon Riggs wrote: On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote: To do something like that the user would have to create a prepared transaction to save the snapshot. I think that makes sense though since effectively it's just requiring that the user explicitly do what would otherwise be a hidden implicit requirement -- that the user do something to hold globalxmin back to avoid having the snapshots expire. This is a good idea which I will want to develop in the future, not yet though. I haven't been following this thread in detail, but I'd just like to point out that there's a couple features in the XA spec that we don't currently support: - ability to stop a transaction, and resume it later, executing other transactions in between. - ability to stop a transaction, and resume it later in another connection. Neither of these are essential for two-phase commit, which is what the spec is for, but if they happened to fall out of some other work, it would be nice... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(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: [HACKERS] Declarative partitioning grammar
On Tue, 2008-01-15 at 17:12 +, Gregory Stark wrote: Wouldn't Segment Exclusion (maybe together with a specialized form of CLUSTERing) handle that case much better than partitioning? Without the need to name all those thousands of partitions and manage them manually. Firstly we have a philosophical difference here. I think crossing my fingers and hoping for a performance boost from some low level infrastructure that I can't measure or monitor is not better than managing things so I know precisely what's going on and can see it for myself in the plan. The arguments put forward here apply equally to visibility maps of any kind, so should equally be applied to both Heikki's VM proposal and Itagaki's DSM approach. Both of those proposals rely on the idea that the writes to tables are either low or isolated to particular areas. If we do anything that relies upon dynamic state information then the results are, well...dynamic, i.e. they give a variable performance boost. I'm not sure why you think it could not be measured or monitored. Crossing fingers and hoping isn't really a fair comment, unless your workload varied dramatically from massively random one day to isolated the next day. Most workloads don't, including your example case. Sure, they won't help in all cases, but as I've said elsewhere we can construct dysfunctional test cases that will defeat other tuning measures such as HOT, TOAST and many other things. If we want to apply further tuning to Postgres then we should accept that not all tuning will apply to all cases. I've accepted that we should have declarative partitioning to cover many of the cases people have cited, but that doesn't mean a dynamic partitioning approach is worthless because they aren't mutually exclusive techniques. I think we need to see a design for how the internals of partitioning might work, if it differs from the existing table-level model. Only then can we see the downsides of both approaches. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Transaction Snapshot Cloning
On Sun, 2008-01-20 at 12:37 +, Heikki Linnakangas wrote: Simon Riggs wrote: On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote: To do something like that the user would have to create a prepared transaction to save the snapshot. I think that makes sense though since effectively it's just requiring that the user explicitly do what would otherwise be a hidden implicit requirement -- that the user do something to hold globalxmin back to avoid having the snapshots expire. This is a good idea which I will want to develop in the future, not yet though. I haven't been following this thread in detail, but I'd just like to point out that there's a couple features in the XA spec that we don't currently support: - ability to stop a transaction, and resume it later, executing other transactions in between. - ability to stop a transaction, and resume it later in another connection. Neither of these are essential for two-phase commit, which is what the spec is for, but if they happened to fall out of some other work, it would be nice... Thanks for the info. Sounds like this idea would provide some of the groundwork for the latter concept. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Transaction Snapshot Cloning
Simon Riggs [EMAIL PROTECTED] writes: On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote: To do something like that the user would have to create a prepared transaction to save the snapshot. I think that makes sense though since effectively it's just requiring that the user explicitly do what would otherwise be a hidden implicit requirement -- that the user do something to hold globalxmin back to avoid having the snapshots expire. This is a good idea which I will want to develop in the future, not yet though. I didn't mean this as an additional feature. I'm talking about how users would use the two very different proposed interfaces. In your version the user can save the actual snapshot somewhere and then use it later. He'll presumably get an error if the snapshot is no longer usable and there's no way for him to protect it and guarantee it's still usable. In Tom's version the user can only copy the snapshot from some other running session. It's necessarily still valid because the session is using it. But if the user wants to save it for later he'll have to create a session (or prepared transaction) to hold the snapshot. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 In MySQL I have a function SHA1, which is critical for storing and authenticating passwords. It sure would be nice to have this in core. Yeah, there's pgcrypto, but it's a bit overkill for people who simply want to do a SHA1, especially when they see we already have a md5(). I also realize that SHA1 is not a great solution these days either, but I'd at least like to see a discussion on moving Postgres to somewhere between only has md5() and all pg_crypto functions inside core, even if it only means a handful of SHA functions. Moving this over to -hackers. In summary: what would objections be to my writing a sha1() patch? - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200801201218 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFHk4NIvJuQZxSWSsgRA83ZAJ0SIk36sYvLF30q7hog2sBaQU1+LACeOv15 WkDwrzgzHyrwmNFP85plbBA= =6P4y -END PGP SIGNATURE- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] select statement details
I'm trying to determine if a select statement:
1 - causes execution of a Volatile function
- or -
2 - causes execution of a nextval function (same/similar as #1 above?)
from within tcop / postgres.c ??
Things like QueryIsReadOnly imply that select nextval('some_sequence') are
read-only ... which is not read-only in the sense that the database is in a
different state after the nextval runs.
I've been looking through PortalDesc NodeTag, but haven't been able to find
anything...
suggestions?
If nothing exists, I'd need to create something.
Any suggestions where to start?
---(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: [HACKERS] [GENERAL] SHA1 on postgres 8.3
Greg Sabino Mullane wrote: I also realize that SHA1 is not a great solution these days either, but I'd at least like to see a discussion on moving Postgres to somewhere between only has md5() and all pg_crypto functions inside core, even if it only means a handful of SHA functions. Moving this over to -hackers. In summary: what would objections be to my writing a sha1() patch? Isn't sha1 considered broken for some uses anyway? Perhaps if you're going to do that it would make sense to move the whole pgcrypto/sha2.c stuff to core, I think. -- 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: [HACKERS] [GENERAL] SHA1 on postgres 8.3
On Sun, Jan 20, 2008 at 05:24:11PM -, Greg Sabino Mullane wrote: It sure would be nice to have this in core. Yeah, there's pgcrypto, but it's a bit overkill for people who simply want to do a SHA1, especially when they see we already have a md5(). md5() was added with the following commit message: Attached are two small patches to expose md5 as a user function -- including documentation and regression test mods. It seemed small and unobtrusive enough to not require a specific proposal on the hackers list -- but if not, let me know and I'll make a pitch. Otherwise, if there are no objections please apply. http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/varlena.c#rev1.94 In summary: what would objections be to my writing a sha1() patch? There wasn't any discussion about it last time. It does seem a bit wierd to support one but not the other. It's also interesting to note that the implementation in the backed is commented with: I do not expect this file to be used for general purpose MD5'ing of large amounts of data, only for generating hashed passwords from limited input. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F Kennedy signature.asc Description: Digital signature
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
Alvaro Herrera wrote: Greg Sabino Mullane wrote: I also realize that SHA1 is not a great solution these days either, but I'd at least like to see a discussion on moving Postgres to somewhere between only has md5() and all pg_crypto functions inside core, even if it only means a handful of SHA functions. Moving this over to -hackers. In summary: what would objections be to my writing a sha1() patch? Isn't sha1 considered broken for some uses anyway? Perhaps if you're going to do that it would make sense to move the whole pgcrypto/sha2.c stuff to core, I think. IIRC not anymore than md5, which we already do... That said, it would make sense to include sha1() for compatibility reasons and a stronger sha for people that need something better. //Magnus ---(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: [HACKERS] message string fixes
Teodor Sigaev [EMAIL PROTECTED] writes: web I don't find any other reference to regises (regisen? reges?), so I think we should avoid using the term. How about just changing the messages to just say regular expression instead? It's just a combination of regular expression for ispell. Maybe the right phrase to use is ispell regular expression. In any case we need to document what the limitations are compared to regular regular expressions (ahem). Do you know offhand what the rules are? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
Martijn van Oosterhout wrote: In summary: what would objections be to my writing a sha1() patch? There wasn't any discussion about it last time. It does seem a bit wierd to support one but not the other. It's also interesting to note that the implementation in the backed is commented with: I proposed md5 without sha1 because we already had md5 code in the backend, and we did not have sha1 (and still don't). At the time I was afraid that if I proposed sha1 as well it would become a debate and we would have ended up with neither. Personally I'm in favor of having sha1 and one or more of the newer replacements in the backend. I'd also like to see HMAC built in. But I think we need to be careful about running afoul of various export regulations. Keeping the crypto stuff separate allows distributions to leave the crypto out if they need to. Perhaps cryptographic hashes/HMAC are not an issue though. Anyone know? Joe ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
Greg Sabino Mullane [EMAIL PROTECTED] writes: In summary: what would objections be to my writing a sha1() patch? Mainly that no one else is dissatisfied with the current split between core and pgcrypto. The only reason md5() is in core is to support encryption of passwords in pg_shadow. There are good reasons not to have any more crypto capability in core than we absolutely have to; mainly to do with benighted laws in some countries. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] bgwriter_lru_multiplier blurbs inconsistent
Is the bgwriter_lru_multiplier parameter a limit on the number to scan or to write? GUC and docs seem to contradict one another. GUC says #: utils/misc/guc.c:1834 #, fuzzy msgid Background writer multiplier on average buffers to scan per round. The docs say Unless limited by varnamebgwriter_lru_maxpages/, the number of dirty buffers written in each round is determined by reference to the number of new buffers that have been needed by server processes during recent rounds. This number is multiplied by varnamebgwriter_lru_multiplier/ to arrive at the estimate of the number of buffers that will be needed during the next round. Which one is correct? Do we need a correction of either? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(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] Transaction Snapshot Cloning
On Sun, 2008-01-20 at 15:11 +, Gregory Stark wrote: Simon Riggs [EMAIL PROTECTED] writes: On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote: To do something like that the user would have to create a prepared transaction to save the snapshot. I think that makes sense though since effectively it's just requiring that the user explicitly do what would otherwise be a hidden implicit requirement -- that the user do something to hold globalxmin back to avoid having the snapshots expire. This is a good idea which I will want to develop in the future, not yet though. I didn't mean this as an additional feature. I'm talking about how users would use the two very different proposed interfaces. In your version the user can save the actual snapshot somewhere and then use it later. He'll presumably get an error if the snapshot is no longer usable and there's no way for him to protect it and guarantee it's still usable. In Tom's version the user can only copy the snapshot from some other running session. It's necessarily still valid because the session is using it. But if the user wants to save it for later he'll have to create a session (or prepared transaction) to hold the snapshot. OK, misunderstanding. My version is being done now, so we can use it now; it will be published as BSD licenced open source software, but as yet seems unlikely to ever be part of a main distribution of Postgres. It will probably be published on pgfoundry, though possibly elsewhere also. I don't take credit for the general idea, but I am responsible for the idea to do this now as an external function. I prefer this done in the backend in the long term, much safer, which we are agreed upon. I'll come back to that so we get it into 8.4. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [DOCS] bgwriter_lru_multiplier blurbs inconsistent
Alvaro Herrera [EMAIL PROTECTED] writes: Is the bgwriter_lru_multiplier parameter a limit on the number to scan or to write? GUC and docs seem to contradict one another. GUC says #: utils/misc/guc.c:1834 #, fuzzy msgid Background writer multiplier on average buffers to scan per round. The docs say Unless limited by varnamebgwriter_lru_maxpages/, the number of dirty buffers written in each round is determined by reference to the number of new buffers that have been needed by server processes during recent rounds. This number is multiplied by varnamebgwriter_lru_multiplier/ to arrive at the estimate of the number of buffers that will be needed during the next round. Which one is correct? Do we need a correction of either? We multiply the average number of new buffers used per round by the multiplier, and use that as the target for the number of clean buffers to have in front of the sweep hand. Any of these that are dirty will be written (until we exceed maxpages written). So it's the number to scan. I don't find either the docs or the msgid to be wrong, exactly; but if you have a proposal for better wording, I'm all ears. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
On Sun, Jan 20, 2008 at 01:42:21PM -0500, Tom Lane wrote: Greg Sabino Mullane [EMAIL PROTECTED] writes: In summary: what would objections be to my writing a sha1() patch? Mainly that no one else is dissatisfied with the current split between core and pgcrypto. The only reason md5() is in core is to support encryption of passwords in pg_shadow. There are good reasons not to have any more crypto capability in core than we absolutely have to; mainly to do with benighted laws in some countries. Is there any country with laws so benighted that they restrict secure hashing algorithms? Right now, there's a contest between SHA1 and MD5 as to which one gets broken first, and SHA1 appears to be in the lead. SHAn for n1 could preempt the awfulness of losing this race. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate ---(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
[HACKERS] Minor bug in src/port/rint.c
Hi everyone,
I believe that there is a small bug in src/port/rint.c when the input
parameter has a fractional part of 0.5 which is demonstrated by the
attached program. It appears that the PG version of rint() rounds in the
wrong direction with respect to glibc.
[EMAIL PROTECTED]:~$ ./test
rint(-1.5): -2.00
pg_rint(-1.5): -1.00
rint(1.5): 2.00
pg_rint(1.5): 1.00
The fix is, of course, to add an equals into the if() comparisons on
lines 21 and 26, so that when the fractional part is 0.5, it rounds in
the opposite direction instead.
I'm sure that this will have practically zero effect on the code,
however it may be worth applying for correctness and consistency with
other platform implementations.
ATB,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
/*
* rint() test program
*
* Compile on gcc using:
* gcc -o test test.c -lm
*/
#include math.h
#include stdio.h
double
pg_rint(double x)
{
double f,
n = 0.;
f = modf(x, n);
if (x 0.)
{
if (f .5)
n += 1.;
}
else if (x 0.)
{
if (f -.5)
n -= 1.;
}
return n;
}
int main()
{
printf(rint(-1.5): %f\n, rint(-1.5));
printf(pg_rint(-1.5): %f\n, pg_rint(-1.5));
printf(rint(1.5): %f\n, rint(1.5));
printf(pg_rint(1.5): %f\n, pg_rint(1.5));
}
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] bgwriter_lru_multiplier blurbs inconsistent
On Sun, 20 Jan 2008, Alvaro Herrera wrote: Is the bgwriter_lru_multiplier parameter a limit on the number to scan or to write? GUC and docs seem to contradict one another. It adjusts the target for how many clean buffers it wants to either find or create. This always increases the number of buffers scanned, and that's what the GUC description says. Since a clean buffer can either be a) a reusable candidate found by scanning or b) a buffer that is written, on average it's adjusting up the number of writes as well. But it's not guaranteed to--you could have a case where it just found all the buffers it needed and never wrote a single one. Unless limited by varnamebgwriter_lru_maxpages/, the number of dirty buffers written in each round is determined by reference to the number of new buffers that have been needed by server processes during recent rounds. This number is multiplied by varnamebgwriter_lru_multiplier/ to arrive at the estimate of the number of buffers that will be needed during the next round. There is nothing incorrect here, it's just not as clear as it could be. Here's a V2 that tries to clear that up: Unless limited by varnamebgwriter_lru_maxpages/, the number of dirty buffers written in each round is based on the number of new buffers that have been needed by server processes during recent rounds. The recent need is multiplied by varnamebgwriter_lru_multiplier/ to arrive at the estimate of the number of buffers that will be needed during the next round. Buffers are written to meet that need if there aren't enough reusable ones found while scanning. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(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: [HACKERS] Minor bug in src/port/rint.c
Mark Cave-Ayland [EMAIL PROTECTED] writes: I believe that there is a small bug in src/port/rint.c when the input parameter has a fractional part of 0.5 which is demonstrated by the attached program. It appears that the PG version of rint() rounds in the wrong direction with respect to glibc. The fix is, of course, to add an equals into the if() comparisons on lines 21 and 26, so that when the fractional part is 0.5, it rounds in the opposite direction instead. Your proposed fix wouldn't make it act the same as glibc, only move the differences around. I believe glibc's default behavior for the ambiguous cases is round to nearest even number. You propose replacing round towards zero, which is what our code currently does, with round away from zero, which really isn't likely to match any platform's behavior. (The behaviors specified by IEEE are to nearest even, towards zero, towards minus infinity, and towards plus infinity, with the first being the typical default.) Considering that probably every modern platform has rint(), I doubt it's worth spending time on our stopgap version to try to make it fully IEEE-compliant ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] message string fixes
Maybe the right phrase to use is ispell regular expression. In any case we need to document what the limitations are compared to regular regular expressions (ahem). Do you know offhand what the rules are? There is a fallback to regex if expression isn't supported by regis (see call of RS_isRegis() in spell.c). Regis supports only matches as is, range of characters ( [abc] ), negotiation of characters range ( [^abc] ) and can match begin or end of string. AFAIK, ispell allows full regex but in practice I never seen something unsupported by regis. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] message string fixes
Teodor Sigaev [EMAIL PROTECTED] writes: There is a fallback to regex if expression isn't supported by regis (see call of RS_isRegis() in spell.c). Oh. So in that case, the messages Alvaro is worried about ereport(ERROR, (errcode(ERRCODE_INVALID_REGULAR_EXPRESSION), errmsg(invalid regis pattern: \%s\, str))); aren't user-facing errors at all, and should be demoted to elog's, correct? elog(ERROR, invalid regis pattern: \%s\, str); regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Minor bug in src/port/rint.c
Tom Lane wrote: Mark Cave-Ayland [EMAIL PROTECTED] writes: I believe that there is a small bug in src/port/rint.c when the input parameter has a fractional part of 0.5 which is demonstrated by the attached program. It appears that the PG version of rint() rounds in the wrong direction with respect to glibc. The fix is, of course, to add an equals into the if() comparisons on lines 21 and 26, so that when the fractional part is 0.5, it rounds in the opposite direction instead. Your proposed fix wouldn't make it act the same as glibc, only move the differences around. I believe glibc's default behavior for the ambiguous cases is round to nearest even number. You propose replacing round towards zero, which is what our code currently does, with round away from zero, which really isn't likely to match any platform's behavior. (The behaviors specified by IEEE are to nearest even, towards zero, towards minus infinity, and towards plus infinity, with the first being the typical default.) Considering that probably every modern platform has rint(), I doubt it's worth spending time on our stopgap version to try to make it fully IEEE-compliant ... Except win32. (let's not get into the argument about modern platforms, please, but it certainly is one of our most popular ones) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Minor bug in src/port/rint.c
Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Considering that probably every modern platform has rint(), I doubt it's worth spending time on our stopgap version to try to make it fully IEEE-compliant ... Except win32. Hasn't it got something equivalent? This is IEEE-required behavior I think. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] bgwriter_lru_multiplier blurbs inconsistent
Greg Smith [EMAIL PROTECTED] writes: There is nothing incorrect here, it's just not as clear as it could be. Here's a V2 that tries to clear that up: Unless limited by varnamebgwriter_lru_maxpages/, the number of dirty buffers written in each round is based on the number of new buffers that have been needed by server processes during recent rounds. The recent need is multiplied by varnamebgwriter_lru_multiplier/ to arrive at the estimate of the number of buffers that will be needed during the next round. Buffers are written to meet that need if there aren't enough reusable ones found while scanning. I think the main problem is the qualifying clause up front in a place of prominence. Here's a V3 try: The number of dirty buffers written in each round is based on the number of new buffers that have been needed by server processes during recent rounds. The average recent need is multiplied by varnamebgwriter_lru_multiplier/ to arrive at the estimate of the number of buffers that will be needed during the next round. Dirty buffers are written until there are that many clean, reusable buffers available. However, no more than varnamebgwriter_lru_maxpages/ buffers will be written per round. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Minor bug in src/port/rint.c
Mark Cave-Ayland [EMAIL PROTECTED] writes: The big question is, of course, how much difference does this make? Probably not a lot. If we can find an IEEE-compliant rounding function on Windows, I'd be happy to see rint() fixed to call it; beyond that I think it's not worth troubling with. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] message string fixes
Teodor Sigaev wrote: aren't user-facing errors at all, and should be demoted to elog's, correct? elog(ERROR, invalid regis pattern: \%s\, str); Hmm. If regis detects an error in expression then it will be an error for regex library too. At least, it was supposed to be. And those that are not, probably are not what the user intends anyway, with the pattern language being so narrow. If all invalid regis patterns are indeed invalid regex patterns, then just changing regis for regex should be enough. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] message string fixes
Alvaro Herrera [EMAIL PROTECTED] writes: Teodor Sigaev wrote: Hmm. If regis detects an error in expression then it will be an error for regex library too. At least, it was supposed to be. And those that are not, probably are not what the user intends anyway, with the pattern language being so narrow. It looks to me like RS_isRegis() needs to be tightened up a bit anyway: it will accept ^foo which is valid regex but not valid regis, leading to an error being thrown which is not what we want. If we tighten it to exactly match what RS_compile() will take ... say by using the same state-machine logic ... then indeed the ereports are internal and can be demoted to elog's. If we make them elogs then ISTM they ought to keep saying regis, just so we know where to look if they ever do fail ;-) regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Minor bug in src/port/rint.c
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Tom Lane wrote: Considering that probably every modern platform has rint(), I doubt it's worth spending time on our stopgap version to try to make it fully IEEE-compliant ... Except win32. Hasn't it got something equivalent? This is IEEE-required behavior I think. Quite possibly - I haven't looked for it. I just added port/rint.c when it was missing that one. Something for the list of things to investigate, I guess... //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] proposal: generic function, constructor function
Hello
The different-numbers-of-arguments bit is what I'm objecting to.
Just register the function as foo(ANY), foo(ANY,ANY), foo(ANY,ANY,ANY),
etc, and you're done without breaking anything else.
I found simple solution, it uses ANY, but number of necessary ANY
arguments is generated dynamically:
FuncCandidateList
FuncnameGetCandidates(List *names, int nargs)
{
FuncCandidateList resultList = NULL;
char *schemaname;
/* anyparams has unlimeted pronargs, we cannot check it */
if (pronargs == 1 procform-proargtypes.values[0]
== ANYPARAMSOID)
generic_function = true;
/* Ignore if it doesn't match requested argument count */
else if (nargs = 0 pronargs != nargs)
continue;
/*
* Okay to add it to result list
*/
if (!generic_function)
{
newResult = (FuncCandidateList)
palloc(sizeof(struct
_FuncCandidateList) - sizeof(Oid)
+ pronargs * sizeof(Oid));
newResult-pathpos = pathpos;
newResult-oid = HeapTupleGetOid(proctup);
newResult-nargs = pronargs;
memcpy(newResult-args, procform-proargtypes.values,
pronargs * sizeof(Oid));
newResult-next = resultList;
resultList = newResult;
}
else
{
/* generic function hasn't own params, but we
know numbers and
* we can use ANY type.
*/
int i;
newResult = (FuncCandidateList)
palloc(sizeof(struct
_FuncCandidateList) - sizeof(Oid)
+ nargs * sizeof(Oid));
newResult-pathpos = pathpos;
newResult-oid = HeapTupleGetOid(proctup);
newResult-nargs = nargs;
for (i = 0; i nargs; i++)
newResult-args[i] = ANYOID;
newResult-next = resultList;
resultList = newResult;
}
It is more simpler than I though and it works. With this technique I
don't need some mentioned restriction.
ANYPARAMS is only syntactic sugar for n x ANY
What do you thing about it, please?
Regards
Pavel Stehule
we can use partial unique index, if it is possible - I didn't test it.
It's not --- partial indexes on system catalogs are not supported, and
pg_proc is certainly one catalog that that restriction will never be
relaxed for. (How you going to execute a predicate without doing
function lookups?) I don't believe that the constraint could be
expressed as a partial index predicate anyway --- how will you say
that foo(...) and foo(int) conflict, but foo(int) and foo(int,int)
don't?
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] message string fixes
aren't user-facing errors at all, and should be demoted to elog's, correct? elog(ERROR, invalid regis pattern: \%s\, str); Hmm. If regis detects an error in expression then it will be an error for regex library too. At least, it was supposed to be. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Minor bug in src/port/rint.c
On Sun, 2008-01-20 at 16:47 -0500, Tom Lane wrote: Your proposed fix wouldn't make it act the same as glibc, only move the differences around. I believe glibc's default behavior for the ambiguous cases is round to nearest even number. You propose replacing round towards zero, which is what our code currently does, with round away from zero, which really isn't likely to match any platform's behavior. (The behaviors specified by IEEE are to nearest even, towards zero, towards minus infinity, and towards plus infinity, with the first being the typical default.) Considering that probably every modern platform has rint(), I doubt it's worth spending time on our stopgap version to try to make it fully IEEE-compliant ... Hi Tom, Right, I think I understand more about this now. My confusion stemmed from reading the GNU documentation here: http://www.gnu.org/software/libc/manual/html_node/Rounding-Functions.html where in rint() section it says The default rounding mode is to round to the nearest integer. However, Wikipedia proved to be quite a fruitful resource, and agrees with what you stated which was round to even number. Interestingly, the article on rounding also points to this page http://support.microsoft.com/kb/196652 which has some example code to perform round to even number, or Banker's Rounding. The reason I was looking into this is because PostGIS will require this for an MSVC Win32 build. I haven't yet tried the implementations given in the above page, so I'm not sure whether they are any good or not... The big question is, of course, how much difference does this make? Does the current implementation exhibit different behaviour for certain date calculations between Win32 and glibc platforms, and if so does it matter? I guess at the end of the day, if it doesn't have any real effect then there is no need to worry about it. ATB, Mark. -- ILande - Open Source Consultancy http://www.ilande.co.uk ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] setof record out syntax and returning records
This thread made me try this example. Note that there's a WARNING in the spot where I pressed tab. alvherre=# create or replace function foo (out pg_class) language plpgsql as $$ declare i pg_class%rowtype; begin for i in select * from pg_class loop return next; end loop; end; $$; ERROR: cannot use RETURN NEXT in a non-SETOF function en o cerca de «next» LINEA 1: ...begin for i in select * from pg_class loop return next; end ... ^ alvherre=# set lc_messWARNING: problem in alloc set PL/PgSQL function context: detected write past chunk end in block 0xb541d0, chunk 0xb562c0 ages to 'C'; WARNING: problem in alloc set PL/PgSQL function context: detected write past chunk en d in block 0xb541d0, chunk 0xb562c0 SET The reason I tried to change lc_messages is that the spanish message struck me as a bit odd and wanted to see what the english message looked like. The full sequence required to create the message in a clean backend, regardless of whether the foo(pg_class) function exists previously, is: create function foo (out pg_class) language plpgsql as $$ declare i pg_class%type; begin for i in select * from pg_class loop return next; end loop; end; $$; create or replace function foo (out pg_class) language plpgsql as $$ declare i pg_class%type; begin for i in select * from pg_class loop return next; end loop; end; $$; create or replace function foo (out pg_class) language plpgsql as $$ declare i pg_class%rowtype; begin for i in select * from pg_class loop return next; end loop ; end; $$; set lc_mess tab -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [GENERAL] setof record out syntax and returning records
Alvaro Herrera [EMAIL PROTECTED] writes: alvherre=# set lc_messWARNING: problem in alloc set PL/PgSQL function context: detected write past chunk end in block 0xb541d0, chunk 0xb562c0 ages to 'C'; WARNING: problem in alloc set PL/PgSQL function context: detected write past chunk en d in block 0xb541d0, chunk 0xb562c0 SET Ugh. I could not reproduce this here though; there's some missing bit of context. Are you testing CVS HEAD? I assume you've got --enable-nls on, but what were the initial settings of lc_messages, the server locale, and the database encoding? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Bug in psql/enum
Folks, 8.3's psql is ponderously unhelpful when getting the type description of an enum, so I'd like to propose a new column in the \dT output which can contain those values in an array format. Yes, I know it looks like a new feature, but it's really a bug fix. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] bgwriter_lru_multiplier blurbs inconsistent
On Sun, 20 Jan 2008, Tom Lane wrote: I think the main problem is the qualifying clause up front in a place of prominence. Here's a V3 try That one looks good to me. These are small details but better to get it right now. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] message string fixes
I wrote: It looks to me like RS_isRegis() needs to be tightened up a bit anyway: it will accept ^foo which is valid regex but not valid regis, leading to an error being thrown which is not what we want. I experimented with this and verified that the error could be reached with a hacked-up affix file. If we tighten it to exactly match what RS_compile() will take ... say by using the same state-machine logic ... then indeed the ereports are internal and can be demoted to elog's. If we make them elogs then ISTM they ought to keep saying regis, just so we know where to look if they ever do fail ;-) Patch committed along these lines. regards, tom lane ---(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] message string fixes
Alvaro Herrera [EMAIL PROTECTED] writes: Additionally, I would like to apply the attached patch. Are there objections? So far I think you only applied one half of that? regards, tom lane ---(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] bgwriter_lru_multiplier blurbs inconsistent
Greg Smith [EMAIL PROTECTED] writes: On Sun, 20 Jan 2008, Tom Lane wrote: I think the main problem is the qualifying clause up front in a place of prominence. Here's a V3 try That one looks good to me. These are small details but better to get it right now. OK, committed. Back to Alvaro's original concern: is the short description in guc.c all right, or can we improve that? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bug in psql/enum
David Fetter [EMAIL PROTECTED] writes: 8.3's psql is ponderously unhelpful when getting the type description of an enum, so I'd like to propose a new column in the \dT output which can contain those values in an array format. ... and how wide is your screen, again? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Anyone tried PG with Perl 5.10?
I read that Perl 5.10 is about to hit Fedora rawhide. Anyone know if it will work with plperl and/or DBD::Pg? If there are fixes needed in plperl, it'd sure be nice if they were in 8.3 ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] SHM_HUGETLB on Linux 2.6.
Kurt Roeckx wrote: Hi, Has anyone tried to use the huge tlb support of the Linux 2.6 kernel? If you compile the kernel with support for it (CONFIG_HUGETLBFS), you can call shmget() with a SHM_HUGETLB parameter so that it will use larger pages. Has anyone tried to use it? Is it worth trying to set it up? I tried to apply HugeTlb on shared memory segment, but it does not provide us statistically-meaningful difference on PostgreSQL. pgbench gave us the following result, with shared_buffer_size=160mb and Core2Duo E6400, total system memory=512MB. Unfortunatelly, any other detailed parameters were lost. Transaction per sec AverageSTD --- pgsql-8.2.5 (normal) : 656.611817.5006 pgsql-8.2.5 (hugetlb) : 655.338920.2623 A similar topic was also posted at Mar 2007. http://archives.postgresql.org/pgsql-hackers/2007-03/msg00232.php Regard, -- OSS Platform Development Division, NEC KaiGai Kohei [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] mklink of pg_standby
Hi Simon, and Dave,Magnus. About pg_standby, a link option cause a problem in windows(XP and 2k,2k3). It is because the call of mklink is needed. Then, they are the new programs of VISTA and 2008. It is CreateSymbolicLink of API of kernel32.lib is equipped with mklink. http://msdn2.microsoft.com/en-us/library/aa363866.aspx Therefore, I considered whether it should correspond by the 'Junction' or the 'Hard Link' this way and that. However, The addition thought that it was not desirable by the reason of the process of evolution functional pg_standby. A copy function is no problem. However, I think that it is necessary to write it to a document in order to avoid a user's confusion. probably, has that no source code corrects. to Dave,and Magnus. You can do more honest suggestion.:-) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] SHA1 on postgres 8.3
* David Fetter: Is there any country with laws so benighted that they restrict secure hashing algorithms? Right now, there's a contest between SHA1 and MD5 as to which one gets broken first, and SHA1 appears to be in the lead. SHAn for n1 could preempt the awfulness of losing this race. MD5 is broken in the sense that you can create two or more meaningful documents with the same hash. This is not currently possible for SHA-1 (at least no one has publicly demonstrated this capability). SHA-256 etc. are sufficiently similar to MD5 and SHA-1, so it's not clear if they add significant additional security. (Sorry if this is what you've said.) -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] mklink of pg_standby
On Mon, 2008-01-21 at 15:36 +0900, Hiroshi Saito wrote: Hi Simon, and Dave,Magnus. About pg_standby, a link option cause a problem in windows(XP and 2k,2k3). It is because the call of mklink is needed. Then, they are the new programs of VISTA and 2008. It is CreateSymbolicLink of API of kernel32.lib is equipped with mklink. http://msdn2.microsoft.com/en-us/library/aa363866.aspx Therefore, I considered whether it should correspond by the 'Junction' or the 'Hard Link' this way and that. However, The addition thought that it was not desirable by the reason of the process of evolution functional pg_standby. A copy function is no problem. However, I think that it is necessary to write it to a document in order to avoid a user's confusion. probably, has that no source code corrects. Hi Hiroshi, pg_standby uses mklink which defaults to creating symbolic links on Win2003 and Win2008: http://technet2.microsoft.com/windowsserver2008/en/library/0ce4df22-2dbc-48fc-9c16-b721ae85f8571033.mspx?mfr=true I think you're referring to the point that mklink is not available for XP and 2k. The API call you give is limited to Windows Vista and later, so doesn't really help us get any closer. If anybody has a suggestion, I'd be happy to implement, though I don't have a test rig for Windows. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
