Re: [PATCHES] postgresql in FreeBSD jails: proposal
[EMAIL PROTECTED] (Mischa Sandberg) writes: >Unfortunately, with multiple jails running PG servers and (due to app >limitations) all servers having same PGPORT, you get the situation that >when jail#2 (,jail#3,...) server comes up, it: >- detects that there is a shm seg with ipc key 5432001 >- checks whether the associated postmaster process exists (with kill -0) >- overwrites the segment created and being used by jail #1 Easiest fix: change the UID of the user running the postmaster (ie. pgsql) so that each runs as a distinct UID (instead of distinct PGPORT) ... been doing this since moving to FreeBSD 6.x ... no patches required ... -- ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am playing with this now ... sorry for delay ... - --On Wednesday, February 28, 2007 12:58:04 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: >> Joshua D. Drake wrote: >>> We should add this to the mailing list signup pages and the welcome >>> pages to the lists. > >> Yep, good idea. Marc? > > For -patches and -hackers, I agree. It seems a bit legalistic and > off-putting for the general lists, though. > > regards, tom lane > > ---(end of broadcast)------- > TIP 2: Don't 'kill -9' the postmaster - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFF7NK+4QvfyHIvDvMRAgmcAJ9SFJPqi1awtlsSPHYMskH0qEXSdACfblCC qODCB1vxRHBNwKj95pIOun4= =Asm5 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] reply to ...
'k, isn't the Reply-To header part of an RFC somewhere? Or is it really an optional thing for an MUA to follow? On Tue, 11 Jul 2006, Joshua D. Drake wrote: On Tuesday 11 July 2006 18:20, Marc G. Fournier wrote: checking ot make sure it works and gives the right answer ... Kmail ignores it ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(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
[PATCHES] reply to ...
checking ot make sure it works and gives the right answer ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Patch to readme
Is there a reason you didn't list the pl/PHP one? Seems appropriate for that list no? On Mon, 6 Feb 2006, Joshua D. Drake wrote: Attached is a patch to the README file to bring it a little more up to date with current PostgreSQL. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [BUGS] PSQL commands not backwards-compatible
On Tue, 30 Aug 2005, Tom Lane wrote: Bruce Momjian writes: Here is a patch that will print out (in interactive mode only) a warning message if a newer client connects to an older major numbered server. Why only older? It's even less likely to work if the server is newer. (I don't agree with the premise to begin with...) An example of where this sort of 'obvious warning' is in an environment like ours, where we have several different version of PostgreSQL running, and *try* to make sure each version of psql is available to our clients, but a client inadvertantly runs the wrong version against their database ... its only psql that has the "helper commands", like \d, so the only thing that *really* makes a different between versions ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] [BUGS] PSQL commands not backwards-compatible
Could this be back patched to the older versions as well? On Tue, 30 Aug 2005, Bruce Momjian wrote: Josh Berkus wrote: Tom, They've been broken on a fairly regular basis in past releases. Certainly 7.3 broke every single one because of the addition of schema syntax ... Yeah, and we warned people about it, as I recall. Also, we had about 25x less users then. I think we should put something in the release notes: WARNING: 8.1's "psql" is not completely backwards-compatible with previous versions of PostgreSQL. Here is a patch that will print out (in interactive mode only) a warning message if a newer client connects to an older major numbered server. -- 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 ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] dbsize backend integration
If dbsize is being moved from contrib to the backend, it should be moved in in its entirety ... On Tue, 21 Jun 2005, Bruce Momjian wrote: This version is being removed from the patches queue because it does not address how to handle existing dbsize functions not moved into the main server. --- Andreas Pflug wrote: As a start for a bunch of instrumentation functions that should be included in the backend as discussed previously, here are the dbsize functions. The dbsize.c file should go to the usual place, src/backend/utils/adt. Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- 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: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Bgwriter behavior
On Fri, 7 Jan 2005, Bruce Momjian wrote: Do we want to add this additional log infor to CVS for 8.0? No, unless we're looking for an RC5? --- Simon Riggs wrote: On Mon, 2005-01-03 at 19:14 -0500, Bruce Momjian wrote: Simon Riggs wrote: Here's my bgwriter instrumentation patch, which gives info that could allow the bgwriter settings to be tuned. Uh, what does this do exactly? Add additional logging output? Produces output like this... DEBUG:ARC T1target= 45 B1len= 4954 T1len= 40 T2len= 4960 B2len= 46 DEBUG:ARC total = 98% B1hit= 0% T1hit= 0% T2hit= 98% B2hit= 0% DEBUG:ARC buffer dirty misses= 22% (wasted=0); cleaned= 4494 when you have debug_shared_buffers (= n) set and you have server messages DEBUG1 available. The last line of log output has been replaced by this version. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Bgwriter behavior
On Mon, 3 Jan 2005, Bruce Momjian wrote: OK, we have a submitted patch that attempts to improve bgwriter by making bgwriter_percent control what percentage of the buffer is scanned. The patch still needs doc changes and a change to the default value but at this point we need a vote on the patch. Is it: * too late for 8.0 Too late by at least 3 RCs ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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: [PATCHES] [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
On Thu, 4 Nov 2004, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. Erk, yes, good point ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
On Thu, 4 Nov 2004, Alvaro Herrera wrote: On Thu, Nov 04, 2004 at 09:47:46AM -0500, Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Why not move it to src/tools, so no one gets the impression that it is user code? I thought about that earlier, but concluded it wasn't worth the loss of CVS history. why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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: [PATCHES] license cleanup
On Mon, 4 Oct 2004, Peter Eisentraut wrote:
Neil Conway wrote:
Attached is a patch that replaces src/port/{strtol.c,strtoul.c} with
versions derived from current NetBSD CVS sources, which has a
3-clause BSD license.
In my opinion, this is a completely pointless exercise in replacing
perfectly good code with code that we didn't know until today. Not
during beta please.
Oh good, I feared it was just me that thought that this seemed like a 'not
so good' idea :(
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] ALTER INDEX
On Fri, 20 Aug 2004, Bruce Momjian wrote: Patch applied. Thanks. I originally thought of this as a feature addition, but I realized that ALTER INDEX is being added because people are going to want to move tablespaces for indexes, and without this, they can't easily. Which would fall under adding a feature onto the tablespaces, not fixing a bug in tablespaces itself ... does *not* having ALTER INDEX *break* tablespaces? Causes it not to work, or not build? --- Gavin Sherry wrote: This patch has a fix for a 'thought-o' in the docs. Gavin Content-Description: [ Attachment, skipping... ] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Postgresql.conf Documentation change
On Mon, 16 Aug 2004, Josh Berkus wrote: Bruce, One issue is that the postgresql.conf file only gets installed as part of initdb so a shutdown/install/restart will replace the sample file, but the server file will retain comments until an initdb. This means some beta people might go into 8.0.0 final with comments, and some will not. I think there's a couple other patches that have the same effect (that is, initdb is required to take care of them). I think people using the beta should expect to re-build several times, anyway -- if they're not, they shouldn't use beta software. Actually, I agree with this, but from a different angle ... if testing beta, part of that testing is that an initdb does what is expected and doesn't generate any errors/problems ... when we go into RC mode, *then* things should be safe from an initdb, but beta shouldn't have that requirement ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] win32 readline
On Mon, 2 Aug 2004, Bruce Momjian wrote: Where are we on this? Right now readline is disabled on Win32. psql works fine for me. In fact it is more native because the delete key deletes, and control-d doesn't exit. I am inclined to leave the code unchanged and we can revisit this later after we figure out why readline doesn't work on some Win32 versions. Stupid question, but for Windows ... how many will actually use psql, vs something like PgAdmin? I'd say revisit it later myself ... it isn't critical to the operation of the server, only a 'luxury item' that we've all gotten used to being there :) --- Peter Eisentraut wrote: Magnus Hagander wrote: Just for reference, what features are we losing without readline. Tab completion, but what more? Command history, customizable key bindings, cut and paste, cursor keys come to mind. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 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 Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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: [PATCHES] Moving pg_autovacuum from contrib to src/bin
On Sat, 29 May 2004, Matthew T. O'Connor wrote: On Sat, 2004-05-29 at 11:04, Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: It is supposed to be linked into the postmaster and forked from there. In the current state of pg_autovacuum it wouldn't matter a lot, but I am assuming that we will soon migrate it to depend on being part of the postmaster environment. For instance, it ought to be configured from GUC, which will mean it has to receive SIGHUP from the postmaster. In an only slightly longer timeframe, it will probably want access to shared memory so it can look at stats maintained in the FSM. These attributes would make it quite inappropriate for autovacuum to live in src/bin. Ok. BTW, Matthew, I am currently working on promoting the bgwriter into a more full-fledged postmaster child. If you can wait a day or so you should have a decent model to work from. I'll try to commit as soon as a working skeleton is in place. I can wait, but I am really trying not to miss the feature freeze which AFAIK, is still happening in a few days. Is that changing? Will I have time if I wait a few days? Especially given that my backend hacking skill leave much to be desired. We're discussing it in core right now, but Tom's feel is that we can have PITR if we wait the extra month, which will also give a bit more time to hammer out any bugs in Win32 ... so figure on having the extra 4 weeks to work with ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [pgsql-hackers-win32] WIN32_DEV CVS branch
removed, and files from ftp have also been removed ... On Sat, 8 Nov 2003, Bruce Momjian wrote: > We are no longer using the WIN32_DEV CVS branch. We are doing all Win32 > work in HEAD now. I have already moved any WIN32_DEV changes up into > HEAD. I have updated the Win32 web page to indicate this: > > http://momjian.postgresql.org/main/writings/pgsql/win32.html > > Marc, would you remove the nightly generation of the win32 tarballs? > Thanks. I assume we can't remove the branch itself. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (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 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 > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Reorganization of spinlock defines
On Thu, 11 Sep 2003, Bruce Momjian wrote: > I just learned from Larry that Unixware defines intel as i386, not > __i386 or __i386__, at least of the native SCO compiler that he uses. could we put something in the various port files to standardize this? ie. in unixware.h, add somethinglike: #ifdef i386 #define __i386__ #endif just so that 'special cases' are centralized in the ports file, and the mainstream code doesn't have: #if defined(i386) || defined(__i386) || defined(__i386__) ? ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Reorganization of spinlock defines
On Thu, 11 Sep 2003, Bruce Momjian wrote: > Well, the problem was that we defined HAS_TEST_AND_SET inside the ports. > I guess we could splatter a test for Itanium and Opterion in every port > that could possibly use it, but then again, if we fall back to not > finding it for some reason, we don't get a report because we silently > fall back to semaphores. That's what has me worried, that if we don't > do it, we will not know what platforms really aren't working properly. >From what I understand, "not working properly" means slow, not broken, no? Which means ppl could submit a problem report and it could be fixed for v7.4.1 ... its not so much 'not working properly' as it is 'not optimal performance' ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Reorganization of spinlock defines
On Thu, 11 Sep 2003, Bruce Momjian wrote: > Yes, but to throw an error if spinlocks aren't found, we need this > patch. We would have to test for Opteron in all the platforms that test > for specific CPU's but don't test for opteron, and might support > opterion/itanium, but even then, we don't have any way of getting a > report of a failure. 'K, but apparently right now we are broken on Opteron/Itanium without this patch ... so, to fix, we either: a. add appropriate tests to the individual port files based on individual failure reports (albeit not clean, definitely safer), or: b. we do massive, sweeping changes to the whole HAVE_TEST_AND_SET detection code (definitely cleaner, but has potential of breaking more then it fixes) :( personally, as late in the cycle as we are, I think that a. is the wiser move for v7.4, with b. being something that should happen as soon as possible once we've branched and start working on v7.5 ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Reorganization of spinlock defines
On Thu, 11 Sep 2003, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > The problem with waiting for 7.5 is that we will have no error reporting > > when our non-spinlock code is being executed, and with Opteron/Itanium, > > it seems like a good time to get it working. > > Well, as long as you're prepared to reduce the list of known supported > platforms to zero as of 7.4beta3, and issue a fresh call for port reports. I didn't think we had done that yet ... had we? called for port reports, that is ... ? > But it seems to me that this is mostly a cosmetic cleanup and therefore > not the kind of thing to be doing late in beta. Couldn't we do > something that affects only Opteron/Itanium and doesn't take a chance > on breaking everything else? I just went through the whole patch myself, and as much as I like the overall simplification, I tend to agree with Tom here on questioning the requirement to do suck a massive change so late in the end cycle ... is there no smaller bandaid that can be applied to handle the Opteron/Itanium issue for v7.4, with the "cleanup patch" being applied right away after v7.4? ---(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
