[HACKERS] strcoll_l an new approach for locale per column
in this list there is some discussion about adding support locale per column. as far as I know the final result was that: because postgresql uses glibc locale functions, and because glibc only handle one locale, postgresql also suppor only one locale at the same time. one solution was that use some help functions (such as nls_sort, or strxfrm...) and use setlocale to support other locale. the main problem with these solutions was that 1. it is not standart 2. the overhead of setlocale is too high as far as I investigate the glibc code, I found some extention function such as strcol_l and strxfrm_l that let you to pass locale to them. so you dont have to change locale repeatedly. I want to know the groups idea? Best Regards __ Do you Yahoo!? Send holiday email and support a worthy cause. Do good. http://celebrity.mail.yahoo.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] getting 'order by' working with unicode locale? ICU?
Ühel kenal päeval (laupäev, 18. detsember 2004, 02:41+0100), kirjutas Palle Girgensohn: --On torsdag, december 16, 2004 09.20.50 +0100 Peter Eisentraut [EMAIL PROTECTED] wrote: Palle Girgensohn wrote: Not on FreeBSD, since collation is not implemented in unicode locales. One way would be to implement it in the OS, of course... Try taking the locale definition files from another system and use localedef to build locale files for your local system. The localedef source files are supposed to be portable. As far as I understand, there is no code in FreeBSD to specify the collating order for multibyte locales. Would ot be easier to fix the OS or hack ICU into PostgreSQL? A bit off topic: I'm still dreaming of a way to get order by working with different locales for the same database (different clients getting different collation depending on their locale choice). Now this is hardcoded at initdb time. Is there any way this could work, ever, in PostgreSQL, or will I have to sort client side? I guess you can write a function that returns something client-specific and sort on that. select weirdnames from namelist order by localesort(weirdnames, 'SE'); You can even build and index on localesort(weirdnames, 'SE') to speed things up for some queries. And yes, I think using ICU is the right way to do it ;) -- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Thoughts about updateable views
Jaime Casanova wrote: In a galaxy far, far away Bernd wrote: The context: http://archives.postgresql.org/pgsql-hackers/2004-03/msg00999.php so joined views are even not updateable, too. I don't find the why of this on the specs and the threads about this issue ignore the comment. BEGIN QUOTE In O'Reilly there are also the conditions mentioned a view has to pass when declaring it updateable (also SQL99): - The SELECT of the CREATE VIEW command depends only on one table - UNION, EXCEPT and INTERSECT are not part of the View's SELECT - No GROUP BY or HAVING - Pseudo-Columns are forbidden, too (but i think that can improved to functions) - No Aggregates - No DISTINCT so joined views are even not updateable, too. END QUOTE Well, I haven't checked the specs, but this list is clearly incorrect from a theoretical point of view (I've been thinking about this recently). There are two things (AFAICT) you need to be able to do to update (NOTE - not insert) a view. 1. Identify the underlying table(s) for the updated column(s) 2. Identify (primary) key values for the table(s) being updated. So - I could have a join listing users and how many email aliases they have (so sum()) and still update their name, so long as the key for the users table was present in the view. Any summarising rules out updates for the summarised tables (because you no longer have a key available). Similarly, expression/function columns can't be updated (except in certain special cases). UNION etc doesn't necessarily mean you can't update, so long as the underlying table/key can be identified. For INSERTing to a view, the same rules apply, but obviously you need to be able to identify table/keys for all columns in the view. This clearly rules out aggregates etc. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Can't Restart ver 8.0b3
Anyone, I would not describe my situation as desprate (yet), but it is painful, and I am looking for some information and a degree of confidence. I have yet to communicate w/ our sysadmin about backup/restore. We are using version 8.0 beta 3, on Red Hat Linux, to develop a product that we plan to released in several months. The problem began when I tried to make some table modifications. A CREATE statement hung. I canceled. I then noticed many backend processes hung idle in transaction. I had everyone exit their database activities, but several hung transactions still remained. I then did a pg_ctl stop followed by a pg_ctl start. Here is the log file activity: (I got lots of these. Probably people exiting their clients) LOG: could not receive data from client: Connection reset by peer LOG: unexpected EOF on client connection LOG: could not receive data from client: Connection reset by peer LOG: unexpected EOF on client connection (Then this; probably after pg_ctl stop) LOG: received fast shutdown request LOG: aborting any active transactions FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command FATAL: terminating connection due to administrator command LOG: shutting down LOG: database system is shut down (Now this after pg_ctl start) LOG: could not create IPv6 socket: Address family not supported by protocol LOG: database system was shut down at 2004-12-21 16:30:25 EST LOG: checkpoint record is at 0/278B3430 LOG: redo record is at 0/278B3430; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 884736; next OID: 306834 PANIC: could not access status of transaction 884736 DETAIL: could not read from file /usr/local/pgsql8b3/data/pg_clog/ at offset 221184: Success LOG: startup process (PID 17774) was terminated by signal 6 LOG: aborting startup due to startup process failure It turns out that /usr/local/pgsql8b3/data/pg_clog/ exists, is read/writable by postgres, and is exactly 221184 bytes long. So I started pursuing recovery documents. Came across pg_resetxlog. First I tried without the force option. It complained that it would not work. Then, using the -f option; that changed nothing. Then I began using the -f, -x and -l options: as follows: First some useful information for you: $ ls -l /usr/local/pgsql8b3/data/pg_clog/ -rw---1 postgres postgres 221184 Dec 21 16:12 and $ls -l /usr/local/pgsql8b3/data/pg_xlog -rw---1 postgres postgres 16777216 Dec 22 06:16 000100010068 drwx--2 postgres postgres 4096 Sep 28 04:57 archive_status Like the doc describes, I tried: $ postgres pg_resetxlog -f -x 0x10 -l 0x1,0x1,0x65 /usr/local/pgsql8b3/data (Now I get this in the log) LOG: could not create IPv6 socket: Address family not supported by protocol LOG: database system was shut down at 2004-12-21 20:11:12 EST LOG: checkpoint record is at 1/641C LOG: redo record is at 1/641C; undo record is at 1/641C; shutdown TRUE LOG: next transaction ID: 1048576; next OID: 306834 PANIC: could not access status of transaction 1048576 DETAIL: could not open file /usr/local/pgsql8b3/data/pg_clog/0001: No such file or directory LOG: startup process (PID 304) was terminated by signal 6 LOG: aborting startup due to startup process failure Which is correct, there is no file: /usr/local/pgsql8b3/data/pg_clog/0001. Also, this is the output of pg_controldata after running pg_resetxlog: pg_control version number:74 Catalog version number: 200408031 Database system identifier: 4708838347263258567 Database cluster state: in production pg_control last modified: Wed 22 Dec 2004 06:17:55 AM EST Current log file ID: 1 Next log file segment:105 Latest checkpoint location: 1/681C Prior checkpoint location:0/0 Latest checkpoint's REDO location:1/681C Latest checkpoint's UNDO location:1/681C Latest checkpoint's TimeLineID: 1 Latest checkpoint's NextXID: 1048576 Latest checkpoint's NextOID: 306834 Time of latest checkpoint:Wed 22 Dec 2004 06:16:27 AM EST Database block size: 8192 Blocks per segment of large relation: 131072 Bytes per WAL segment:16777216 Maximum length of identifiers:64 Maximum number of function arguments: 32 Date/time type storage: floating-point numbers Maximum length of locale name:128 LC_COLLATE: en_US.UTF-8 LC_CTYPE: en_US.UTF-8 Can someone help me make sense of all this? Thanks, David ---(end of
[HACKERS] oldish libpq bug still in RC2
It seems that this bug is still lurking in libpq: http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php Is anybody working on it, or should I try something myself, perhaps just replacing the lone recv() with pqsecure_read() ? -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Thoughts about updateable views
Hi, On Wed, Dec 22, 2004 at 09:41:40AM +, Richard Huxton wrote: UNION etc doesn't necessarily mean you can't update, so long as the underlying table/key can be identified. I think you mean UNION ALL, i.e. the set addition, don't you? Otherwise UNION (wothout ALL) is kind of a aggregation due to it only adds a row once to the resulting set wheter it is found twice or not. Therefore any updates are not possible. Regards, Yann ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thoughts about updateable views
Yann Michel wrote: Hi, On Wed, Dec 22, 2004 at 09:41:40AM +, Richard Huxton wrote: UNION etc doesn't necessarily mean you can't update, so long as the underlying table/key can be identified. I think you mean UNION ALL, i.e. the set addition, don't you? Otherwise UNION (wothout ALL) is kind of a aggregation due to it only adds a row once to the resulting set wheter it is found twice or not. Therefore any updates are not possible. Not if you can identify the underlying table(s) and key(s). If the UNION hides that information, then you are correct. Imagine the case where you were running a calendar system and had people_invited unioned with rooms_booked - you could in theory alter the name on both. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] RC2 and open issues
Tom Lane [EMAIL PROTECTED] writes: Maybe we need a hybrid approach: clean a few percent of the LRU end of the ARC list in order to keep backends from blocking on writes, plus run a clock scan to keep checkpoints from having to do much. Well if you just keep note of when the last clock scan started then when you get to the end of the list you've _done_ a checkpoint. Put another way, we already have such a clock scan, it's called checkpoint. You could have checkpoint delay between each page write long enough to spread the checkpoint i/o out over a configurable amount of time -- say half the checkpoint interval -- and be done with that side of things. -- greg ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] strcoll_l an new approach for locale per column
Mahmoud Taghizadeh [EMAIL PROTECTED] writes: as far as I investigate the glibc code, I found some extention function such as strcol_l and strxfrm_l that let you to pass locale to them. so you dont have to change locale repeatedly. Sorry, but depending on glibc-only functionality is a non-starter. We run on many platforms that use other libc implementations. Anything not standardized by the Single Unix Spec isn't even worth suggesting... http://www.opengroup.org/onlinepubs/007908799/ regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thoughts about updateable views
Richard Huxton dev@archonet.com writes: There are two things (AFAICT) you need to be able to do to update (NOTE - not insert) a view. 1. Identify the underlying table(s) for the updated column(s) 2. Identify (primary) key values for the table(s) being updated. So - I could have a join listing users and how many email aliases they have (so sum()) and still update their name, so long as the key for the users table was present in the view. No; you'd also have to have some guarantee that a given underlying table row gives rise to at most one join row. If the same table row gives rise to multiple join rows, then a request specifying an UPDATE of just one of those join rows can't be satisfied. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Can't Restart ver 8.0b3
Dave Hartwig [EMAIL PROTECTED] writes: LOG: next transaction ID: 884736; next OID: 306834 PANIC: could not access status of transaction 884736 DETAIL: could not read from file /usr/local/pgsql8b3/data/pg_clog/ at offset 221184: Success LOG: startup process (PID 17774) was terminated by signal 6 LOG: aborting startup due to startup process failure Hmm ... do we have a problem when the next XID is exactly at a page boundary? I'll look into that. LOG: next transaction ID: 1048576; next OID: 306834 PANIC: could not access status of transaction 1048576 DETAIL: could not open file /usr/local/pgsql8b3/data/pg_clog/0001: No such file or directory IIRC, pg_resetxlog doesn't have any provision to create new pg_clog segments. Which is probably an oversight, but it's easy enough to do it by hand. Do something like dd bs=8k count=1 /dev/zero /usr/local/pgsql8b3/data/pg_clog/0001 and everything should be fine. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] oldish libpq bug still in RC2
Hannu Krosing [EMAIL PROTECTED] writes: It seems that this bug is still lurking in libpq: http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php Is anybody working on it, or should I try something myself, perhaps just replacing the lone recv() with pqsecure_read() ? Go for it. The difficulty I think is testing that the failure path actually does the right thing. Do you have the ability to provoke the failure on demand? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Thoughts about updateable views
--On Mittwoch, Dezember 22, 2004 11:25:42 -0500 Tom Lane [EMAIL PROTECTED] wrote: Richard Huxton dev@archonet.com writes: There are two things (AFAICT) you need to be able to do to update (NOTE - not insert) a view. 1. Identify the underlying table(s) for the updated column(s) 2. Identify (primary) key values for the table(s) being updated. So - I could have a join listing users and how many email aliases they have (so sum()) and still update their name, so long as the key for the users table was present in the view. No; you'd also have to have some guarantee that a given underlying table row gives rise to at most one join row. If the same table row gives rise to multiple join rows, then a request specifying an UPDATE of just one of those join rows can't be satisfied. Not sure if i understand correctly, but that means JOINs between 1:n relations falls under the not updateable category, because the parent row triggers updates to n possible child rows? -- Bernd ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thoughts about updateable views
Richard Huxton dev@archonet.com writes: Yann Michel wrote: I think you mean UNION ALL, i.e. the set addition, don't you? Not if you can identify the underlying table(s) and key(s). If the UNION hides that information, then you are correct. If a unique key of the underlying table is included in the UNION data, then there can't be any duplicate rows and so the UNION really reduces to UNION ALL. However, I'm unconvinced that there are any cases like this that are interesting in practice. Consider CREATE TABLE a (id int primary key, ...); CREATE TABLE b (id int primary key, ...); CREATE VIEW v AS SELECT * FROM a UNION SELECT * FROM b; If a and b have disjoint key sets then the UNION is theoretically updatable, but there is no way to specify such a constraint and thus no way for the system to know that the UNION is updatable. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Thoughts about updateable views
Tom Lane wrote: Richard Huxton dev@archonet.com writes: There are two things (AFAICT) you need to be able to do to update (NOTE - not insert) a view. 1. Identify the underlying table(s) for the updated column(s) 2. Identify (primary) key values for the table(s) being updated. So - I could have a join listing users and how many email aliases they have (so sum()) and still update their name, so long as the key for the users table was present in the view. No; you'd also have to have some guarantee that a given underlying table row gives rise to at most one join row. If the same table row gives rise to multiple join rows, then a request specifying an UPDATE of just one of those join rows can't be satisfied. But you can't specify an update of a single row, only those where certain values match. Say you have a view user_email_vw with the following columns (from obvious tables): user_email_vw: u_id, u_name, e_id, e_address Updating the view WHERE u_id=123 may well update more than one row (where a user has multiple emails), but that's exactly equivalent to updating the user-table WHERE u_name = 'John Smith'. In the view (u_id) is not a key any more. If you have a many-many relationship, (say worker=department) then again you may update multiple rows in the view (WHERE dept_id=123), but so what - that's what you asked to do. I'm not saying this is always the behaviour you'd want. Imagine an address table where you have a country-code field and a lookup table of countries. I almost certainly DON'T want the lookup table updated via the view, but there's no easy solution to that - it's to do with the semantics of the join, not its syntax. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thoughts about updateable views
Richard Huxton dev@archonet.com writes: Tom Lane wrote: No; you'd also have to have some guarantee that a given underlying table row gives rise to at most one join row. If the same table row gives rise to multiple join rows, then a request specifying an UPDATE of just one of those join rows can't be satisfied. But you can't specify an update of a single row, only those where certain values match. Say you have a view user_email_vw with the following columns (from obvious tables): user_email_vw: u_id, u_name, e_id, e_address Updating the view WHERE u_id=123 may well update more than one row (where a user has multiple emails), but that's exactly equivalent to updating the user-table WHERE u_name = 'John Smith'. In the view (u_id) is not a key any more. Consider a request like UPDATE vw SET u_name = 'Joe' WHERE u_id = 123 AND e_id = 456; where u_id 123 links to multiple e_ids including 456. There is no way to update the underlying tables in such a way that only this row of the view changes. Therefore you can't sustain the illusion that the view is an updatable table. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Thoughts about updateable views
Tom Lane wrote: Richard Huxton dev@archonet.com writes: Yann Michel wrote: I think you mean UNION ALL, i.e. the set addition, don't you? Not if you can identify the underlying table(s) and key(s). If the UNION hides that information, then you are correct. If a unique key of the underlying table is included in the UNION data, then there can't be any duplicate rows and so the UNION really reduces to UNION ALL. However, I'm unconvinced that there are any cases like this that are interesting in practice. Consider CREATE TABLE a (id int primary key, ...); CREATE TABLE b (id int primary key, ...); CREATE VIEW v AS SELECT * FROM a UNION SELECT * FROM b; If a and b have disjoint key sets then the UNION is theoretically updatable, but there is no way to specify such a constraint and thus no way for the system to know that the UNION is updatable. What about: CREATE TABLE a(id int primary key check 100, ...) CREATE TABLE b(id int primary key check 100, ...) In any case, imagine a diary system where you might have an booking involving one or more people and/or resources (room/projector). You'd quite possibly have: SELECT 'P' as res_type, p_id, p_name FROM event_person UNION SELECT 'R', r_id, r_type FROM event_resource WHERE ... Again, updatable (although I'm not sure how you'd detect the implied CHECK on the first column). None of this is easy, or even practical but I'm fairly sure it's all possible. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Thoughts about updateable views
Tom Lane wrote: Richard Huxton dev@archonet.com writes: Tom Lane wrote: No; you'd also have to have some guarantee that a given underlying table row gives rise to at most one join row. If the same table row gives rise to multiple join rows, then a request specifying an UPDATE of just one of those join rows can't be satisfied. But you can't specify an update of a single row, only those where certain values match. Say you have a view user_email_vw with the following columns (from obvious tables): user_email_vw: u_id, u_name, e_id, e_address Updating the view WHERE u_id=123 may well update more than one row (where a user has multiple emails), but that's exactly equivalent to updating the user-table WHERE u_name = 'John Smith'. In the view (u_id) is not a key any more. Consider a request like UPDATE vw SET u_name = 'Joe' WHERE u_id = 123 AND e_id = 456; where u_id 123 links to multiple e_ids including 456. There is no way to update the underlying tables in such a way that only this row of the view changes. Therefore you can't sustain the illusion that the view is an updatable table. Agreed, but the reason we can't maintain the illusion that it's a simple table (i.e. plain CREATE TABLE) is that it's not. I might have a shelf_position column that, when I update it fires a trigger to renumber all the positions for that shelf. That breaks the illusion too. Perhaps a more common example. A column updated_ts that always gets set to now() regardless of supplied value. That's non-intuitive (or at least implicit) behaviour, but perfectly common (and reasonable, I'd argue). Now, on the client I'll grant we've got a problem unless we re-fetch after each update, or have some server-driven signalling. However, Microsoft have some sort of solution because their resultset-style model of the world in VB etc encounter this sort of thing. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Can't Restart ver 8.0b3
Bingo! Thanks Tom. -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 22, 2004 11:33 AM To: Dave Hartwig Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Can't Restart ver 8.0b3 Dave Hartwig [EMAIL PROTECTED] writes: LOG: next transaction ID: 884736; next OID: 306834 PANIC: could not access status of transaction 884736 DETAIL: could not read from file /usr/local/pgsql8b3/data/pg_clog/ at offset 221184: Success LOG: startup process (PID 17774) was terminated by signal 6 LOG: aborting startup due to startup process failure Hmm ... do we have a problem when the next XID is exactly at a page boundary? I'll look into that. LOG: next transaction ID: 1048576; next OID: 306834 PANIC: could not access status of transaction 1048576 DETAIL: could not open file /usr/local/pgsql8b3/data/pg_clog/0001: No such file or directory IIRC, pg_resetxlog doesn't have any provision to create new pg_clog segments. Which is probably an oversight, but it's easy enough to do it by hand. Do something like dd bs=8k count=1 /dev/zero /usr/local/pgsql8b3/data/pg_clog/0001 and everything should be fine. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Can't Restart ver 8.0b3
I wrote: Dave Hartwig [EMAIL PROTECTED] writes: LOG: next transaction ID: 884736; next OID: 306834 PANIC: could not access status of transaction 884736 DETAIL: could not read from file /usr/local/pgsql8b3/data/pg_clog/ at offset 221184: Success LOG: startup process (PID 17774) was terminated by signal 6 LOG: aborting startup due to startup process failure Hmm ... do we have a problem when the next XID is exactly at a page boundary? I'll look into that. Indeed, this is a bug I introduced into 8.0 awhile back :-(. Many thanks for the trouble report. IIRC, pg_resetxlog doesn't have any provision to create new pg_clog segments. Which is probably an oversight, but it's easy enough to do it by hand. Do something like dd bs=8k count=1 /dev/zero /usr/local/pgsql8b3/data/pg_clog/0001 and everything should be fine. There isn't any need to change pg_resetxlog, since the postmaster can handle creating new segments at need. But I'd modified StartupCLOG in a way that assumed the current clog page already exists, which is wrong in this boundary case. Fixed for RC3. In the meantime, creating an all-zeroes page as per the above suggestion should get you out of trouble. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Bgwriter behavior
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: So what are we doing for 8.0? Well, it looks like RC2 has already crashed and burned --- I can't imagine that Marc will let us release without an RC3 given what was committed today, never mind the btree bug that Mark Wong seems to have found. So maybe we should just bite the bullet and do something real about this. I'm willing to code up a proposed patch for the two-track idea I suggested, and if anyone else has a favorite maybe they could write something too. But do we have the resources to test such patches and make a decision in the next few days? At the moment my inclination is to sit on what we have. I've not seen any indication that 8.0 is really worse than earlier releases; the most you could argue against it is that it's not as much better as we hoped. That's not grounds to muck around at the RC3 stage. I remember the other difference between 8.0 and pre-8.0. When a backend has to write a block in 8.0, it does a write _plus_ fsync(), while in pre-8.0 it did only a write. There was a proposal to pass backend write information to the background writer so it would know to fsync at checkpoint, but it was decided that backend writing would be rare. I think we have to rethink that assumption. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Regression (semi)fix for netbsd-mac68k
Hi, One of the regression failure on NetBSD mac68k is float8 (see http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=ospreybr=HEAD). The failure is due to the fact the strtod does not underflow for +-10e-400. I see in src/test/regress/resultmap that NetBSD ix86 does not overflow either, and that that seems to be OK since there is a special result file for this platform so that the test passes. So a fix for NetBSD mac68k would be to special case it too... Patch: It should be possible to have one regexp for netbsd, but I did not figure how to write it --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.0 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.0 +0100 @@ -3,6 +3,7 @@ float8/i.86-.*-freebsd[234]=float8-small-is-zero float8/i.86-.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero +float8/m68k-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/i.86-pc-mingw32=float8-exp-three-digits-win32 float8/i.86-pc-cygwin=float8-small-is-zero Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Regression (semi)fix for netbsd-mac68k
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.0=20 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.0 +0100 @@ -3,6 +3,7 @@ float8/i.86-.*-freebsd[234]=float8-small-is-zero float8/i.86-.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero +float8/m68k-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/i.86-pc-mingw32=float8-exp-three-digits-win32 float8/i.86-pc-cygwin=float8-small-is-zero Looks reasonable to me --- why do you call it only a semi fix? I wonder whether we oughtn't remove the i.86- part from the patterns for the BSDen, ie, assume they will have this behavior on all hardware not just Intel. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Regression (semi)fix for netbsd-mac68k
Le 23 déc. 04, à 00:26, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: --- src/test/regress/resultmap.orig 2004-10-04 16:42:47.0=20 +0200 +++ src/test/regress/resultmap 2004-12-22 23:27:51.0 +0100 @@ -3,6 +3,7 @@ float8/i.86-.*-freebsd[234]=float8-small-is-zero float8/i.86-.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero +float8/m68k-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/i.86-pc-mingw32=float8-exp-three-digits-win32 float8/i.86-pc-cygwin=float8-small-is-zero Looks reasonable to me --- why do you call it only a semi fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod. So this is just accepting the bug, not correcting it :) I wonder whether we oughtn't remove the i.86- part from the patterns for the BSDen, ie, assume they will have this behavior on all hardware not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] RC2 and open issues
On Tue, 2004-12-21 at 15:26, Tom Lane wrote: Richard Huxton dev@archonet.com writes: However, one thing you can say is that if block B hasn't been written to since you last checked, then any blocks older than that haven't been written to either. [ itch... ] Can you? I don't recall exactly when a block gets pushed up the ARC list during a ReadBuffer/WriteBuffer cycle, but at the very least I'd have to say that this assumption is vulnerable to race conditions. An intriguing idea: after some thought this would only be true if all block accesses were writes. A block can be re-read (but not written), causing it to move to the MRU of T2, thus moving it ahead of other dirty buffers. Forgive me: the conveyor belt analogy only applies when blocks on the buffer list haven't been touched *at all*. i.e. if they are hit only once (on T1) or twice (T2) they then just move down towards the LRU and roll off when they get there. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Regression (semi)fix for netbsd-mac68k
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Le 23 d=E9c. 04, =E0 00:26, Tom Lane a =E9crit : Looks reasonable to me --- why do you call it only a semi fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod. So this is just accepting the bug, not correcting it :) Sure, but it's not our job to fix strtod(). Feel free to file a bug report with the NetBSD guys. I wonder whether we oughtn't remove the i.86- part from the patterns for the BSDen, ie, assume they will have this behavior on all hardware not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). OK, never mind that then. Patch applied as-is. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Regression (semi)fix for netbsd-mac68k
Le 23 déc. 04, à 04:52, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Le 23 d=E9c. 04, =E0 00:26, Tom Lane a =E9crit : Looks reasonable to me --- why do you call it only a semi fix Because strtod really should underflow, so there seems to be a bug in NetBSD's strtod. So this is just accepting the bug, not correcting it :) Sure, but it's not our job to fix strtod(). Feel free to file a bug report with the NetBSD guys. Of course. Will do. I wonder whether we oughtn't remove the i.86- part from the patterns for the BSDen, ie, assume they will have this behavior on all hardware not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). OK, never mind that then. Patch applied as-is. Cool, thanks ! Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
