Re: [HACKERS] pg_upgrade project: high-level design proposal of
On Sat, 4 Jun 2005, Bruce Momjian wrote: Date: Sat, 4 Jun 2005 19:33:40 -0400 (EDT) I have added a link to this thread on the TODO list under TODO.detail. Thanks Bruce (and Josh Berkus) for reminding me about this. I should be able to follow this up in early July. -s Serguei A. Mokhov wrote: Hello dear all, [Please CC your replies to me as I am on the digest mode] Here's finally a very high-level design proposal of the pg_upgrade feature I was handwaiving a couple of weeks ago. Since, I am almost done with the moving, I can allocate some time for this for 8.1/8.2. If this topic is of interest to you, please read on until the very end before flaming or bashing the ideas out. I had designed that thing and kept updating (the design) more or less regularly, and also reflected some issues from the nearby threads [1] and [2]. This design is very high-level at the moment and is not very detailed. I will need to figure out more stuff as I go and design some aspects in finer detail. I started to poke around asking for initdb-forcing code paths in [3], but got no response so far. But I guess if the general idea or, rather, ideas accepted I will insist on more information more aggressively :) if I can't figure something out for myself. [1] http://archives.postgresql.org/pgsql-hackers/2004-09/msg0.php [2] http://archives.postgresql.org/pgsql-hackers/2004-09/msg00382.php [3] http://archives.postgresql.org/pgsql-hackers/2004-08/msg01594.php Comments are very welcome, especially _*CONSTRUCTIVE*_... Thank you, and now sit back and read... CONTENTS: = 1. The Need 1. Utilities and User's View of the pg_upgrade Feature 2. Storage Management - Storage Managers and the smgr API 3. Source Code Maintenance Aspects 2. The Upgrade Sequence 4. Proposed Implementation Plan - initdb() API - upgrade API 1. The Need --- It's been a problem for PG for quite awhile now to have a less painful upgrade procedure with every new revision of PostgreSQL, so the dump/restore sequence is required. That can take a while for a production DB, while keeping it offline. The new replication-related solutions, such as Slony I, pg_pool, and others can remedy the problem somewhat, but require to roughly double the storage requirements of a given database while replicating from the older server to a newer one. The proposed implementation of an in-server pg_upgrade facility attempts to address both issues at the same time -- a possibility to keep the server running and upgrading lazily w/o doubling the storage requirements (there will be some extra disk space taken, but far from doubling the size). The in-process upgrade will not take much of down time and won't require that much memory/disk/network resources as replication solutions do. Prerequisites - Ideally, the (maybe not so anymore) ambitious goal is to simply be able to drop in the new binaries of the new server and kick off on the older version of data files. I think is this feasible now a lot more than before since we have those things available, which should ease up the implementation: - bgwriter - pg_autovacuum (the one to be integrated into the backend in 8.1) - smgr API for pluggable storage managers - initdb in C - ... initdb in C, bgwriter and pg_autovacuum, and pluggable storage manager have made the possibility of creation of the Upgrade Subsystem for PostgreSQL to be something more reasonable, complete, feasible, and sane to a point. Utilities and the User's (DBA) View of the Feature -- Two instances exist: pg_upgrade (in C) A standalone utility to upgrade the binary on-disk format from one version to another when the database is offline. We should always have this as an option. pg_upgrade will accept sub/super set of pg_dump(all)/pg_restore options that do not require a connection. I haven't thought through this in detail yet. pg_autoupgrade a postgres subprocess, modeled after bgwriter and pg_autovacuum daemons. This will work when the database system is running on old data directory, and lazily converting relations to the new format. pg_autoupgrade daemon can be triggered by the following events in addition to the lazy upgrade process: SQL level: UPGRADE ALL | relation_name [, relation_name] [NOW | time] While the database won't be offline running over older database files, SELECT/read-only queries would be allowed using older storage managers*. Any write operation on old data will act using write-invalidate approach that will force the upgrade the affected relations to the new format to be scheduled after the relation-in-progress. (* See the Storage Management
Re: [HACKERS] [pgsql-advocacy] Development Plans
Tom Lane wrote: I wouldn't mind seeing people be a little more vocal on the hackers list about what they plan to be doing, just so that there's not duplication of effort. pg_upgrade -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(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] Patent issues and 8.1
Hello all, With this paten issue on hand, can't we come up with a pluggable API and pluggable cache-replacement modules so that folks who care not for US patents can simply download and load in the PgARC module, and those who can't, just load the NeilLRU, or a BetterThanARCCacheReplacement module that don't violate those pattents. If the modules all conform to the same pg-cache-replacement API, they could be swapped on the fly. I believe the API and the two modules: ARC of Jan and LRU of Neil, can be implemented for 8.0.1 and be less invasive than just ARC yanked out and replaced with LRU. I believe, PGDG does not need to concern itself with removing and all traces of ARC from CVS or otherwise; on the conrary, it still can ship the ARC module as an add-on to those who wish. This is possible because the project is NOT hosted in the US (if I am wrong correct me). This idea will also help the commercial vendros of PG to write up their own modules they think best, of if they can't, just always load in LRU in their commerical deployments of PG in the US. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patent issues and 8.1
Hello all, As I got the next digest of pg hackers, I see that Jean-Gerard Pailloncy has already advocated this idea. In no means I meant to copy :) as I am on the digest mode. However, I think it's a good path to go anyway as two people at least came up with it. Please do not disregard this idea. -s On Wed, 26 Jan 2005, Serguei A. Mokhov wrote: Date: Wed, 26 Jan 2005 14:51:49 -0500 (EST) From: Serguei A. Mokhov [EMAIL PROTECTED] To: pgsql-hackers@postgresql.org Subject: Re: Patent issues and 8.1 Hello all, With this paten issue on hand, can't we come up with a pluggable API and pluggable cache-replacement modules so that folks who care not for US patents can simply download and load in the PgARC module, and those who can't, just load the NeilLRU, or a BetterThanARCCacheReplacement module that don't violate those pattents. If the modules all conform to the same pg-cache-replacement API, they could be swapped on the fly. I believe the API and the two modules: ARC of Jan and LRU of Neil, can be implemented for 8.0.1 and be less invasive than just ARC yanked out and replaced with LRU. I believe, PGDG does not need to concern itself with removing and all traces of ARC from CVS or otherwise; on the conrary, it still can ship the ARC module as an add-on to those who wish. This is possible because the project is NOT hosted in the US (if I am wrong correct me). This idea will also help the commercial vendros of PG to write up their own modules they think best, of if they can't, just always load in LRU in their commerical deployments of PG in the US. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [pgsql-hackers] Daily digest v1.4918 (23 messages)
On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: I have already suggested to core that we should insist on 8.1 not requiring an initdb, so as to ensure that people will migrate up to it easily from 8.0. So is it firm policy that changes that require a catversion update cannot be made during the 8.1 cycle? Not yet --- I suggested it but didn't get any yeas or nays. I don't feel this is solely core's decision anyway ... what do the assembled hackers think? (Needless to say, it would be good to get this sorted out early on in the 8.1 development cycle, to avoid the need to revert patches at some point down the line. For those of us working on large projects that will definitely require an initdb, it would also be good to know -- as this policy will likely prevent that work from getting into 8.1) Yes, it has to be decided one way or the other soon. One way to have our cake and eat it too would be for someone to resurrect pg_upgrade during this devel cycle. Anyone feel like working on that? Yup. I feel like working on that and not just feel as I been noising about it in the recent past. In fact I have opend a pgfoundry project for that exact work. regards, tom lane -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Final call for translation updates
On Tue, 4 Jan 2005, Peter Eisentraut wrote: With the 8.0 release around the corner, this is as good a time as ever to send in the last translation updates. If your files are not in CVS right now, I don't have them, so please send them again in this case. A batch of Russian translation updates is coming real soon now. I, with help from Oleg, am doing final polishing, spelling, and terminology fixes. I will send in the patches this Wed, Thu, maybe earlier. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] pg_upgrade project: high-level design proposal of in-place upgrade facility
()
mergeOldTemplates()
upgradeUsers()
upgradeSchemas()
- 7.2, else NULL
upgradeUserRelations()
upgradeIndices()
DROP/CREATE
upgradeInit()
{
}
The main body in pseudocode:
upgradeLoop()
{
moveData();
preliminaryRecovery();
preliminaryCleanup();
upgradeSystemInfo();
upgradeUsers();
upgradeSchemas();
upgradeUserRelations();
}
Something along these lines the API would be:
typedef struct t_upgrade
{
bool(*moveData) (void);
bool(*preliminaryRecovery) (void); /* may be NULL */
bool(*preliminaryCleanup) (void); /* may be NULL */
bool(*upgradeSystemInfo) (void);/* may be NULL */
bool(*upgradeUsers) (void); /* may be NULL */
bool(*upgradeSchemas) (void); /* may be NULL */
bool(*upgradeUserRelations) (void); /* may be NULL */
} t_upgrade;
The above sequence is executed by either pg_upgrade utility uninterrupted
or by the pg_autoupgrade daemon. In the former the upgrade priority is
simply by OID, in the latter also, but can be overridden by the user using
the UPGRADE command to schedule relations upgrade, write operation can
also change such schedule, with user's selected choice to be first. The
more write requests a relation receives while in the upgrade queue, its
priority increases; thus, the relation with most hits is on top. In case
of tie, OID is the decision mark.
Some issues to look into:
- catalog merger
- a crash in the middle of upgrade
- PITR logs for 8.x+
- ...
Flames and Handwaiving
--
Okay, flame is on, but before you flame, mind you, this is a very initial
version of the design. Some of the ideas may seem far fetched, the
contents may seem messy, but I believe it's now more doable than ever and
I am willing to put effort in it for the next release or two and then
maintain it afterwards. It's not going to be done in one shot maybe, but
incrementally, using input, feedback, and hints from you, guys.
Thank you for reading till this far :-) I.d like to hear from you if any
of this made sense to you.
Truly yours,
--
Serguei A. Mokhov| /~\The ASCII
Computer Science Department | \ / Ribbon Campaign
Concordia University | XAgainst HTML
Montreal, Quebec, Canada | / \ Email!
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_upgrade project: high-level design proposal of
On Thu, 30 Sep 2004, Tom Lane wrote: Date: Thu, 30 Sep 2004 16:36:02 -0400 Serguei A. Mokhov [EMAIL PROTECTED] writes: Comments are very welcome, especially _*CONSTRUCTIVE*_... This is fundamentally wrong, because you are assigning the storage manager functionality that it does not have. In particular, the Maybe, that's why I was asking of all init-db forcing paths, so I can go level above smgr to upgrade stuff, let say in access/ and other parts. I did ask that before and never got a reply. So the concept of Storage Managers may and will go well beyond the smgt API. That's the design refinement stage. I don't believe in the idea of incremental lazy upgrades very much either. It certainly will not work on the system catalogs --- you have to convert those in a big-bang fashion, I never proposed to do that to system catalogs, on the contrary, I said the system catalogs are to be upgraded upon the postmaster startup. only user relations are upgraded lazily: The relations to be upgraded are ordered according to some priority, e.g. system relations being first, then user-owned relations. System relations upgrade is forced upon the postmaster startup, and then user relations are processed lazily. So looks like we don't disagree here :) The design we'd pretty much all bought into six months ago involved being able to do in-place upgrades when the format/contents of user relations and indexes is not changing. All you'd have to do is dump and restore the schema data (system catalogs) which is a reasonably short process even on a large DB, so the big-bang nature of the conversion isn't a problem. Admittedly this will not work for every single upgrade, but we had agreed that we could schedule upgrades so that the majority of releases do not change user data. Historically that's been mostly true anyway, even without any deliberate attempt to group user-data-changing features together. Annoyingly enough, they still do change. I think the last major discussion about it started here: http://archives.postgresql.org/pgsql-hackers/2003-12/msg00379.php (I got distracted by other stuff and never did the promised work, but I still think the approach is sound.) I'll go over that discussion and maybe will combine useful ideas together. I'll open a pgfoundry project to develop it there and then will submit for evaluation UNLESS you reserved it for yourself, Tom, to fullfill the promise... If anybody objects the pgfoundry idea to test the concepts, I'll apply for a project there. Thank you for the comments! regards, tom lane -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Compiling from CVS: undefined reference to `PQparameterStatus'
Risking to report a dup (by being on digest), I report that I can't compile postgres from just CVS-checked out sources: gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o exec.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -Wl,-rpath,/usr/local/pgsql/lib -lpgport -lz -lreadline -ltermcap -lcrypt -lresolv -lnsl -ldl -lm -lbsd -o pg_dump pg_backup_db.o(.text+0x9f): In function `_check_database_version': : undefined reference to `PQparameterStatus' collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 make[3]: Leaving directory `/var/tmp/sam/pg/pgsql/src/bin/pg_dump' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/sam/pg/pgsql/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/sam/pg/pgsql/src' make: *** [all] Error 2 -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Compiling from CVS: undefined reference to
On Tue, 28 Sep 2004, Devrim GUNDUZ wrote: Date: Tue, 28 Sep 2004 00:21:32 +0300 (EEST) Hi, On Mon, 27 Sep 2004, Serguei A. Mokhov wrote: Risking to report a dup (by being on digest), I report that I can't compile postgres from just CVS-checked out sources: snip Just had a fresh checkout, but could not reproduce it on RHEL3, gcc 3.2.3. Maybe you were caught in the middle of an commit? Dunno. I then did cvs up -dP, make distclean, and then ./configure --enable-nls again two times and the problem is still there. Perhaps it'd be wise of me to report the OS and the compiler versions :) This is FC2 with gcc 3.3.2. .mokhov [pgsql] % gcc --version gcc (GCC) 3.3.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. .mokhov [pgsql] % uname -a Linux 2.6.8-1.521smp #1 SMP Mon Aug 16 09:25:06 EDT 2004 i686 i686 i386 GNU/Linux .mokhov [pgsql] % -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(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] Compiling from CVS: undefined reference to
On Mon, 27 Sep 2004, Bruce Momjian wrote: Date: Mon, 27 Sep 2004 17:13:32 -0400 (EDT) Serguei A. Mokhov wrote: Risking to report a dup (by being on digest), I report that I can't compile postgres from just CVS-checked out sources: : undefined reference to `PQparameterStatus' collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 make[3]: Leaving directory `/var/tmp/sam/pg/pgsql/src/bin/pg_dump' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/sam/pg/pgsql/src/bin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/sam/pg/pgsql/src' make: *** [all] Error 2 This is new. What OS are you using? FC2 with gcc 3.3.2, as per my reply to Devrim. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Compiling from CVS: undefined reference to
On Mon, 27 Sep 2004, Tom Lane wrote: Date: Mon, 27 Sep 2004 19:34:45 -0400 Serguei A. Mokhov [EMAIL PROTECTED] writes: pg_backup_db.o(.text+0x9f): In function `_check_database_version': : undefined reference to `PQparameterStatus' I'd say it is picking up a several-versions-back libpq.so from somewhere, but it's hard to tell where. Do you have anything already installed in /usr/local/pgsql/lib? What configure arguments did you use? The configure args were just --enable-nls, but it's irrelevant as your first guess is correct -- it picked up libpq.so of 7.3.6... in /usr/lib it is. I actually was not aware that the admin had postgres installed there, so I just went ahead and tried to compile a fresh checkout and got a bit puzzled the error and it did not occur to me to see if there was something already installed as the server is new. Sorry for the noise :( regards, tom lane -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Resurrecting pg_upgrade
On Wed, 1 Sep 2004, Richard Huxton wrote: Date: Wed, 01 Sep 2004 09:45:56 +0100 Serguei A. Mokhov wrote: Hello, Just poking around to see if anyone is working on resurrecting the concept of pg_upgrade after all these years? You probably want to join the (very recent) thread subject = version upgrade started by Andrew Rawnsley. Being on the digest mode I just came across it. Reading it doesn't give much more concrete stuff yet. I think I will finalize my design and post it then, but the reply to my original post with initdb-forcing code paths would be helpful anyway to all. Thanks for the reply though! -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(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
[HACKERS] version upgrade
Date: Tue, 31 Aug 2004 23:35:18 -0400 On 8/31/2004 9:38 PM, Andrew Rawnsley wrote: On Aug 31, 2004, at 6:23 PM, Marc G. Fournier wrote: On Tue, 31 Aug 2004, Josh Berkus wrote: Andrew, If I were loony enough to want to make an attempt at a version updater (i.e. migrate a 7.4 database to 8.0 without an initdb), any suggestions on where to poke first? Does a catalog/list of system catalog changes exist anywhere? Any really gross problems immediately present themselves? Is dusting off pg_upgrade a good place to start, or is that a dead end? Join the Slony project?Seriously, this is one of the uses of slony. All you'd need would be a script that would: I thought of this quite a bit when I was working over eRServer a while back. Its _better_ than a dump and restore, since you can keep the master up while the 'upgrade' is happening. But Mark is right - it can be quite problematic from an equivalent resource point of view. An in-place system (even a faux setup like pg_upgrade) would be easier to deal with in many situations. | There is something that you will not (or only under severe risk) get | with an in-place upgrade system. The ability to downgrade back in the | case, your QA missed a few gotchas. The application might not instantly | eat the data, but it might start to sputter and hobble here and there. | | With the Slony system, you not only switch over to the new version. But | you keep the old system as a slave. That means that if you discover 4 | hours after the upgrade that the new version bails out with errors on a | lot of queries from the application, you have the chance to switch back | to the old version and have lost no single committed transaction. Just asking: how far back in time Slony can downgrade or keep the older servers in slavery? 6.5? I haven't tried it yet, hence, the question. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Resurrecting pg_upgrade
Hello, Just poking around to see if anyone is working on resurrecting the concept of pg_upgrade after all these years? If not, I think I have nearly ready a high-level design of how the whole upgrade procedure will work, but I just need to clear out some ideas and put them together in a more-or-less coherent way. If nobody's working on the feature, I'd like to tackle it for 8.1/8.2 after having the design approved by the community. To clarify some of these, I would like to identify the codepaths, more generally -- directories with the code that, if changed, forces initdb. I'd assume these would fall into this category: src/backend /storage /smgr * /access /bootstrap /catalog /commands If you have time, please make the list above more complete or remove extraneous items. Please Cc to me as I am on the digest on most pg lists. Thank you, -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Typo in a comment in initdb.c
Hello, This comment in initdb.c::main(): char *pgdenv; /* PGDATA value got from sent to * environment */ doesn't look very correct, not at least from the English language perspective. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(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] Missing French backend translations in the HEAD
On Tue, 10 Aug 2004, Peter Eisentraut wrote: Date: Tue, 10 Aug 2004 20:51:52 +0200 Serguei A. Mokhov wrote: backend/po/fr.po had 99% translations done for 7.4, and nos it is totally missing for the current CVS tip (it is in the Attic)... why? Most of those messasge are still applicable to the current, no? Commit message from you from 2 weeks ago says: The file has only ever existed in the 7.4 branch, because it was submitted as postgres-7.4.po.bz2. So? It is still valid in most part for 8.0. The parts that are not, won't do any bad. I think the log messages are a CVS artifact. If Guillaume wants, I can also put the 7.4 PO file in the head branch. I was surpirsed not finding it there, actually, when everything else is there. I need sometimes the French localized messages, that's why I brought it up. Guillaume? (BTW, does a fr_CA version of it have a chance of being accepted? French here (in Canada) is still a bit different with its own specifics. Spelling-wise, the most notable difference is having CAPS with accents where fr_FR normally doesn't have (for corresponding lowercase accented letters) and spacing. Maybe a bit of terminology as well, but I don't have an example handy). Of course, you can start making an argument of then should we create en_BR, pt, es_MX, etc, but.. any comment?). -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(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
[HACKERS] Beta Page on Developer's site is out of date
Maybe this should be brought up-to-date slightly? http://developer.postgresql.org/beta.php Or maybe point elsewhere at least where the more up-to-date info actually is. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Missing French backend translations in the HEAD
Hello Peter, backend/po/fr.po had 99% translations done for 7.4, and nos it is totally missing for the current CVS tip (it is in the Attic)... why? Most of those messasge are still applicable to the current, no? Commit message from you from 2 weeks ago says: 2 weeks petere branches: 1.1.2; file fr.po was initially added on branch REL7_4_STABLE. http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/po/Attic/ I don't understad it and the reasons for the file to be removed. As a consequence it is also missing in the current translation status table. -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Dead cvsweb link
On the developer's page: http://developer.postgresql.org/ CVSWeb link points to: http://developer.postgresql.org/cvsweb.cgi/pgsql-server which is incorrect. The same for interfaces... -- Serguei A. Mokhov| /~\The ASCII Computer Science Department | \ / Ribbon Campaign Concordia University | XAgainst HTML Montreal, Quebec, Canada | / \ Email! ---(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] Multibyte support in oracle_compat.c
On Thu, 5 Sep 2002, Peter Eisentraut wrote: Date: Thu, 5 Sep 2002 00:46:39 +0200 (CEST) From: Peter Eisentraut [EMAIL PROTECTED] To: Tatsuo Ishii [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [HACKERS] Multibyte support in oracle_compat.c Tatsuo Ishii writes: Functions upper,lower and initcap doesn't work with utf-8 data The backend routines use the host OS locales, so look there. On my machine I have several Russian locales, which seem to address the issue of character sets: ru_RU ru_RU.koi8r ru_RU.utf8 ru_UA russian Yeah, our character sets is a major pain for internatianlization. And the above list is not exhaustive. I guess you are right, for the time being you'll have to bear with it. -s ---(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] Memory management question
Maybe when this thread is over, some parts of it can be added to the dev. FAQ? -s On Tue, 3 Sep 2002, Karel Zak wrote: Date: Tue, 3 Sep 2002 13:52:09 +0200 From: Karel Zak [EMAIL PROTECTED] To: Nigel J. Andrews [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] Memory management question On Tue, Sep 03, 2002 at 12:28:37PM +0100, Nigel J. Andrews wrote: It's probably a pretty basic question explained in some document I haven't seen but...if I do something like a CreateTupleDescCopy() how do I know my memory context owns everything allocated without following the code all the way through until it returns to me? If some code doesn't call MemoryContextSwitchTo() all is allocated in current memory context. You can check if CurrentMemoryContext is same before and after call that is important for you - but this check say nothing, bacuse some code can switch to other context and after usage switch back to your context. IMHO is not common way how check it. (Ok, maybe check all contexts size before/after call...) Suggestion: add to memory managment counter that handle number of MemoryContextSwitchTo() calls. IMHO it can be compile only if MEMORY_CONTEXT_CHECKING is define. But I think there is not to much places which switching between contexts and all are good commented (I hope, I wish :-) Karel ---(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] I am done
On Mon, 2 Sep 2002, Tom Lane wrote: Date: Mon, 02 Sep 2002 10:33:49 -0400 From: Tom Lane [EMAIL PROTECTED] To: Christopher Kings-Lynne [EMAIL PROTECTED] Cc: Bruce Momjian [EMAIL PROTECTED], PostgreSQL-development [EMAIL PROTECTED] Subject: Re: [HACKERS] I am done Christopher Kings-Lynne [EMAIL PROTECTED] writes: You can probably nail some TODOs: Maybe add a TODO item: * fix a possibility of DoS attacks in the backend before the user is authenticated ? Since I guess my patch for that is too late and I don't even know if it's any good approach at all. -s ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
