Re: [HACKERS] Bug in UTF8-Validation Code?
On Tue, Apr 03, 2007 at 01:06:38PM -0400, Tom Lane wrote: > I think it's probably defensible for non-Unicode encodings. To do > otherwise would require (a) figuring out what the equivalent concept to > "code point" is for each encoding, and (b) having a separate code path > for each encoding to perform the mapping. It's not clear that there > even is an answer to (a), and (b) seems like more work than chr() is > worth. But we know what the right way is for Unicode, so we should > special case that one. I dunno. I find it odd that if I want a pl/pgsql function to return a Euro symbol, it has to know what encoding the DB is in. Though I suppose that would call for a unicode_chr() function. Is there any multibyte mapping other than unicode that distinguishes between the character set and the encoding thereof? Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] [GENERAL] Using MS Access front-end with PG]
Klint Gore <[EMAIL PROTECTED]> writes: > Is there any way to create operators to point like to ilike? There > doesn't seem to be a like or ilike in pg_operator (not in 7.4 anyway). Actually it's the other way 'round: if you look into gram.y you'll see that LIKE is expanded as the operator ~~ and ILIKE as the operator ~~* ... so one of the alternatives I was thinking of offering to Paul was to rename those two operators to swap 'em. However I'm afraid that that would break the planner, which has some hardwired assumptions about the behavior of those two operator OIDs. Maybe we should change the planner to look a level deeper and see what functions the operators refer to. 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: [HACKERS] Oracle indemnifies PostgreSQL on its patents
Josh, On 3/31/07 11:01 AM, "Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > The PostgreSQL project should not give any credence to these > announcements and should avoid all patent issues possible. I think that's appropriate - the structure of the OIN looks like it's: 1) focused on Linux 2) designed to foster a patent pool of contributed patents The license agreement isn't available online, so there's little to review. What's more - the press release is vague enough that we're not sure if they signed the same agreement everyone signed or if they made changes to the agreement. In any case, I'm not sure what this really means. Perhaps someone from OIN can enlighten us. - Luke ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] "Garbled" postgres logs
Andrew Dunstan <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Note to hackers: would it make sense to use write() instead of >> fprintf() in send_message_to_server_log to avoid any possibility >> of stdio deciding to fragment the message? Possibly there'd be >> some marginal efficiency gain too. > What about in write_syslogger_file_binary()? Since redirect_stderr is > set true in the case reported, wont that be what does the writing? No, syslogger is single-threaded so it can't be at fault. The interleaving must be happening when the data is inserted into the pipe that leads to syslogger. We've got multiple backends concurrently writing that pipe, remember. BTW, although I'm blaming stdio here, it's conceivable that it is issuing messages in a single write() and the kernel is failing to keep the writes atomic, as I think is required by spec if the write is for less than PIPEBUF bytes. So Tim might want to compare exact kernel versions as well as exact libc versions between the misbehaving machine and the others. 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] "Garbled" postgres logs
On Tue, 2007-04-03 at 15:02 -0400, Tom Lane wrote: > Tim Goodaire <[EMAIL PROTECTED]> writes: > > While going through some log files, we noticed that some of the log entries > > are "garbled". For example: > > > 2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG: > > duratio2007-03-n: 3751.27 01:19801 ms :44.139 statemenUTC [421940] > > oxrt: EXECUsor > > g aTE [P0.136.10REPARE: 8 LOG: select > > durationname fro: 3866.1m epp_do88 ms smain_dz_tatementnames wh: > > EXECUTere nameE > 2007-03-27 01:19:49.213 UTC [528480] oxrsa aepp xx.xx.xx.xx LOG: > > duration: 4510.129 ms statement: EXECUTE [PR27 > > 01:19EPARE: :49 > > .213 select nUTC [294ame from930] oxr b_domsa aain_dz_nb > > 10.4ames whe0.136.10re name 7 LOG: = $1] > > > We're seeing this in postgresql 8.1.8 on AIX 5.3. Also, even though we're > > using the same binaries for a bunch of clusters, we've only seen this issue > > on one of them. > > It looks like you've got messages from different backends being > interleaved, which is surely not impossible but normally it only happens > line-by-line at worst. This must have something to do with the > buffering behavior on stderr. Perhaps the difference is caused > by a difference in where the postmaster's stderr originally pointed > --- was this postmaster started in a different fashion than the others? No. Standard init script was used to start all clusters. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] "Garbled" postgres logs
Tom Lane wrote: Note to hackers: would it make sense to use write() instead of fprintf() in send_message_to_server_log to avoid any possibility of stdio deciding to fragment the message? Possibly there'd be some marginal efficiency gain too. What about in write_syslogger_file_binary()? Since redirect_stderr is set true in the case reported, wont that be what does the writing? cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] "Garbled" postgres logs
Tim Goodaire <[EMAIL PROTECTED]> writes: > While going through some log files, we noticed that some of the log entries > are "garbled". For example: > 2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG: > duratio2007-03-n: 3751.27 01:19801 ms :44.139 statemenUTC [421940] > oxrt: EXECUsor > g aTE [P0.136.10REPARE: 8 LOG: select > durationname fro: 3866.1m epp_do88 ms smain_dz_tatementnames wh: > EXECUTere nameE 2007-03-27 01:19:49.213 UTC [528480] oxrsa aepp xx.xx.xx.xx LOG: > duration: 4510.129 ms statement: EXECUTE [PR27 > 01:19EPARE: :49 > .213 select nUTC [294ame from930] oxr b_domsa aain_dz_nb > 10.4ames whe0.136.10re name 7 LOG: = $1] > We're seeing this in postgresql 8.1.8 on AIX 5.3. Also, even though we're > using the same binaries for a bunch of clusters, we've only seen this issue > on one of them. It looks like you've got messages from different backends being interleaved, which is surely not impossible but normally it only happens line-by-line at worst. This must have something to do with the buffering behavior on stderr. Perhaps the difference is caused by a difference in where the postmaster's stderr originally pointed --- was this postmaster started in a different fashion than the others? Note to hackers: would it make sense to use write() instead of fprintf() in send_message_to_server_log to avoid any possibility of stdio deciding to fragment the message? Possibly there'd be some marginal efficiency gain too. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Plan invalidation
"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote: >> If the invalidation were something that *had* to be accounted for, >> such as a dropped index, then there should be adequate locking for it; >> plancache is not introducing any new bug that wasn't there before. >> > Oh yes, I was wondering about the other parts of the code, not > plan invalidation. Never mind, it was just a thought. Well, as that comment notes, we've always had to worry about being sure that the relcache data structures are up-to-date (or sufficiently up-to-date, anyway). I think it's reasonably well debugged. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Plan invalidation
On 4/3/07, Tom Lane <[EMAIL PROTECTED]> wrote: I'm not particularly worried about missing a potential improvement in the plan during the first command after a change is committed. Me too. Just noticed it, so brought it up. If the invalidation were something that *had* to be accounted for, such as a dropped index, then there should be adequate locking for it; plancache is not introducing any new bug that wasn't there before. Oh yes, I was wondering about the other parts of the code, not plan invalidation. Never mind, it was just a thought. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Plan invalidation
"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > I traced it a bit and it seems that the invalidation messages > are not accepted in session 2 because the locks are already held > on the relation. Right, because of this coding in LockRelationOid(): /* * Now that we have the lock, check for invalidation messages, so that we * will update or flush any stale relcache entry before we try to use it. * We can skip this in the not-uncommon case that we already had the same * type of lock being requested, since then no one else could have * modified the relcache entry in an undesirable way. (In the case where * our own xact modifies the rel, the relcache update happens via * CommandCounterIncrement, not here.) */ if (res != LOCKACQUIRE_ALREADY_HELD) AcceptInvalidationMessages(); We could remove the optimization and do AcceptInvalidationMessages always, but I think that cure would be a great deal worse than the disease --- it would hugely increase the contention for SInvalLock. I'm not particularly worried about missing a potential improvement in the plan during the first command after a change is committed. If the invalidation were something that *had* to be accounted for, such as a dropped index, then there should be adequate locking for it; plancache is not introducing any new bug that wasn't there before. 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: [HACKERS] notification payloads
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: We'll also need to store the database id along with the event name and message, since pg_listener is per db rather than per cluster. Well, that's an artifact of the historical implementation ... does anyone want to argue that LISTEN should be cluster-wide given the opportunity? That would be a problem if you try to run multiple installations of an application that uses NOTIFY/LISTEN in separate databases in a single cluster. Applications would overhear each other. I'd consider that as a bug, not a feature. -- 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] Bug in UTF8-Validation Code?
Albe Laurenz wrote: What I suggest (and what Oracle implements, and isn't CHR() and ASCII() partly for Oracle compatibility?) is that CHR() and ASCII() convert between a character (in database encoding) and that database encoding in numeric form. Looking at Oracle documentation, it appears that you get different behavior from CHR(X [USING NCHAR_CS]) depending on whether you call it with the argument USING NCHAR_CS. Oracle 9i and higher have an additional function called NCHR(X) which is supposed to be the same as CHR(X USING NCHAR_CS). On http://www.oraclehome.co.uk/chr-function.htm it says that "To use UTF8, you specify using nchar_cs in the argument list". Does this mean that CHR(X) behaves as Tom Lane wants, and NCHR(X) behaves as Albe Laurenz wants? Vice versa? I'm not saying that Oracle compatibility is paramount. But if we can get compatibility and a reasonable implementation at the same time, that seems like a bonus. Once again, I don't have Oracle installed and cannot test this :( mark ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] notification payloads
Andrew Dunstan <[EMAIL PROTECTED]> writes: > We'll also need to store the database id along with the event name and > message, since pg_listener is per db rather than per cluster. Well, that's an artifact of the historical implementation ... does anyone want to argue that LISTEN should be cluster-wide given the opportunity? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Questions about pid file creation code
Zdenek Kotala <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The start script does not typically have the intelligence to get this >> right, particularly not the is-shmem-still-in-use part. If you check >> the archives you will find many of us on record telling people who think >> they should remove the pidfile in their start script that they're crazy. > It is true, but question is what way is better. Keep all logic in > postmaster or improve pg_ctl to share more information and keep > responsibility on start scripts or monitoring tool which has more > information about system as complex. If you have conditions PG doesn't know about, you're free to test for them in your start script. I see no reason to change this code, however. 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: [HACKERS] Synchronized Scan benchmark results
On Tue, 2007-04-03 at 10:01 +0100, Simon Riggs wrote: > On Mon, 2007-04-02 at 16:14 -0700, Jeff Davis wrote: > > > The results are very positive and quite conclusive. > > Can we show some summary results? I should be able to make some graphs today. > I'm happy that the scans stay together all the way around, even handling > the max-> 0 blockid transition well. So definite winner for me. Yes, I was happy with the results. > > However, the "sync_seqscan_offset" aspect of my patch, which attempts to > > use pages that were cached before the scan began, did not show a lot of > > promise. That aspect of my patch may end up being cut. > > Yes, please remove :-) Ok. > > The primary aspect of my patch, the Synchronized Scanning, performed > > great though. Even the CFQ scheduler, that does not appear to properly > > read ahead, performed substantially better than plain 8.2.3. And even > > better, Simon's patch didn't seem to hurt Synchronized Scans at all. > > > > Out of the 36 runs I did, a couple appear anomalous. I will retest those > > soon. > > Which ones were they? This one stood out to me: * Machine 1, Linux AS, Sync Scan patch + Recycle Buffers patch, single scan: 204s Compared to these tests: * Machine 1, Linux AS, Sync Scan patch + Recycle Buffers patch, scan.rb: all 5 scans are below 170s. * Machine 1, Linux AS, Sync Scan patch only, scan.rb: 165s. That makes no sense to me, so it's probably a fluke (by which I mean some other activity on the system, perhaps swapping some large applications). The second two tests are consistent with all the other numbers I got, but the first one took 40 seconds longer than I would expect. I'll do a simple re-test tonight. > > Note: I posted the versions of the patches that I used for the tests on > > the page above. The version of Simon's patch that I used did not apply > > cleanly to 8.2.3, but the only problem appeared to be in copy.c, so I > > went ahead with the tests. If this somehow compromised the patch, then > > let me know. > > [It was never designed to apply cleanly to 8.2.3, as we might guess] > That was v2, the current v3 should be OK because I removed the > experimental COPY interaction. That will not have affected the tests. Good to know. > I would like to see some tests with different queries that have varying > I/O and CPU requirements to see if they stay together too. That won't > block the patch, but it will help everybody understand what the range of > real world applicability there is in this. I'd guess this can benefit us > sufficiently frequently in most cases that its worth it. I'll do some more varied tests. The best idea I've come up with so far is to do something that requires random seeking going concurrently with the scans. Pgbench would probably be a good idea too, since it's more standard. Regards, Jeff Davis ---(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] notification payloads
Tom Lane wrote: Hannu Krosing <[EMAIL PROTECTED]> writes: Ühel kenal päeval, T, 2007-03-27 kell 07:11, kirjutas Andrew Dunstan: Er, what listen table? At least the list of which backends listen to which events should be also in shared mem. No, the intent is specifically that there will be *no* such global structure. All it does is add complexity, not to mention make it harder to size shared memory. How else would we know how many copies to make for each backend or when we can release the memory in case we make one copy ? The proposed design is essentially a clone of the sinval messaging system, which does not need to know either of those and does not make "one copy per backend". There's one copy, period. Further design notes: What we will need to keep track of (a la sinval) is a queue pointer per backend. I think we can add an optimization to that by keeping a count of events listened to per backend, so that we only wake up active listeners. For non listeners we can just catch them up without bothering to wake them. This will help to avoid the potential for a "thundering herd" effect that has apparently bothered some people. We'll also need to store the database id along with the event name and message, since pg_listener is per db rather than per cluster. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Implicit casts to text
Peter Eisentraut <[EMAIL PROTECTED]> writes: > FWIW, is the attached patch about what you had in mind? (It probably only > covers "normal" types at the moment.) Hm, I hadn't realized that it would take as little work as that ... I have an itchy feeling that you missed something but I'm not sure what. One thing I had wanted to do is take out the existing functions and pg_cast entries that are effectively just providing hard-wired equivalents to this, but that's merely housekeeping. 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: [HACKERS] Bug in UTF8-Validation Code?
Mark Dilger <[EMAIL PROTECTED]> writes: > Martijn van Oosterhout wrote: >> Just about every multibyte encoding other than Unicode has the problem >> of not distinguishing between the code point and the encoding of it. > Thanks for the feedback. Would you say that the way I implemented things in > the > example code would be correct for multibyte non Unicode encodings? I think it's probably defensible for non-Unicode encodings. To do otherwise would require (a) figuring out what the equivalent concept to "code point" is for each encoding, and (b) having a separate code path for each encoding to perform the mapping. It's not clear that there even is an answer to (a), and (b) seems like more work than chr() is worth. But we know what the right way is for Unicode, so we should special case that one. Note the points made that in all cases ascii() and chr() should be inverses, and that you shouldn't just fall back to the old behavior in SQL_ASCII encoding. (My vote for SQL_ASCII would be to reject values > 255.) regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Implicit casts to text
Peter, Which precise implicit casts are we breaking? Can we provide an exact list in the release notes? -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Bug in UTF8-Validation Code?
Martijn van Oosterhout wrote: On Tue, Apr 03, 2007 at 11:43:21AM +0200, Albe Laurenz wrote: IMHO this is the only good and intuitive way for CHR() and ASCII(). Hardly. The comment earlier about mbtowc was much closer to the mark. And wide characters are defined as Unicode points. Basically, CHR() takes a unicode point and returns that character in a string appropriately encoded. ASCII() does the reverse. Just about every multibyte encoding other than Unicode has the problem of not distinguishing between the code point and the encoding of it. Unicode is a collection of encodings based on the same set. Have a nice day, Thanks for the feedback. Would you say that the way I implemented things in the example code would be correct for multibyte non Unicode encodings? I don't see how to avoid the endianness issue for those encodings. mark ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Questions about pid file creation code
Tom Lane wrote: Zdenek Kotala <[EMAIL PROTECTED]> writes: Tom Lane wrote: Just to distinguish postmasters from standalone backends in the error messages. I think that's still useful. I'm not sure what you mean. It is used only in CreatePidFile function and I think that if directory is locked by some process, I don't see any useful reason to know if it is postmaster or standalone backend. You don't? Consider the decisions the user needs to take upon seeing the message --- should he kill that other process or not, and if so how? Knowing whether it's a postmaster seems pretty important to me. If somebody want to kill some process he must know what he want to do. How many postgres user know what is different between postmaster and postgres in error message? And other problem. If another application (e.g. pg_migrator) want to lock this directory to prevent data corruption. How shall it do that? How big sense have this message in this case? I suggest to remove this behavior and modify message. Yes there are. But it does not sense for me. If I want to open file and another process remove it, why I want to try created it again when another process going to do it? That could be the track of another postmaster just now shutting down. There's no reason to fail to start in such a scenario. The looping logic is necessary anyway (to guard against races involving two postmasters trying to start at the same time), so we might as well let it handle this case too. Ok. I now understand (I hope) what this loop try to handle. However, If one server go down and another go up there is only really small time piece between first open attempt and second one. I guess in this case we can say stop to the startup postmaster. For me it is better then make one hundred loops depend on cpu speed and recheck it again. I think that in this case postgres doubled role of startup scripts. There is also another issue which can occur. If you have two node with access to one shared filesystem. One node is for backup and somebody run postgres on second node. In this case postgres remove file and create own and two postgres on one dbcluster is not good idea. Good cluster solution protect this situation, but it can happen if somebody run it manually. I'm sorry, I meant why there is a pid cleanup which stays there after another postmaster crash. Many application only check OK there is some pid file -> exit. And rest is on start script or some other monitoring facility. The start script does not typically have the intelligence to get this right, particularly not the is-shmem-still-in-use part. If you check the archives you will find many of us on record telling people who think they should remove the pidfile in their start script that they're crazy. It is true, but question is what way is better. Keep all logic in postmaster or improve pg_ctl to share more information and keep responsibility on start scripts or monitoring tool which has more information about system as complex. It's not actually trying to validate the syntax of the lock file, only to make certain it doesn't trigger any unexpected behavior in kill(). I not sure if we talk about same place. Yes, we are. Read the kill(2) man page and note the special behaviors for pid = 0 or -1. The test is just trying to be darn certain we don't invoke those behaviors. No we don't :-). I mean code few lines up after atoi(). with regards Zdenek ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Synchronized Scan benchmark results
On Mon, 2007-04-02 at 21:38 -0700, Luke Lonergan wrote: > Jeff, > > Your conclusions sound great - can you perhaps put the timings in a column > in your table so we can confirm them? > I just threw the logs up, which contain the timings involved. I will try to make graphs out of them, but the data is there. The logs contain: * The time a given backend fetches a page, if that page is an even multiple of 5k * The duration of a scan * The time the scan started * The cache hit ratio as reported by log_executor_stats Your right, I do need to summarize it and make it more visually accessible. Regards, Jeff Davis ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Implicit casts to text
Am Montag, 2. April 2007 18:41 schrieb Tom Lane:
> >> The scheme that was in the back of my mind was to do this at the same
> >> time as providing a general facility for casting *every* type to and
> >> from text, by means of their I/O functions if no specialized cast is
> >> provided in pg_cast.
> http://archives.postgresql.org/pgsql-admin/2004-06/msg00390.php
> http://archives.postgresql.org/pgsql-hackers/2004-10/msg00303.php
FWIW, is the attached patch about what you had in mind? (It probably only
covers "normal" types at the moment.)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../cvs-pgsql/src/backend/parser/parse_coerce.c ./src/backend/parser/parse_coerce.c
--- ../cvs-pgsql/src/backend/parser/parse_coerce.c 2007-04-02 08:52:16.0 +0200
+++ ./src/backend/parser/parse_coerce.c 2007-04-03 18:05:12.0 +0200
@@ -371,6 +371,28 @@
r->convertformat = cformat;
return (Node *) r;
}
+ if ((inputTypeId == TEXTOID || targetTypeId == TEXTOID) && ccontext == COERCION_EXPLICIT)
+ {
+ /* Explicit coercion through I/O functions */
+ Oid inputTypeOutput;
+ Oid targetTypeInput;
+ bool isVarlena;
+ Oid typeIOParam;
+
+ getTypeInputInfo(targetTypeId, &targetTypeInput, &typeIOParam);
+ getTypeOutputInfo(inputTypeId, &inputTypeOutput, &isVarlena);
+
+ result = build_coercion_expression(build_coercion_expression(node, inputTypeOutput, arrayCoerce,
+ CSTRINGOID, -1,
+ cformat,
+ (cformat != COERCE_IMPLICIT_CAST)),
+ targetTypeInput, arrayCoerce,
+ targetTypeId, -1,
+ cformat,
+ (cformat != COERCE_IMPLICIT_CAST));
+
+ return result;
+ }
/* If we get here, caller blew it */
elog(ERROR, "failed to find conversion function from %s to %s",
format_type_be(inputTypeId), format_type_be(targetTypeId));
@@ -451,6 +473,10 @@
if (typeInheritsFrom(inputTypeId, targetTypeId))
continue;
+ /* Else only explicit coercion from/to text is possible through I/O functions */
+ if ((inputTypeId == TEXTOID || targetTypeId == TEXTOID) && ccontext == COERCION_EXPLICIT)
+ continue;
+
/*
* Else, cannot coerce at this argument position
*/
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Bug in UTF8-Validation Code?
Andrew wrote:
>> According to RFC 2279, the Euro,
>> Unicode code point 0x20AC = 0010 1010 1100,
>> will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
>>
>> IMHO this is the only good and intuitive way for CHR() and ASCII().
>
> It is beyond ludicrous for functions like chr() or ascii() to
> convert a Euro sign to 0xE282AC rather than 0x20AC. "Intuitive"? There
> is _NO SUCH THING_ as 0xE282AC as a representation of a Unicode
character
> - there is either the code point, 0x20AC (which is a _number_), or the
> sequences of _bytes_ that represent that code point in various
encodings,
> of which the three-byte sequence 0xE2 0x82 0xAC is the one used in
UTF-8.
Yes, 0xE2 0x82 0xAC is the representation in UTF-8, and UTF-8 is the
database encoding in use.
> Functions like chr() and ascii() should be dealing with the _number_
of the
> code point, not with its representation in transfer encodings.
I think that we have a fundamental difference.
As far as I know, the word "code point" is only used in UNICODE and
is the first column in the list
http://www.unicode.org/Public/UNIDATA/UnicodeData.txt
So, if I understand you correctly, you want CHR() and ASCII()
to convert between characters (in the current database encoding)
and UNICODE code points (independent of database encoding).
What I suggest (and what Oracle implements, and isn't CHR() and ASCII()
partly for Oracle compatibility?) is that CHR() and ASCII()
convert between a character (in database encoding) and
that database encoding in numeric form.
I think that what you suggest would be a useful function too,
but I certainly wouldn't call such a function ASCII() :^)
The current implementation seems closer to my idea of ASCII(),
only incomplete:
test=> select to_hex(ascii('EUR'));
to_hex
e2
(1 row)
What do others think? Should the argument to CHR() be a Unicode
code point or the numeric representation of the database encoding?
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] Implicit casts to text
Am Dienstag, 3. April 2007 17:17 schrieb Bruce Momjian: > I assumed the issue was that there might not be explicit casts for every > case were were now disallowing. My proposal is to "downgrade" some casts from implicit to assignment. Tom's proposal is to add more casts at the level of explicit, which is farther below assignment. No cast will be lost. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PL/Python warnings in CVS HEAD
Great, patch applied and TODO item removed. --- Marko Kreen wrote: > On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote: > > On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > Great. Care to take on the Python boolean patch? > > > > > > o Allow PL/PythonU to return boolean rather than 1/0 > > I think this should be also solved with backwards-compat ifdef. > > Tested with python 2.2, 2.3, 2.4, 2.5. > > -- > marko [ Attachment, skipping... ] -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Auto Partitioning Patch - WIP version 1
Hi, The following things are TODOs: iv) Auto generate rules using the checks mentioned for the partitions, to handle INSERTs/DELETEs/UPDATEs to navigate them to the appropriate child. Note that checks specified directly on the master table will get inherited automatically. Am planning to do the above by using the check constraint specified for each partition. This constraint's raw_expr field ends up becoming the whereClause for the rule specific to that partition. One question is whether we should we allow auto creation of UPDATE rules given that updates can end up spanning multiple partitions if the column on which partitioning is specified gets updated? Also if we decide to auto - add rules for UPDATE, the raw_expr will need to be modified to refer to "OLD."col, which can be quite a headache. We do not have parsetree walker/mutator functions as far as I could see in the code. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com
[HACKERS] "Garbled" postgres logs
While going through some log files, we noticed that some of the log entries are "garbled". For example: 2007-03-27 01:19:44.139 UTC [1761474] oxrsa aepp xx.xx.xx.xx LOG: duratio2007-03-n: 3751.27 01:19801 ms :44.139 statemenUTC [421940] oxrt: EXECUsor g aTE [P0.136.10REPARE: 8 LOG: select durationname fro: 3866.1m epp_do88 ms smain_dz_tatementnames wh: EXECUTere nameE [PR27 01:19EPARE: :49 .213 select nUTC [294ame from930] oxr b_domsa aain_dz_nb 10.4ames whe0.136.10re name 7 LOG: = $1] Here are the logging sections in the postgresql.conf file: log_destination = 'stderr' redirect_stderr = on log_directory = '/opt/rg/logs/pgsql81' log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' log_truncate_on_rotation = off log_rotation_age = 1440 log_rotation_size = 10240 log_line_prefix = '%m [%p] %d %u %h ' # Special values: We're seeing this in postgresql 8.1.8 on AIX 5.3. Also, even though we're using the same binaries for a bunch of clusters, we've only seen this issue on one of them. Any ideas of what could cause this? -- Tim Goodaire416-673-4126[EMAIL PROTECTED] Database Team Lead, Afilias Canada Corp. pgpOpq9wXJTsy.pgp Description: PGP signature
Re: [HACKERS] PL/Python warnings in CVS HEAD
On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote: On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > Great. Care to take on the Python boolean patch? > > o Allow PL/PythonU to return boolean rather than 1/0 I think this should be also solved with backwards-compat ifdef. Tested with python 2.2, 2.3, 2.4, 2.5. -- marko py-bool.diff Description: Binary data ---(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] Implicit casts to text
Peter Eisentraut wrote: > Am Montag, 2. April 2007 18:41 schrieb Tom Lane: > > Certainly they'd all be explicit-only. ?From a technical perspective > > there's no need to do the two things at the same time; I'm just opining > > that we could sell it easier if we did them together. ?If we just do > > this part, what users will see is that we broke their queries for what > > to them will appear to be no particular gain. > > I find this method of selling features very unusual. The two issues under > consideration have nothing in common except that they have "cast" in their > subject line. The reduction of implicit casts to text has to stand on its > own: the purpose is to produce more reliable expression behavior. Those > whose queries this would break are not helped by having other casts available > without work; they'd still have to do manual fixups. So what we'd have > is "Sorry, casting int to text implicitly doesn't work anymore, but instead > you can cast $othertype to text explicitly." How does that help anyone? I assumed the issue was that there might not be explicit casts for every case were were now disallowing. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://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: [HACKERS] Implicit casts to text
Am Montag, 2. April 2007 18:41 schrieb Tom Lane: > Certainly they'd all be explicit-only. From a technical perspective > there's no need to do the two things at the same time; I'm just opining > that we could sell it easier if we did them together. If we just do > this part, what users will see is that we broke their queries for what > to them will appear to be no particular gain. I find this method of selling features very unusual. The two issues under consideration have nothing in common except that they have "cast" in their subject line. The reduction of implicit casts to text has to stand on its own: the purpose is to produce more reliable expression behavior. Those whose queries this would break are not helped by having other casts available without work; they'd still have to do manual fixups. So what we'd have is "Sorry, casting int to text implicitly doesn't work anymore, but instead you can cast $othertype to text explicitly." How does that help anyone? -- 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
Re: [HACKERS] Bug in UTF8-Validation Code?
On Tue, Apr 03, 2007 at 11:43:21AM +0200, Albe Laurenz wrote: > IMHO this is the only good and intuitive way for CHR() and ASCII(). Hardly. The comment earlier about mbtowc was much closer to the mark. And wide characters are defined as Unicode points. Basically, CHR() takes a unicode point and returns that character in a string appropriately encoded. ASCII() does the reverse. Just about every multibyte encoding other than Unicode has the problem of not distinguishing between the code point and the encoding of it. Unicode is a collection of encodings based on the same set. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] Modifying TOAST thresholds
Tom, On 4/3/07 7:15 AM, "Tom Lane" <[EMAIL PROTECTED]> wrote: > BTW, it strikes me that a GUC variable is quite the wrong way to go > about this. The right way is a table storage parameter, a la FILLFACTOR, > so that it can be set on a per-table basis. That would also give us a > chance to fix my concern about needs_toast_table: the case where we > might need a toast table that we didn't need before is where the toast > threshold is lowered via ALTER TABLE SET, and we could reasonably make > that command recheck the situation. This also seems to also support further development along the vertical partitioning path. Any thought on support of per-column TOAST tables? - Luke ---(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: [PATCHES] [HACKERS] Arrays of Complex Types
Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote: > >> So, hum, what happened to the idea of creating the array types only > >> on demand? > > > Scotched, as far as I could tell, > > More like "you submitted a patch that entirely ignores multiple people's > opinion on what is needed". > > Bruce may have put this into the patch queue, but do not labor under > the delusion that that means it'll get applied as-is. The queue is > currently operating as a list of open issues. Correct. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Modifying TOAST thresholds
Chris Browne <[EMAIL PROTECTED]> writes: > Here's a "drafty" patch that *tries* to do this using a GUC variable; > it passes some interactive testing. BTW, it strikes me that a GUC variable is quite the wrong way to go about this. The right way is a table storage parameter, a la FILLFACTOR, so that it can be set on a per-table basis. That would also give us a chance to fix my concern about needs_toast_table: the case where we might need a toast table that we didn't need before is where the toast threshold is lowered via ALTER TABLE SET, and we could reasonably make that command recheck the situation. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Plan invalidation
I noticed that the plan invalidation is not immediately effective. Not sure whether it's worth fixing or has any other side-effects, but thought would just post it. I was testing the following scenario: session1session2 CREATE TABLE test (int a, int b); INSERT INTO TABLE SET enable_seqscan = off BEGIN PREPARE myplan AS SELECT * FROM TEST WHERE a = 100; EXPLAIN EXECUTE myplan; (seq scan) CREATE INDEX -> EXPLAIN EXECUTE myplan (seq scan) EXPLAIN EXECUTE myplan (index scan) The second "EXPLAIN" in session 2 uses seq scan because the plan is not invalidated and replanned properly. Ideally it should have used the index scan. I traced it a bit and it seems that the invalidation messages are not accepted in session 2 because the locks are already held on the relation. At the end of the command, session 2 calls CommandCounterIncrement() and gets the invalidation messages. Hence the next EXPLAIN revalidates the plan properly. May be this is not such an important issue. But I was wondering if there are other places in the code where we might miss or receive invalidation messages with a delay, mostly because of *lack* of lock conflict ? Thanks, Pavan -- EnterpriseDBhttp://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] CheckpointStartLock starvation
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: Nor will that work for prepared xacts --- you don't want to wait for the eventual commit, only for PREPARE TRANSACTION to exit its critical section. PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no clog changes to protect from at that point. It would be set in RecordTransactionCommitPrepared when we're really committing. Just like we use the CheckpointStartLock today. Indeed --- you'd better take another look at where we use the CheckpointStartLock today. Yeah, while writing the patch I noticed that we really do use it in EndPrepare to avoid a similar race condition with the twophase state file.. -- Heikki Linnakangas 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] CheckpointStartLock starvation
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Nor will that work for prepared xacts --- you don't want to wait for the >> eventual commit, only for PREPARE TRANSACTION to exit its critical >> section. > PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no clog > changes to protect from at that point. It would be set in > RecordTransactionCommitPrepared when we're really committing. Just like > we use the CheckpointStartLock today. Indeed --- you'd better take another look at where we use the CheckpointStartLock today. 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: [HACKERS] PL/Python warnings in CVS HEAD
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: Great. Care to take on the Python boolean patch? o Allow PL/PythonU to return boolean rather than 1/0 http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php It requires only a few lines of code, but some testing, which you seem to have available. Ok. -- marko ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Bug in UTF8-Validation Code?
On 2007-04-03, "Albe Laurenz" <[EMAIL PROTECTED]> wrote: > According to RFC 2279, the Euro, > Unicode code point 0x20AC = 0010 1010 1100, > will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC. > > IMHO this is the only good and intuitive way for CHR() and ASCII(). It is beyond ludicrous for functions like chr() or ascii() to convert a Euro sign to 0xE282AC rather than 0x20AC. "Intuitive"? There is _NO SUCH THING_ as 0xE282AC as a representation of a Unicode character - there is either the code point, 0x20AC (which is a _number_), or the sequences of _bytes_ that represent that code point in various encodings, of which the three-byte sequence 0xE2 0x82 0xAC is the one used in UTF-8. Functions like chr() and ascii() should be dealing with the _number_ of the code point, not with its representation in transfer encodings. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(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: [PATCHES] [HACKERS] Full page writes improvement, code update
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Koichi Suzuki wrote: > Bruce Momjian wrote: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > > > http://momjian.postgresql.org/cgi-bin/pgpatches > > Thank you very much for including. Attached is an update of the patch > according to Simon Riggs's comment about GUC name. > > Regards; > > -- > Koichi Suzuki [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PL/Python warnings in CVS HEAD
Patch applied. Thanks. --- Marko Kreen wrote: > On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote: > > On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > Where are we on Python 2.5? > > > > I'll look into it. > > Following patch converts plpython.c to use Python 2.5 types, > with compat ifdef for older version. This is recommended > method by PEP 353 to fix the issue. > > Tested with python 2.4.3, 2.5. > > -- > marko [ Attachment, skipping... ] > > ---(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 -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] PL/Python warnings in CVS HEAD
Great. Care to take on the Python boolean patch? o Allow PL/PythonU to return boolean rather than 1/0 http://archives.postgresql.org/pgsql-patches/2007-01/msg00596.php It requires only a few lines of code, but some testing, which you seem to have available. --- Marko Kreen wrote: > On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote: > > On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > Where are we on Python 2.5? > > > > I'll look into it. > > Following patch converts plpython.c to use Python 2.5 types, > with compat ifdef for older version. This is recommended > method by PEP 353 to fix the issue. > > Tested with python 2.4.3, 2.5. > > -- > marko [ Attachment, skipping... ] > > ---(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 -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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: [PATCHES] [HACKERS] Arrays of Complex Types
On Tue, Apr 03, 2007 at 02:30:07AM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote: > >> So, hum, what happened to the idea of creating the array types > >> only on demand? > > > Scotched, as far as I could tell, > > More like "you submitted a patch that entirely ignores multiple > people's opinion on what is needed". > > Bruce may have put this into the patch queue, but do not labor under > the delusion that that means it'll get applied as-is. I assure you I'm not. Two glaring things it's missing are regression tests and documentation. I should have those in this week. Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(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] PL/Python warnings in CVS HEAD
Marko Kreen escribió: > On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote: > >On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > >> Where are we on Python 2.5? > > > >I'll look into it. > > Following patch converts plpython.c to use Python 2.5 types, > with compat ifdef for older version. This is recommended > method by PEP 353 to fix the issue. > > Tested with python 2.4.3, 2.5. No compiler warnings, regression tests pass here on Python 2.4.4. $ uname -a Linux perhan 2.6.18-3-amd64 #1 SMP Mon Dec 4 17:04:37 CET 2006 x86_64 GNU/Linux -- 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] PthreadGC2 of MinGW is not linked.
From: "Dave Page" <[EMAIL PROTECTED]> Magnus Hagander wrote: On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote: Slony-I is still used...Ahh, I have not confirmed it yet. Slony uses it, yes. It would probably be worthwhile to fix that one as well, but I haven't looked at how much work that would be. And to port the build system to msbuild... :-) Ugaa, Probably, I expected for fear of it. :-) Furthermore, PostGIS is required. For the time being, it is necessary to fight with the nightmare. I was able to give good environment. It will be desired. surely :-) Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PthreadGC2 of MinGW is not linked.
Magnus Hagander wrote: On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote: Slony-I is still used...Ahh, I have not confirmed it yet. Slony uses it, yes. It would probably be worthwhile to fix that one as well, but I haven't looked at how much work that would be. And to port the build system to msbuild... :-) /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PthreadGC2 of MinGW is not linked.
On Tue, Apr 03, 2007 at 06:16:26PM +0900, Hiroshi Saito wrote: > Hi. > > >>Am I misunderstanding it? > > > >That is intended. With the changes that was put in to ecpg, pthreads is no > >longer required. We use the native threading on Windows instead. > > > >Also, enable_thread_safety is now the default for windows :-) > > Ooops, Isn't pthreadGC2 necessary? Not any more. > Slony-I is still used...Ahh, I have not confirmed it yet. Slony uses it, yes. It would probably be worthwhile to fix that one as well, but I haven't looked at how much work that would be. //Magnus ---(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] Oracle indemnifies PostgreSQL on its patents
what can't be purchased and silenced, should be killed with rain of law suits. Microsoft does it, novell does it, sco does it, and oracle too. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Full page writes improvement, code update
Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches Thank you very much for including. Attached is an update of the patch according to Simon Riggs's comment about GUC name. Regards; -- Koichi Suzuki 20070403_pg_lesslog.tgz Description: Binary data ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PL/Python warnings in CVS HEAD
On 4/3/07, Marko Kreen <[EMAIL PROTECTED]> wrote: On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > Where are we on Python 2.5? I'll look into it. Following patch converts plpython.c to use Python 2.5 types, with compat ifdef for older version. This is recommended method by PEP 353 to fix the issue. Tested with python 2.4.3, 2.5. -- marko python25.diff Description: Binary data ---(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: [PATCHES] [HACKERS] Full page writes improvement, code update again.
Here's third revision of WAL archival optimization patch. GUC parameter name was changed to wal_add_optimization_info. Regards; -- Koichi Suzuki 20070403_pg_lesslog.tar.gz Description: application/gzip ---(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] Bug in UTF8-Validation Code?
Mark Dilger wrote:
>>> In particular, in UTF8 land I'd have expected the argument of chr()
>>> to be interpreted as a Unicode code point, not as actual UTF8 bytes
>>> with a randomly-chosen endianness.
>>>
>>> Not sure what to do in other multibyte encodings.
>>
>> "Not sure what to do in other multibyte encodings" was pretty much my
>> rationale for this particular behavior. I standardized on network
byte
>> order because there are only two endianesses to choose from, and the
>> other seems to be a more surprising choice.
>
> Since chr() is defined in oracle_compat.c, I decided to look
> at what Oracle might do. See
>
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96540/func
tions18a.htm
>
> It looks to me like they are doing the same thing that I did,
> though I don't have Oracle installed anywhere to verify that.
> Is there a difference?
This is Oracle 10.2.0.3.0 ("latest and greatest") with UTF-8 encoding
(actually, Oracle chooses to call this encoding AL32UTF8):
SQL> SELECT ASCII('EUR') AS DEC,
2 TO_CHAR(ASCII('EUR'), 'XX') AS HEX
3 FROM DUAL;
DEC HEX
--
14844588 E282AC
SQL> SELECT CHR(14844588) AS EURO FROM DUAL;
EURO
EUR
I don't see how endianness enters into this at all - isn't that just
the question of how a byte is stored physically?
According to RFC 2279, the Euro,
Unicode code point 0x20AC = 0010 1010 1100,
will be encoded to 1110 0010 1000 0010 1010 1100 = 0xE282AC.
IMHO this is the only good and intuitive way for CHR() and ASCII().
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] PthreadGC2 of MinGW is not linked.
Hi. Am I misunderstanding it? That is intended. With the changes that was put in to ecpg, pthreads is no longer required. We use the native threading on Windows instead. Also, enable_thread_safety is now the default for windows :-) Ooops, Isn't pthreadGC2 necessary? Slony-I is still used...Ahh, I have not confirmed it yet. I was too busy and did not catch up with you I start the work at once. Thanks! Regards, Hiroshi Saito ---(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] PthreadGC2 of MinGW is not linked.
On Tue, Apr 03, 2007 at 06:06:16PM +0900, Hiroshi Saito wrote: > Hi Magnus. > > configure was changed the cvs head. > Is this what you intended it?_? > > I think necessary to recover it. > > *** configure.orig Tue Apr 3 17:51:06 2007 > --- configure Tue Apr 3 17:52:21 2007 > *** > *** 16732,16739 > # For each platform, we need to know about any special compile and link > # libraries, and whether the normal C function names are thread-safe. > # See the comment at the top of src/port/thread.c for more information. > ! # WIN32 doesn't need the pthread tests; it always uses threads > ! if test "$enable_thread_safety" = yes -a "$PORTNAME" != "win32"; then > > > --- 16732,16738 > # For each platform, we need to know about any special compile and link > # libraries, and whether the normal C function names are thread-safe. > # See the comment at the top of src/port/thread.c for more information. > ! if test "$enable_thread_safety" = yes; then > > Am I misunderstanding it? That is intended. With the changes that was put in to ecpg, pthreads is no longer required. We use the native threading on Windows instead. Also, enable_thread_safety is now the default for windows :-) //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] PthreadGC2 of MinGW is not linked.
Hi Magnus. configure was changed the cvs head. Is this what you intended it?_? I think necessary to recover it. *** configure.orig Tue Apr 3 17:51:06 2007 --- configure Tue Apr 3 17:52:21 2007 *** *** 16732,16739 # For each platform, we need to know about any special compile and link # libraries, and whether the normal C function names are thread-safe. # See the comment at the top of src/port/thread.c for more information. ! # WIN32 doesn't need the pthread tests; it always uses threads ! if test "$enable_thread_safety" = yes -a "$PORTNAME" != "win32"; then --- 16732,16738 # For each platform, we need to know about any special compile and link # libraries, and whether the normal C function names are thread-safe. # See the comment at the top of src/port/thread.c for more information. ! if test "$enable_thread_safety" = yes; then Am I misunderstanding it? Regards, Hiroshi Saito ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Synchronized Scan benchmark results
On Mon, 2007-04-02 at 16:14 -0700, Jeff Davis wrote: > The results are very positive and quite conclusive. Can we show some summary results? I'm happy that the scans stay together all the way around, even handling the max-> 0 blockid transition well. So definite winner for me. > However, the "sync_seqscan_offset" aspect of my patch, which attempts to > use pages that were cached before the scan began, did not show a lot of > promise. That aspect of my patch may end up being cut. Yes, please remove :-) > The primary aspect of my patch, the Synchronized Scanning, performed > great though. Even the CFQ scheduler, that does not appear to properly > read ahead, performed substantially better than plain 8.2.3. And even > better, Simon's patch didn't seem to hurt Synchronized Scans at all. > > Out of the 36 runs I did, a couple appear anomalous. I will retest those > soon. Which ones were they? > Note: I posted the versions of the patches that I used for the tests on > the page above. The version of Simon's patch that I used did not apply > cleanly to 8.2.3, but the only problem appeared to be in copy.c, so I > went ahead with the tests. If this somehow compromised the patch, then > let me know. [It was never designed to apply cleanly to 8.2.3, as we might guess] That was v2, the current v3 should be OK because I removed the experimental COPY interaction. That will not have affected the tests. I would like to see some tests with different queries that have varying I/O and CPU requirements to see if they stay together too. That won't block the patch, but it will help everybody understand what the range of real world applicability there is in this. I'd guess this can benefit us sufficiently frequently in most cases that its worth it. -- 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] PL/Python warnings in CVS HEAD
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: Where are we on Python 2.5? I'll look into it. -- marko ---(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] CheckpointStartLock starvation
Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: Tom Lane wrote: What sort of "wait for finish" mechanism do you have in mind? I was thinking of XactLockTableWait. Ugh. I don't think the bgwriter can participate in heavyweight-lockmgr operations, or should become able to. Oh, good point. I suppose we could just poll and sleep, checkpoint is a heavy operation anyway so a little delay wouldn't hurt. Nor will that work for prepared xacts --- you don't want to wait for the eventual commit, only for PREPARE TRANSACTION to exit its critical section. PREPARE TRANSACTION wouldn't set the flag in MyProc; there's no clog changes to protect from at that point. It would be set in RecordTransactionCommitPrepared when we're really committing. Just like we use the CheckpointStartLock today. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Modifying TOAST thresholds
> > ... should we revel > > in configurability, and allow CREATE TABLE/ALTER TABLE behavior to > > vary depending on the current threshold setting? We'd have to fix the > > toaster routines to not try to push stuff out-of-line when there is no > > out-of-line to push to ... but I think we probably had better do that > > anyway for robustness, if we're allowing any variability at all in > > these numbers. > > Actually, upon looking closely at the toast code, it already > does the right thing when there's no toast table. Good on > someone for getting that right. But we still need to think > about whether it's sane for CREATE/ALTER TABLE to condition > the create-a-toast-table decision on a parameter that may now > be changeable. I think it is ok to decide during creation with current settings. When a user wants a toast table that has not been created we can direct them to use some dummy "alter table ... set storage ..." and create a toast table if it does not exist (and the new settings opt for one). And a new threshold has immediate consequences for inline compression, so a change is not ignored. Andreas ---(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] Interaction of PITR backups andBulkoperationsavoiding WAL
On Mon, 2007-04-02 at 19:09 -0400, Bruce Momjian wrote: > Where is this patch? see Hackers thread: "Minor changes to Recovery related code", Mar 30 -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Calling void functions
Pavel Stehule wrote: > it's problem. You cannot do it now. One year ago I sent patch > > http://archives.postgresql.org/pgsql-patches/2006-03/msg00196.php The only comments to that were that no one knew what it was good for. But now we know, so I think we should add your patch. Tom Lane did it before you nice a day Pavel _ Citite se osamele? Poznejte nekoho vyjmecneho diky Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
