Re: [HACKERS] Incremental Backup Script
On Sun, 2005-12-25 at 14:02 +0100, Gregor Zeitlinger wrote: as far as I have understood, the WAL backup that you control via archive_command is the PostgreSQL equivalent to what other databases let you do with an incremental backup No it is not an incremental backup of changed data blocks, it is a transactional log archival. So, other parts of your thinking are slightly off - but not by much. The only way to do a partial recovery is to follow the PITR notes. Best Regards, Simon Riggs ---(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] Fixing row comparison semantics
Alvaro Herrera wrote: Martijn van Oosterhout wrote: src/tools/make_ctags is your friend... That just shows you where a symbol is defined, not where it's called from. When you change the parameters of a function, you need to make sure you found all the places that used it... IOW, it's good for going down the call tree, but not up it. I use cscope for that. There is also id-utils, which is mentioned in our developer FAQ. That's what I use, but it is strictly command-line or 'edit all files with X', while I think glimpse and cscope are more like applications, though they probably have command-line interfaces too. -- 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 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] [Bizgres-general] WAL bypass for INSERT, UPDATE and
On Sat, 2005-12-24 at 10:32 -0500, Tom Lane wrote: An ALTER TABLE SET LOGGED/UNLOGGED switch might have some merit, but please don't muddy the waters by confusing this with temp-table status. I would not be against such a table-level switch, but the exact behaviour would need to be specified more closely before this became a TODO item, IMHO. If someone has a 100 GB table, they would not appreciate the table being truncated if a transaction to load 1 GB of data aborts, forcing recovery of the 100 GB table. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and
On Mon, Dec 26, 2005 at 12:03:27PM +, Simon Riggs wrote: I would not be against such a table-level switch, but the exact behaviour would need to be specified more closely before this became a TODO item, IMHO. Well, I think at a per table level is the only sensible level. If a table isn't logged, neither are the indexes. After an unclean shutdown the data could be anywhere between OK and rubbish, with no way of finding out which way. If someone has a 100 GB table, they would not appreciate the table being truncated if a transaction to load 1 GB of data aborts, forcing recovery of the 100 GB table. Ah, but wouldn't such a large table be partitioned in such a way that you could have the most recent partition having the loaded data. Personally, I think these shared temp tables have more applications than meet the eye. I've had systems with cache tables which could be wiped on boot. Though I think my preference would be to TRUNCATE rather than DROP on unclean shutdown. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgptUR80IVCyx.pgp Description: PGP signature
Re: [HACKERS] Fixing row comparison semantics
TODO updated: * %Make row-wise comparisons work per SQL spec Right now, '(a, b) (1, 2)' is processed as 'a 1 and b 2', but the SQL standard requires it to be processed as a column-by-column comparison, so the proper comparison is '(a 1) OR (a = 1 AND b 2)' Can we save current behave (with small modification) with other operator, like * (1,1) * (1,2) = true (1,2) * (2,1) is NULL (2,3) * (1,2) = false it's usefull for multicriterial optimalisation Regards Pavel Stehule _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Fixing row comparison semantics
On Mon, Dec 26, 2005 at 01:29:19PM +0100, Pavel Stehule wrote: Can we save current behave (with small modification) with other operator, like * (1,1) * (1,2) = true (1,2) * (2,1) is NULL (2,3) * (1,2) = false it's usefull for multicriterial optimalisation That's strange. That's not just doing less-than, but also distinguishing between equal-to and greater-than. So at the very least you've have to choose an operator like =. Seems to me you should just define your own operator on an array type and use that. I don't think the above could use an index scan for speeding it up so there's no point trying to treat it specially. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgplbfPH8OAZT.pgp Description: PGP signature
Re: [HACKERS] Fixing row comparison semantics
Martijn van Oosterhout kleptog@svana.org writes: If you want technical details I can do that too (the summary on pg-patches a while ago is now wildly out of date). Currently I'm trying to get up to speed on pathkeys and indexes before the tree drifts too far... I've given this advice before to other people: trying to develop a large patch in hiding is doomed to failure. And the sort of patch you are talking about isn't large ... it's massive. Combine that with the fact that you don't even seem to have gotten any pghackers buy-in yet on what you are doing, and you are setting yourself up to have the patch rejected, in the unlikely scenario that it's ever completed. My bet is that you by yourself will be unable to complete it, simply because the tree will drift under you faster than you can respond. (Case in point: my current project on row-wise comparisons is going to affect ScanKeys. I'm not sure how yet, but in designing that I won't be considering what impact it might have on you, because I have no idea what you might be trying to do in that area.) I would recommend posting some fairly detailed design discussions concerning what you see as the new semantics, API, and catalog representation for operators and operator classes. If you haven't got buy-in at that level from the hackers list, it's premature to be writing any code at all. I would further recommend that you ask for help rather than trying to complete the project by yourself. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] default resource limits
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane said: The existing initdb code actually does try to scale them in sync to some extent --- Yes, I know. What I meant was that we could try using one phase rather than two. But that's only one possible approach. I think that's a bad idea, mainly because max_connections is constrained by more things than just SHMMAX. In a scenario where the number of semaphores constrains max_connections, you'd probably end up failing to push shared_buffers up as high as it could be. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [Bizgres-general] WAL bypass for INSERT, UPDATE and
I think this brings up an interesting distinction, that having the NO LOGGING switch per command doesn't make sense because it modifying the table. It has to be a per-object switch, or something that operates only on empty tables. This is the exact same distinction we talked about for NO LOGGING COPY. --- Martijn van Oosterhout wrote: -- Start of PGP signed section. On Mon, Dec 26, 2005 at 12:03:27PM +, Simon Riggs wrote: I would not be against such a table-level switch, but the exact behaviour would need to be specified more closely before this became a TODO item, IMHO. Well, I think at a per table level is the only sensible level. If a table isn't logged, neither are the indexes. After an unclean shutdown the data could be anywhere between OK and rubbish, with no way of finding out which way. If someone has a 100 GB table, they would not appreciate the table being truncated if a transaction to load 1 GB of data aborts, forcing recovery of the 100 GB table. Ah, but wouldn't such a large table be partitioned in such a way that you could have the most recent partition having the loaded data. Personally, I think these shared temp tables have more applications than meet the eye. I've had systems with cache tables which could be wiped on boot. Though I think my preference would be to TRUNCATE rather than DROP on unclean shutdown. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. -- End of PGP section, PGP failed! -- 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 5: don't forget to increase your free space map settings
Re: [HACKERS] Fixing row comparison semantics
Pavel Stehule [EMAIL PROTECTED] writes: Right now, '(a, b) (1, 2)' is processed as 'a 1 and b 2', but the SQL standard requires it to be processed as a column-by-column comparison, so the proper comparison is '(a 1) OR (a = 1 AND b 2)' Can we save current behave (with small modification) with other operator, like * Huh? The only current behavior with other operators is failure: regression=# select (1,1) * (1,2); ERROR: operator * is not supported for row expressions In any case, you can get the equivalent of the current behavior by writing out 1 * 1 AND 1 * 2 so I don't see any strong need to support non-SQL-spec behaviors here. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] Improving missing FROM-clause entry message
I'm thinking about whether we can't improve the message for missing FROM-clause entry to somehow account for situations where the table does exist in the query but it's referenced from an improper place, as in bug #2130 (filed a couple hours ago, not yet visible in mail list archives): SELECT ... FROM a, b LEFT JOIN c ON (c.task_id=a.task_id ... This seems to come up often enough in porting MySQL code that we ought to try to deliver a more specific error message for it. We can fairly easily modify warnAutoRange() to check whether the target name exists anywhere in the ParseState's range table. This would not detect forward references, as in SELECT ... FROM b LEFT JOIN c ON (c.task_id=a.task_id ...), a ... but I think this is acceptable since that case isn't going to occur in ported MySQL code. What I'm wondering about is how to word the error message. A minimum-change approach would be to add a HINT, but I'm thinking it'd be better to replace the message entirely: ERROR: reference to table a is not allowed from this location HINT: JOIN clauses cannot refer to tables outside the JOIN Any thoughts about it? Are there any cases where the existing message wording is preferable even though a matching RTE does exist? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Improving missing FROM-clause entry message
I wrote: I'm thinking about whether we can't improve the message for missing FROM-clause entry to somehow account for situations where the table does exist in the query but it's referenced from an improper place, as in bug #2130 (filed a couple hours ago, not yet visible in mail list archives): SELECT ... FROM a, b LEFT JOIN c ON (c.task_id=a.task_id ... On further investigation, this is arguably a regression in 8.1. Every PG release back to 7.2 has responded to this query with NOTICE: adding missing FROM-clause entry for table a ERROR: JOIN/ON clause refers to a, which is not part of JOIN In 8.1, where add_missing_from defaults to false, you get the first line as an ERROR and so the much-more-useful specific message doesn't appear. I think we need to do something about this. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Online backup vs Continuous backup
I noticed that we are using the term Online Backup in our documentation when we are talking about continuous backup and PITR. To me, online backup is doing a backup while the system is online (online-backup), and that is accomplished by pg_dump. I know a lot of databases us Online Backup but I assume this is for historical reasons because at some time in the past their full backups didn't work while the database was online. Other systems use the term Continuous Logging, but I think that is too easily confused with the server activity logs. I suggest the following patch to rename our capability Continuous Backup. -- 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 Index: backup.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/backup.sgml,v retrieving revision 2.76 diff -c -r2.76 backup.sgml *** backup.sgml 7 Nov 2005 17:36:44 - 2.76 --- backup.sgml 26 Dec 2005 16:30:48 - *** *** 19,25 itemizedlist listitemparaacronymSQL/ dump/para/listitem listitemparaFile system level backup/para/listitem !listitemparaOn-line backup/para/listitem /itemizedlist Each has its own strengths and weaknesses. /para --- 19,25 itemizedlist listitemparaacronymSQL/ dump/para/listitem listitemparaFile system level backup/para/listitem !listitemparaContinuous backup/para/listitem /itemizedlist Each has its own strengths and weaknesses. /para *** *** 373,382 /sect1 sect1 id=backup-online ! titleOn-line backup and point-in-time recovery (PITR)/title indexterm zone=backup !primaryon-line backup/primary /indexterm indexterm zone=backup --- 373,382 /sect1 sect1 id=backup-online ! titleContinuous backup and point-in-time recovery (PITR)/title indexterm zone=backup !primarycontinuous backup/primary /indexterm indexterm zone=backup *** *** 452,458 /para para !To recover successfully using an on-line backup, you need a continuous sequence of archived WAL files that extends back at least as far as the start time of your backup. So to get started, you should set up and test your procedure for archiving WAL files emphasisbefore/ you take your --- 452,458 /para para !To recover successfully using a continuous backup, you need a continuous sequence of archived WAL files that extends back at least as far as the start time of your backup. So to get started, you should set up and test your procedure for archiving WAL files emphasisbefore/ you take your *** *** 782,793 functionpg_start_backup/ or functionpg_stop_backup/, and you will therefore be left to your own devices to keep track of which backup dump is which and how far back the associated WAL files go. ! It is generally better to follow the on-line backup procedure above. /para /sect2 sect2 id=backup-pitr-recovery !titleRecovering with an On-line Backup/title para Okay, the worst has happened and you need to recover from your backup. --- 782,793 functionpg_start_backup/ or functionpg_stop_backup/, and you will therefore be left to your own devices to keep track of which backup dump is which and how far back the associated WAL files go. ! It is generally better to follow the continuous backup procedure above. /para /sect2 sect2 id=backup-pitr-recovery !titleRecovering with a Continuous Backup/title para Okay, the worst has happened and you need to recover from your backup. *** *** 1123,1129 titleCaveats/title para ! At this writing, there are several limitations of the on-line backup technique. These will probably be fixed in future releases: itemizedlist --- 1123,1129 titleCaveats/title para ! At this writing, there are several limitations of the continuous backup technique. These will probably be fixed in future releases: itemizedlist ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] default resource limits
I wrote: Tom Lane said: I think this probably needs to be more aggressive though. In a situation of limited SHMMAX it's probably more important to keep shared_buffers as high as we can than to get a high max_connections. We could think about increasing the 5x multiplier, adding Min and/or Max limits, or some combination. Yes. If we were to base it on the current maxima (1000/100), we could use a factor of 10, or if on the maxima I am now proposing (4000/250) a factor of 16. Something in that range is about right I suspect. In experimenting I needed to set this at 20 for it to bite much. If we wanted to fine tune it I'd be inclined to say that we wanted 20*connections buffers for the first, say, 50 or 100 connections and 10 or 16 times for each connection over that. But that might be getting a little too clever - something we should leave to a specialised tuning tool. After all, we try these in fairly discrete jumps anyway. Maybe a simple factor around 20 would be sufficient. Leaving aside the question of max_connections, which seems to be the most controversial, is there any objection to the proposal to increase the settings tried for shared_buffers (up to 4000) and max_fsm_pages (up to 20) ? If not, I'll apply a patch for those changes shortly. cheers andrew ---(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] to_char and i18n
On Sun, 2005-12-25 at 17:56 -0300, Euler Taveira de Oliveira wrote:
--- Euler Taveira de Oliveira [EMAIL PROTECTED] escreveu:
I have a patch like this. But this was for 7.4.x. I have to take a
look
at it.
The patch is attached. It implements day and month i18n. I fixed a few
misspelling comments. Docs is attached too.
template1=# select to_char(now(), 'Day, DD Month ');
to_char
--
Sunday , 25 December 2005
(1 registro)
template1=# select to_char(now(), 'TMDay, DD TMMonth ');
to_char
---
Domingo, 25 Dezembro 2005
(1 registro)
template1=#
Comments?
I think it looks like a good patch. There's small problem that the
current to_char() output is possible use as argument for to_timestamp()
or to_date() function. It means you should implement vice-versa
conversion from string with TMMonth/TMDay to timestamp.
to_timestamp('Domingo, 25 Dezembro 2005', 'TMDay, DD TMMonth ')
Or.. at least describe in the docs that this way is unsupported
for 'TM' prefix.
Karel
--
Karel Zak [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
Bruce Momjian pgman@candle.pha.pa.us writes: I suggest the following patch to rename our capability Continuous Backup. This doesn't seem like an improvement. Online backup is the standard terminology AFAIK. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [DOCS] Online backup vs Continuous backup
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: I suggest the following patch to rename our capability Continuous Backup. This doesn't seem like an improvement. Online backup is the standard terminology AFAIK. But why is it the standard terminology? It doesn't seem logical. -- 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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] default resource limits
Andrew Dunstan [EMAIL PROTECTED] writes: In experimenting I needed to set this at 20 for it to bite much. If we wanted to fine tune it I'd be inclined to say that we wanted 20*connections buffers for the first, say, 50 or 100 connections and 10 or 16 times for each connection over that. But that might be getting a little too clever - something we should leave to a specialised tuning tool. After all, we try these in fairly discrete jumps anyway. Maybe a simple factor around 20 would be sufficient. I was thinking of a linear factor plus clamps to minimum and maximum values --- does that make it work any better? Leaving aside the question of max_connections, which seems to be the most controversial, is there any objection to the proposal to increase the settings tried for shared_buffers (up to 4000) and max_fsm_pages (up to 20) ? If not, I'll apply a patch for those changes shortly. You probably need to fix the max-connections pass so that it applies the same changes to max_fsm_pages as the second pass does --- otherwise, its assumption that shared_buffers can really be set that way will be wrong. Other than that I didn't see any problem with the shared_buffers part of the patch. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Online backup vs Continuous backup
Bruce Momjian wrote: I noticed that we are using the term Online Backup in our documentation when we are talking about continuous backup and PITR. To me, online backup is doing a backup while the system is online (online-backup), and that is accomplished by pg_dump. I know a lot of databases us Online Backup but I assume this is for historical reasons because at some time in the past their full backups didn't work while the database was online. Other systems use the term Continuous Logging, but I think that is too easily confused with the server activity logs. I suggest the following patch to rename our capability Continuous Backup. I have never heard the term Continuous backup. Although I have heard online backup. The problem is that when I hear the term online backup I think Hot backup which is what we do with pg_dump. I would just call the other Point in time recovery :) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [DOCS] [HACKERS] Online backup vs Continuous backup
Joshua D. Drake wrote: Bruce Momjian wrote: I noticed that we are using the term Online Backup in our documentation when we are talking about continuous backup and PITR. To me, online backup is doing a backup while the system is online (online-backup), and that is accomplished by pg_dump. I know a lot of databases us Online Backup but I assume this is for historical reasons because at some time in the past their full backups didn't work while the database was online. Other systems use the term Continuous Logging, but I think that is too easily confused with the server activity logs. I suggest the following patch to rename our capability Continuous Backup. I have never heard the term Continuous backup. Although I have heard online backup. The problem is that when I hear the term online backup I think Hot backup which is what we do with pg_dump. Yes, that is my problem too. I would just call the other Point in time recovery :) The problem there is that it is recovery, and the documentation talks about the backup step. I am thinking we are going to have to add something like Continuous backup, also called Online Backup or something like that. -- 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 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] [PATCHES] default resource limits
Tom Lane wrote: I was thinking of a linear factor plus clamps to minimum and maximum values --- does that make it work any better? Can you suggest some factor/clamp values? Obviously it would be reasonable to set the max clamp at the max shared_buffers size we would test in the next step, but I'm not sure I see a need for a minimum - all the factors I'm thinking of (or any factor above 10) would make us exceed our current minumum (100) in all cases anyway. You probably need to fix the max-connections pass so that it applies the same changes to max_fsm_pages as the second pass does --- otherwise, its assumption that shared_buffers can really be set that way will be wrong. Other than that I didn't see any problem with the shared_buffers part of the patch. OK, will do. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Fixing row comparison semantics
Huh? The only current behavior with other operators is failure: you didn't understand me. I know so operator * isn't supported now. I prefere SQL spec behave too. But what I wont: a * b ~ ai = bi and one ai bi = true ; if one ai bi = NULL; else false but this behave is from some views really chaotic. This comparation is used in operation research, but propably is far to ideas ANSI SQL. It was only idea. regression=# select (1,1) * (1,2); ERROR: operator * is not supported for row expressions In any case, you can get the equivalent of the current behavior by writing out 1 * 1 AND 1 * 2 so I don't see any strong need to support non-SQL-spec behaviors here. regards, tom lane _ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [DOCS] [HACKERS] Online backup vs Continuous backup
On Mon, 26 Dec 2005, Bruce Momjian wrote: Joshua D. Drake wrote: I have never heard the term Continuous backup. Although I have heard online backup. The problem is that when I hear the term online backup I think Hot backup which is what we do with pg_dump. Yes, that is my problem too. I would just call the other Point in time recovery :) The problem there is that it is recovery, and the documentation talks about the backup step. I am thinking we are going to have to add something like Continuous backup, also called Online Backup or something like that. FWIW, I believe log archival is a common term for that. - Heikki ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Fixing row comparison semantics
On 12/26/05, Pavel Stehule [EMAIL PROTECTED] wrote: (1,1) * (1,2) = true (1,2) * (2,1) is NULL (2,3) * (1,2) = false it's usefull for multicriterial optimalisation This is indeed a sane and useful function which should be adopted by the SQL standard.. in postgresql this would easily enough be implemented as a user function so I'm not sure we need special support for it. The idea is that in a multidimension comparison you can only sometimes say when one tuple is strictly less than (or greater than) another because differing dimensions are incomparable. So, like his example, we can not say if (1,2) is lesser or greater than (2,1) because saying so would require some priority of the dimensions which may not be known or may not exist, it is only clear that they are not equal.. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Pushing init scripts into contrib/
Hi, PostgreSQL source tree had init scripts in contrib/ years before: http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist I suggest to push the init scripts again into contrib/, for people who don'u use packaged versions and need init scripts. We could supply different scripts for different platforms, like the init scripts of our RPMs, init scripts of Debian, etc. Any objections? Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Pushing init scripts into contrib/
Devrim GUNDUZ [EMAIL PROTECTED] writes: PostgreSQL source tree had init scripts in contrib/ years before: http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist Aren't those dead versions of what's now in contrib/start-scripts/ ? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Pushing init scripts into contrib/
Devrim GUNDUZ wrote: Hi, PostgreSQL source tree had init scripts in contrib/ years before: http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist I suggest to push the init scripts again into contrib/, for people who don'u use packaged versions and need init scripts. We could supply different scripts for different platforms, like the init scripts of our RPMs, init scripts of Debian, etc. Any objections? There are too many versions of too many platforms to have to keep up with, IMNSHO. Might be a good pgfoundry project, just as the binary distros are. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Pushing init scripts into contrib/
There are too many versions of too many platforms to have to keep up with, IMNSHO. Might be a good pgfoundry project, just as the binary distros are. In general yes BUT it seems like a good idea to have: Linux FreeBSD MacOSX Solaris As though are the most popular platforms. Sincerely, Joshua D. Drake cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pushing init scripts into contrib/
Hi, On Mon, 26 Dec 2005, Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] writes: PostgreSQL source tree had init scripts in contrib/ years before: http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/linux/?hideattic=0#dirlist Aren't those dead versions of what's now in contrib/start-scripts/ ? Oh... I haven't seen start-scripts :( Thanks. -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Case Conversion Functions
Hi,
There're lots of places in the code which uses either pg_tolower()
or just tolower() - without aware of MB characters; or some
on-their-own implementations of pg_tolower(). (Actually, AFAIK,
whole MB case conversion is broken in -rHEAD.)
For instance, consider backend/utils/adt/{like.c, like_match.c}
file. Some lines of iwchareq() are a duplication of pg_tolower().
Another example:
backend/parser/scansup.c
152 else if (ch = 0x80 isupper(ch))
153 ch = tolower(ch);
Is this an intended behaviour or they're waiting for somebody to
clean them up.
Regards.
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Fixing row comparison semantics
Greetings to all, On Mon, Dec 26, 2005 at 10:04:59AM -0500, Tom Lane wrote: I would recommend posting some fairly detailed design discussions concerning what you see as the new semantics, API, and catalog representation for operators and operator classes. If you haven't got buy-in at that level from the hackers list, it's premature to be writing any code at all. Well, the problem works the other way around too. Unless you're familiar with postgres internals you can't talk sensebly about the changes required. Until two days ago I wasn't sure that my representation was sufficient for everything I wanted it to do. Anyway, the details posted before to -patches [1] and to -hackers [2] produced much discussion about locales but didn't consider the actual patch itself. I thought they were quite detailed and got exactly one useful reaction: don't confuse collations and locales. Good advice and the patch is better for it but I figured I needed to come up with something more substantial for people to take notice. Also, don't be confused about the time interval, there was zero development on it from September until a few days ago, the changes relative to then are not that large. Now I can (almost) initdb again and have no more catalog changes I was thinking of posting another patch with summary and see how far it gets this time. BTW, my stuff won't change how ScanKeys work, they'll probably just provide another way to initialise them. Have a nice day, [1] http://archives.postgresql.org/pgsql-patches/2005-09/msg00022.php [2] http://archives.postgresql.org/pgsql-hackers/2005-09/msg00110.php PS. The web archive for pg-patches seems to be lagging about 4 days at the moment. -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpXciz1jLdsS.pgp Description: PGP signature
Re: [HACKERS] [PATCHES] default resource limits
Tom Lane wrote:
Leaving aside the question of max_connections, which seems to be the
most controversial, is there any objection to the proposal to increase
the settings tried for shared_buffers (up to 4000) and max_fsm_pages (up
to 20) ? If not, I'll apply a patch for those changes shortly.
You probably need to fix the max-connections pass so that it applies the
same changes to max_fsm_pages as the second pass does --- otherwise, its
assumption that shared_buffers can really be set that way will be wrong.
Other than that I didn't see any problem with the shared_buffers part of
the patch.
revised patch attached, leaving max_connections alone except as above.
I'll apply this in a day or two, barring objection.
cheers
andrew
Index: src/bin/initdb/initdb.c
===
RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.101
diff -c -r1.101 initdb.c
*** src/bin/initdb/initdb.c 9 Dec 2005 15:51:14 - 1.101
--- src/bin/initdb/initdb.c 26 Dec 2005 22:44:09 -
***
*** 120,125
--- 120,126
/* defaults */
static int n_connections = 10;
static int n_buffers = 50;
+ static int n_fsm_pages = 2;
/*
* Warning messages for authentication methods
***
*** 1084,1089
--- 1085,1097
}
/*
+ * max_fsm_pages setting used in both the shared_buffers and max_connections
+ * tests.
+ */
+
+ #define TEST_FSM(x) ( (x) 1000 ? 50 * (x) : 2 )
+
+ /*
* check how many connections we can sustain
*/
static void
***
*** 1100,
for (i = 0; i len; i++)
{
snprintf(cmd, sizeof(cmd),
%s\%s\ -boot -x0 %s
-c shared_buffers=%d -c max_connections=%d template1
\%s\ \%s\ 21%s,
SYSTEMQUOTE, backend_exec, boot_options,
! conns[i] * 5, conns[i],
DEVNULL, DEVNULL, SYSTEMQUOTE);
status = system(cmd);
if (status == 0)
--- 1108,1124
for (i = 0; i len; i++)
{
+ int test_buffs = conns[i] * 5;
+ int test_max_fsm = TEST_FSM(test_buffs);
+
snprintf(cmd, sizeof(cmd),
%s\%s\ -boot -x0 %s
+ -c max_fsm_pages=%d
-c shared_buffers=%d -c max_connections=%d template1
\%s\ \%s\ 21%s,
SYSTEMQUOTE, backend_exec, boot_options,
! test_max_fsm,
! test_buffs, conns[i],
DEVNULL, DEVNULL, SYSTEMQUOTE);
status = system(cmd);
if (status == 0)
***
*** 1125,1146
test_buffers(void)
{
char cmd[MAXPGPATH];
! static const int bufs[] = {1000, 900, 800, 700, 600, 500,
! 400, 300, 200, 100, 50};
static const int len = sizeof(bufs) / sizeof(int);
int i,
! status;
! printf(_(selecting default shared_buffers ... ));
fflush(stdout);
for (i = 0; i len; i++)
{
snprintf(cmd, sizeof(cmd),
%s\%s\ -boot -x0 %s
-c shared_buffers=%d -c max_connections=%d template1
\%s\ \%s\ 21%s,
SYSTEMQUOTE, backend_exec, boot_options,
bufs[i], n_connections,
DEVNULL, DEVNULL, SYSTEMQUOTE);
status = system(cmd);
--- 1138,1167
test_buffers(void)
{
char cmd[MAXPGPATH];
! static const int bufs[] = {
! 4000, 3500, 3000, 2500, 2000, 1500,
! 1000, 900, 800, 700, 600, 500,
! 400, 300, 200, 100, 50
! };
static const int len = sizeof(bufs) / sizeof(int);
int i,
! status,
! test_max_fsm_pages;
! printf(_(selecting default shared_buffers/max_fsm_pages ... ));
fflush(stdout);
for (i = 0; i len; i++)
{
+ test_max_fsm_pages = TEST_FSM(bufs[i]);
+
snprintf(cmd, sizeof(cmd),
%s\%s\ -boot -x0 %s
+ -c max_fsm_pages=%d
-c shared_buffers=%d -c max_connections=%d template1
\%s\ \%s\ 21%s,
SYSTEMQUOTE, backend_exec, boot_options,
+ test_max_fsm_pages,
bufs[i], n_connections,
DEVNULL, DEVNULL, SYSTEMQUOTE);
status = system(cmd);
***
*** 1150,1157
if (i = len)
i = len - 1;
n_buffers = bufs[i];
! printf(%d\n, n_buffers);
}
/*
--- 1171,1179
if (i = len)
i = len - 1;
n_buffers = bufs[i];
+ n_fsm_pages = test_max_fsm_pages;
! printf(%d/%d\n, n_buffers, n_fsm_pages);
}
/*
***
*** 1177,1182
--- 1199,1207
snprintf(repltok, sizeof(repltok), shared_buffers = %d, n_buffers);
conflines = replace_token(conflines, #shared_buffers = 1000, repltok);
+ snprintf(repltok, sizeof(repltok), max_fsm_pages = %d, n_fsm_pages);
+ conflines = replace_token(conflines, #max_fsm_pages = 2, repltok);
+
#if DEF_PGPORT != 5432
snprintf(repltok, sizeof(repltok), #port = %d, DEF_PGPORT);
conflines = replace_token(conflines, #port = 5432, repltok);
---(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
Re: [HACKERS] Case Conversion Functions
Volkan YAZICI [EMAIL PROTECTED] writes: There're lots of places in the code which uses either pg_tolower() or just tolower() - without aware of MB characters; or some on-their-own implementations of pg_tolower(). (Actually, AFAIK, whole MB case conversion is broken in -rHEAD.) The upper/lower functions themselves work AFAIK, but I agree that stuff like ILIKE probably is broken for MB encodings. regex character classes need help too. Another example: backend/parser/scansup.c 152 else if (ch = 0x80 isupper(ch)) 153 ch = tolower(ch); Fooling with that is fairly risky --- we've been burnt before by locale-dependent case folding of SQL identifiers. In particular it'd be really bad if the folding could change on-the-fly at runtime. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
