I just had an interesting idea. It sounds too easy to beleve, but hear me out
and correct me if I'm wrong.
Currently, during update, PostgreSQL takes the existing record, modifyies it,
and adds it as a new row. The previous record has a pointer to the new version.
If the row is updated twice, the
Bruce Momjian wrote:
>
> Let me add people's expections of the optimizer and the "it isn't using
> the index" questions are getting very old. I have beefed up the FAQ
> item on this a month ago, but that hasn't reduced the number of
> questions. I almost want to require people to read a specifi
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > That is the difference, in another post Tom said he could not get
> > excited about 10.9 second execution time over a 7.96 execution
> > time. Damn!!! I would. That is wrong.
>
> Sure. Show us how to
Christopher Kings-Lynne wrote:
>
> > I have bitched about the index stuff for a while, and always have
> > bumped up
> > against this problem. If I can sway anyone's opinion, I would say, unless
> > (using Tom's words) a "factor of 2" planner difference against, I
> > would use an
> > index. Rath
Oliver Elphick wrote:
>
> On Wed, 2002-04-17 at 06:51, mlw wrote:
> > I just think there is sufficient evidence to suggest that if a DBA creates an
> > index, there is strong evidence (better than statistics) that the index need be
> > used. In the event that an index e
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > On borderline conditions, wrongly using an index does not result in as bad
> > performance as wrongly not using an index,
>
> You're arguing from a completely false premise. It might be true on the
>
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > ... I have seen many instances of when
> > PostgreSQL refuses to use an index because the data distribution is uneven.
>
> This is fixed, or at least attacked, in 7.2. Again, I do not see this
> as a
Andrew Sullivan wrote:
> Given the apparent infrequency of docs-consultation, I am
> considerably less sanguine than you are about the correctness of the
> choices many DBAs make. Poking at the planner to make it use an
> index more often strikes me as at least as likely to cause worse
> performa
Peter Eisentraut wrote:
>
> mlw writes:
>
> > Adding huristics, such as weighting for index scans, is not making the planner
> > stupider. It is making it smarter and more flexable.
>
> If life was as simple as index or no index then this might make some
> sens
Andrew Sullivan wrote:
> You haven't shown anything except a couple of anecdotal reports as
> evidence against his view. Anyone who asks you for more evidence
> gets treated to a remark that statistics won't do everything in this
> case.
I do not, currently, have access to systems which exhibi
Andrew Sullivan wrote:
> > Now, given the choice of the two strategies on a table, both pretty
> > close to one another, the risk of poor performance for using the
> > index scan is minimal based on the statistics, but the risk of poor
> > performance for using the sequential scan is quite high o
Bruce Momjian wrote:
>
> mlw wrote:
> > Now, given the choice of the two strategies on a table, both pretty close to
> > one another, the risk of poor performance for using the index scan is minimal
> > based on the statistics, but the risk of poor performance for using
Bruce Momjian wrote:
> My second point, that index scan is more risky than sequential scan, is
> outlined above. A sequential scan reads each page once, and uses the
> file system read-ahead code to prefetch the disk buffers. Index scans
> are random, and could easily re-read disk pages to plow
Bruce Momjian wrote:
>
> mlw wrote:
> > Bruce Momjian wrote:
> > >
> > > mlw wrote:
> > > > Now, given the choice of the two strategies on a table, both pretty close to
> > > > one another, the risk of poor performance for using the index sc
Bruce Momjian wrote:
>
> OK, yes, sequential scan _can_ be as slow as index scan, but sometimes
> it is faster. Can you provide reasoning why index scan should be
> preferred, other than the admin created it, which I already addressed?
If you have a choice between two or more sub-plans, simila
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > For instance: say we have two similarly performing plans, close to one another,
> > say within 20%, one plan uses an index, and one does not. It is unlikely that
> > the index plan will perform substantially
Tom Lane wrote:
> By and large this argument reminds me of the "compiler versus hand-
> programmed assembler" argument. Which was pretty much a dead issue
> when I was an undergrad, more years ago than I care to admit in a
> public forum. Yes, a competent programmer who's willing to work
> hard
Bruce Momjian wrote:
>
> mlw wrote:
> > I don't think we will agree, we have seen different behaviors, and our
> > experiences seem to conflict. This however does not mean that either of us is
> > in error, it just may mean that we use data with very different
>
Adrian 'Dagurashibanipal' von Bidder wrote:
>
> On Wed, 2002-04-17 at 19:43, Tom Lane wrote:
> > Hannu Krosing <[EMAIL PROTECTED]> writes:
> > > OTOH, it is also important where the file is on disk. As seen from disk
> > > speed test graphs on http://www.tomshardware.com , the speed difference
>
Lincoln Yeoh wrote:
>
> At 10:48 AM 4/18/02 -0400, mlw wrote:
> >Bruce Momjian wrote:
> > >
> > > Have you tried reducing 'random_page_cost' in postgresql.conf. That
> > > should solve most of your problems if you would like more index sca
Curt Sampson wrote:
>
> On Thu, 18 Apr 2002, Michael Loftis wrote:
>
> > mlw wrote:
> >
> > >The supposed advantage of a sequential read over an random read, in
> > >an active multitasking system, is a myth. If you are executing one
> > >query and
Curt Sampson wrote:
>
> On Tue, 23 Apr 2002, mlw wrote:
>
> > > On a system that has neither read-ahead nor sorting of I/O requests,
> > > yes. Which systems are you using that provide neither of these
> > > facilities?
> >
> > This only happens i
We have had several threads about index usage, specifically when PostgreSQL has
the choice of using one or not.
There seems to be a few points of view:
(1) The planner and statistics need to improve, so that erroneously using an
index (or not) happens less frequently or not at all.
(2) Use prog
I am going to compare a 16KB PostgreSQL system to an 8KB system. I am working
on the assumption that 16K takes about as long to read as 8K, and That the CPU
overhead of working with a 16K block is not too significant.
I know with toast, block size is no longer an issue, but 8K is not a lot these
Jean-Paul ARGUDO wrote:
>
> > I know with toast, block size is no longer an issue, but 8K is not a lot these
> > days, and it seems like a lot of syscall and block management overhead could be
> > reduced by doubling it. Any comments?
>
> IMHO, I think this would enhance performances only if tup
Bruce Momjian wrote:
> Now, with larger RAM and disk sizes, it may be time to consider larger
> page sizes, like 32k pages. That reduces the granularity of the cache,
> but it may have other performance advantages that would be worth it.
>
> What people are actually suggesting with the read-ahea
I have been doing some benchmarking. The idea is to measure the difference
between PostgreSQL 7.2.1 compiled for an 8K block or a 16K block. pgbench is
almost useless for measuring changes in performance, I can't seem to get any
real consistency, so I used the osdb to measure performance.
In the
Bruce Momjian wrote:
>
> Curt Sampson wrote:
> > On Thu, 25 Apr 2002, mlw wrote:
> >
> > > ...but my gut tells me that using 16K blocks will increase performance
> > > over 8K. Aleady I have seen a sequential scan of a large table go from 20
> > &g
This is a set of odd ball string operations for searching text.
strops.tar.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PR
Decode is a simple function inspired by Oracle's decode function, useful for
creating queries that work on both Oracle and PostgreSQL.
concat(...) concatinates multiple strings into one string.
decode.tar.gz
Description: GNU Zip compressed data
---(end of broadcast)---
Bruce Momjian wrote:
>
> Rod Taylor wrote:
> > > > There sure are a lot of arguments in the hackers list tho :) I do
> > wish
> > > > people would be a little less 'ad hominem' in their argument
> > styles,
> > > > however.
> > >
> > > Yes, things do get a little testy sometimes, and it does wor
[EMAIL PROTECTED] wrote:
>
> > mlw <[EMAIL PROTECTED]> writes:
> > > Just out of curiosity, does PostgreSQL have a mission statement?
>
> > Nope. Given the wide variety of views among the developer community,
> > I think we'd have a tough time agreei
> "[EMAIL PROTECTED]" wrote:
>
> Dear Team,
>
> I have been monitoring this list for quite some time now and have been
> studying PostGreSQL for a while. I also did some internet research on the
> subject of "multi valued" database theory. I know that this is the basis for
> the "Pick" databas
mlw wrote:
>
> > "[EMAIL PROTECTED]" wrote:
> >
> > Dear Team,
> >
> > I have been monitoring this list for quite some time now and have been
> > studying PostGreSQL for a while. I also did some internet research on the
> > subject of &
Jean-Michel POURE wrote:
>
> Le Jeudi 2 Mai 2002 01:59, David Terrell a écrit :
> > "Provide a really good database and have fun doing it"
>
> PostgreSQL Community is commited to providing Humanity with the best
> multi-purpose, reliable, open-source and free database system.
The PostgreSQL co
Jim Mercer wrote:
>
> On Thu, May 02, 2002 at 08:15:15AM -0400, mlw wrote:
> > Jean-Michel POURE wrote:
> > > Le Jeudi 2 Mai 2002 01:59, David Terrell a écrit :
> > > > "Provide a really good database and have fun doing it"
> > >
> > >
Jean-Michel POURE wrote:
>
> The PostgreSQL community is committed to creating and maintaining the best,
> most reliable, open-source multi-purpose standards based database, and with
> it, promote free(dom) and open source software world wide.
>
> I hope you don't mind writing "free(dom)" with t
"Marc G. Fournier" wrote:
> > BTW, I think PostgreSQL does _not_ need any mission statement.
>
> Nope, it doesn't ... never did before, don't know why it does suddenly ...
> do any other open source projects have one? Its kinda fun to see what ppl
> banter around, but I can't see it being usef
Mark kirkwood wrote:
>
> On Fri, 2002-05-03 at 04:25, mlw wrote:
>
> >
> > IMHO, if we can come up with a strong, positive statement, it would help MBA
> > trained CIOs and CTOs choose PostgreSQL. To them, it will show a professional
> > minded development group
Jim Mercer wrote:
>
> On Thu, May 02, 2002 at 08:41:30PM -0400, mlw wrote:
> > A mission statement is like a tie.
>
> straw vote!
>
> who on the list wears ties?
How many people who make IT decisions wear ties?
---(end of broadcast)-
Jim Mercer wrote:
>
> On Thu, May 02, 2002 at 09:14:03PM -0400, mlw wrote:
> > Jim Mercer wrote:
> > >
> > > On Thu, May 02, 2002 at 08:41:30PM -0400, mlw wrote:
> > > > A mission statement is like a tie.
> > >
> > > straw vote!
> &g
Jim Mercer wrote:
>
> On Thu, May 02, 2002 at 09:45:45PM -0400, mlw wrote:
> > Jim Mercer wrote:
> > > On Thu, May 02, 2002 at 09:14:03PM -0400, mlw wrote:
> > > > Jim Mercer wrote:
> > > > > On Thu, May 02, 2002 at 08:41:30PM -0400, mlw wrot
"Marc G. Fournier" wrote:
>
> Morning all ...
>
> Just a heads up that over the next little while, I'm planning on
> making a bunch of commits in order to work on making the code able to work
> natively in the above environments ... my work will mostly focus on Win32
> (since I have no O
Tom Lane wrote:
>
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > All I'm planning on doing is changing the appropriate shm_* functions iwth
> > pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
> > have in them is the original call we've always used ... there will even
"Marc G. Fournier" wrote:
>
> On Fri, 3 May 2002, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > > All I'm planning on doing is changing the appropriate shm_* functions iwth
> > > pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
> > > have in them
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > I think that you should create a verbatim implementation of the SysV
> > shared memory API in native Win32. It may have to be a pgsysvshm.dll
> > or something like it, but I think it is the best possible appr
sysv shm/sem
I am writing a Win32 DLL implementation of :
int semget(key_t key, int nsems, int semflg);
int semctl(int semid, int semnum, int cmd, union semun arg);
int semop(int semid, struct sembuf * sops, unsigned nsops);
int shmctl(int shmid, int cmd, struct shmid_ds *buf);
i
Like I told Marc, I don't care. You spec out what you want and I'll write it
for Windows.
That being said, a SysV IPC interface for native Windows would be kind of cool
to have.
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > I am writing a Win32 DLL im
Upon doing some inspection of apache 2.x, it seems that me making a SysV
Windows .DLL for PostgreSQL, while a cool project, would be unnecessary.
The APR (Apache Portable Runtime) seems to have all the necessary support. The
problem is that it has its own API.
We should find a way to extract the
Justin Clift wrote:
>
> mlw wrote:
> >
> > Upon doing some inspection of apache 2.x, it seems that me making a SysV
> > Windows .DLL for PostgreSQL, while a cool project, would be unnecessary.
> >
> > The APR (Apache Portable Runtime) seems to have all the n
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > Upon doing some inspection of apache 2.x, it seems that me making a SysV
> > Windows .DLL for PostgreSQL, while a cool project, would be unnecessary.
>
> > The APR (Apache Portable Runtime) seems
It is sunday morning and I have been musing about some PostgreSQL issues. As
some of you are aware, my dot com, dot died, and I am working on a business
plan for a consulting company which, amongst other things, will feature
PostgreSQL. As I am working on the various aspects, some issue pop up abo
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > [Index] --> [Target]->[LRU]->[1]->[2]->[3]->[MRU]
>
RE: http://archives.postgresql.org/pgsql-hackers/2002-05/msg00030.php
There are a few variations, but it seems I am making the same assumptions
Tom Lane wrote:
> No. For starters, we couldn't guarantee that insertion order is the
> same as transaction commit order. Even if we did, your assumption
> that commit order is the same as visibility is too simplistic. And
> none of this works if the index isn't unique.
Ahh, I get it, (again,
Tom Lane wrote:
>
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Well, I guess that just saved *me* alot of work ... thanks ...
>
> Uh, not yet. Don't you still need a semaphore implementation that
> works on Windows?
>
I have a LOT of experience with Windows development. You tell me wh
As I set out to do the Windows semaphore thing, I notice it can get quite ugly.
In the current CVS directory, there is pgsql/src/backend/port directory.
I propose that this become a separate subproject and library. The reason I want
this is because the semaphore support, specifically multiple se
Tom Lane wrote:
> BTW, I have been able to test the named-semas variant of posix_sema.c
> on OS X, and it works. I don't have access to any platforms that
> support unnamed POSIX semas, which is too bad because that seems much
> the preferable variant. Can anyone check it out?
I did, and yes I
Tom Lane wrote:
> And no, I don't want to undo those changes. Especially not if the
> only reason for it is to not have to use Cygwin on Windows. Most
> of these changes made the startup code substantially simpler,
> faster, and more reliable.
Then I think the notion of a pure Windows version i
[EMAIL PROTECTED] wrote:
>
> > I think, and I know people are probably sick of me spouting opinions,
> > that if you want a Windows presence for PostgreSQL, then we should
> > write a real Win32 version.
>
> The crucial wrong word is the word "we."
>
> If _you_ want a Windows presence, then _yo
Scott Marlowe wrote:
>
> There are some issues that the whole idea of a win32 port should bring up.
> One of them is whether or not postgresql should be rewritten as a
> multi-threaded app.
Perhaps.
>
> If postgresql will never be rewritten as a multi-threaded app, then
> performance under Win
[EMAIL PROTECTED] wrote:
>
> > [EMAIL PROTECTED] wrote:
> >>> I think, and I know people are probably sick of me spouting
> >>> opinions, that if you want a Windows presence for PostgreSQL, then
> >>> we should write a real Win32 version.
> >>
> >> The crucial wrong word is the word "we."
>
> >>
Hannu Krosing wrote:
>
> On Thu, 2002-05-09 at 22:36, mlw wrote:
> > Scott Marlowe wrote:
> > > note
> > > that many Unixes prefer multi-threaded models as well (Solaris comes to
> > > mind) so there's the possibility that a multi-threaded postgresql
Dann Corbit wrote:
> It took a few hundred man hours to do it. I see the whole Win32 port as
> a non issue. Several parties have already completed it (including the
> place where I work -- CONNX Solutions Inc.). If we did not do it or all
> parties who already did it were hit by a comet or some
Dann Corbit wrote:
> Our package avoids Cygwin altogether. We wrote our own POSIX layer from
> scratch, and we junked fork() for CreateProcess() {and inserted copious:
> #ifdef ICKY_WIN32_KLUDGE
> /* our code goes here */
> #else
> /* Standard UNIX code goes here */
> #endif
OK, what sorts of th
Dann Corbit wrote:
http://hp.vector.co.jp/authors/VA023283/PostgreSQLe.html
Mentions cygwin, am I misunderstanding?
Does not matter, the issue is that you guys said you did it. OK, have you been
able to bring the changed back into the main source tree? (Are you not trying?)
Dann Corbit wrote:
> I am not enrolled in the CVS project, and don't even know how to use it.
> We use "Visual Source Safe" here -- really an icky tool but at least
> everyone here knows it.
Source Safe? Yikes. I haven't used that in a long time.
>
> There is some debate here as to whether to k
Robert wrote:
>
> Hi,
>
> Win32 & threads support are both going to be a lot of work and maybe
> we'll need in the future one or both - is there any chance Postgres
> developers look at the Apache experience? Briefly, Apache 2 had the some
> problems as are discussed here (need to support Win,
Jean-Michel POURE wrote:
> > Without some buy-in from the core team, I'm not sure I am willing to spend
> > my time on it. If someone would be willing to fund the 100 or so man-hours
> > required to do it, then that would be a different story.
>
> I suggest we focuss on providing a minimal Postgr
Jean-Michel POURE wrote:
>
> Le Vendredi 10 Mai 2002 14:06, mlw a écrit :
> > Sorry, I'm not interested in a cygwin version of PostgreSQL. I think it
> > will do more harm than good. If we make it something that people want to
> > try, and then they TRY it, they wil
Jean-Michel POURE wrote:
>
> Dear Mark,
>
> Agreed except for paths (see below). But now that we agree, why not move to
> Windows in three steps:
> 1) Release a minimal Cygwin + PostgreSQL installer,
> 2) Have 100.000 downloads or more Windows developpers,
> 3) Work as a team on a Windows port.
Jean-Michel POURE wrote:
>
> Le Vendredi 10 Mai 2002 15:33, mlw a écrit :
> > The first time it doesn't work because of anti-virus software, they'll call
> > it junk. When they test performance and see that it sucks, they'll remove
> > the software.
>
&
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > Without some buy-in from the core team, I'm not sure I am willing to spend my
> > time on it. If someone would be willing to fund the 100 or so man-hours
> > required to do it, then that would be a differe
A binary version of PostgreSQL for Windows should not use the cygwin dll. I
know and understand there is some disagreement with this position, but in this
I'm sure about this.
The tools used to create the binary need not be Microsoft, many venders have
used Borland or Watcom, the run of the mill
Iavor Raytchev wrote:
>
> > If and when patches for pgaccess appear in significant numbers and for
> > some reason, which I cannot imagine, this procedure doesn't end up being
> > practical, we can consider the alternatives. But before you spend a lot
> > of time building a new infrastructure, l
"Marc G. Fournier" wrote:
>
> Mark (mlw) ... could you generate a listing of those variables you feel
> would need to be moved to a 'global structure' and post that to the list?
> That would at least give us a starting point, instead of both sides
> guessing a
Bruce Momjian wrote:
>
> mlw wrote:
> > Like I told Marc, I don't care. You spec out what you want and I'll write it
> > for Windows.
> >
> > That being said, a SysV IPC interface for native Windows would be kind of cool
> > to have.
>
> I a
Jason Tishler wrote:
>
> On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
> > Bruce Momjian wrote:
> > > mlw wrote:
> > > > Like I told Marc, I don't care. You spec out what you want and I'll write
> > > > it for Windows.
> >
Jason Tishler wrote:
>
> On Mon, Jun 03, 2002 at 09:36:51AM -0400, mlw wrote:
> > Jason Tishler wrote:
> > >
> > > On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
> > > > Bruce Momjian wrote:
> > > > > mlw wrote:
> > > &g
This built and worked on my system.
famous last words, huh?
Bruce Momjian wrote:
>
> Can someone address the intagg issue here, or is the code OK?
>
> ---
>
> Tom Lane wrote:
> > Joe Conway and I have just committed some
Greg Copeland wrote:
I've started playing a little with Postgres to determine if there were
memory leaks running around. After some very brief checking, I'm
starting[1] to think that the answer is yes. Has anyone already gone
through a significant effort to locate and eradicate memory leaks? I
I am working on getting a shrink-wrapped version of PostgreSQL for Windows
Currently it installs a customized version of Cygwin, PostgreSQL 7.2.3,
cygipc, psqlodbc, and pgadminII
I currently have the setup done.
The target audience is not the enterprise, it is aimed at people using
Access want
[EMAIL PROTECTED] wrote:
I've looked long and hard and can't find any license issues. Does anyone
know of any that I may have missed? As far as I can see, as long as I
maintain GPL restrictions, I should be fine.
PostgreSQL isn't licensed under the GPL, so it sounds to me as though you'
Dave Page wrote:
-Original Message-
From: mlw [mailto:[EMAIL PROTECTED]]
Sent: 03 December 2002 06:17
To: psqlodbc; [EMAIL PROTECTED]
Subject: [HACKERS] Shrinkwrap Windows Product, any issues? Anyone?
I am working on getting a shrink-wrapped version of
PostgreSQL for Windows
Hey this is a cool project. I have been thinking doing the exact ame thing,
the console Window of 2K/XP just kills the daemon, yuck.
What can I do to help?
Igor Georgiev wrote:
>I am working on getting a shrink-wrapped version of PostgreSQL
for Windows
>Currently it insta
Justin Clift wrote:
Igor Georgiev wrote:
I also be GLAD to read about plans for native windows port in 7.4.
If anyone is interested i can post source code, or maybe this firrst
steps can go to gborg as a separate project
i'm not sure yet.
Hi Igor,
This would be a really good thing to get
Justin Clift wrote:
Hi Igor,
This would be a really good thing to get into GBorg as a project, so
people could work on this through CVS.
Would you like to register it as a project?
Mark, do you feel it would be better to put your installer plus this
together into one project on GBorg too?
files, and the install
scripts I would be glad to post, and I would be very glad to include
Igor's console in the install.
It would make a cool offering.
Justin Clift wrote:
mlw wrote:
Once we do that, the we have the hook for more reliable and powerful
systems.
Yep, I pretty
Is there a way to get pg logging of plans to be produced in the terse
format like when a user types "explain select * from foo where bar = x"
The plan logging is very verbose. Having a lighter version of the
logging would be helpful in pinpointing troublesome queries without
slogging through pa
Peter Eisentraut wrote:
Marc G. Fournier writes:
It isn't, but those working on -advocacy were asked to help come up with a
stronger release *announcement* then we've had in the past ...
Consider that a failed experiment. PostgreSQL is driven by the
development group and, to some exten
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
How hard would it be to add a "WITH (VACUUM)" option to UPDATE and DELETE
queries? This option would cause the regular vacuum activity -- purging the
dead tuple and its index references -- to be done immediately, as part of the
state
Christopher Kings-Lynne wrote:
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?
I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the password to zeros after using it. There is a good
chance that the compiler
Greg Copeland wrote:
On Tue, 2002-12-17 at 10:49, mlw wrote:
Christopher Kings-Lynne wrote:
Hi guys,
Just a thought - do we explicitly wipe password strings from RAM after using
them?
I just read an article (by MS in fact) that illustrates a cute problem.
Imagine you memset the
Ken Hirsch wrote:
http://msdn.microsoft.com/library/en-us/dncode/html/secure10102002.asp
Well, OK, that isn't as bizarre as one could have expected.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
Devrim GUNDUZ <[EMAIL PROTECTED]> writes:
I had no time to search throug the code; but as far as I understood, it
*attacks* the database servers with TCP/IP on, right?
No, the program itself simply takes an MD5 hash value and does a
brute-force search f
Bruce Momjian wrote:
mlw wrote:
The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP
Tom Lane wrote:
Well, this is exactly the issue: someone would have to put substantial
amounts of time into update mechanisms and/or maintenance of obsolete
versions, as opposed to features, performance improvements, or bug
fixes.
Personally, I feel that if we weren't working as hard as we
Please no threading threads!!!
Has anyone calculated the interval and period of "PostgreSQL needs
threads" posts?
The *ONLY* advantage threading has over multiple processes is the time
and resources used in creating new processes.
That being said, I admit that creating a threaded program is ea
Hannu Krosing wrote:
I don't think the main issues are with file _formats_ but rather with
system file structures - AFAIK it is a fundamental design decision
(arguably a design flaw ;( ) that we use system tables straight from
page cache via C structure pointers, even though there seems to be a
Greg Copeland wrote:
On Fri, 2003-01-03 at 14:47, mlw wrote:
Please no threading threads!!!
Ya, I'm very pro threads but I've long since been sold on no threads for
PostgreSQL. AIO on the other hand... ;)
Your summary so accurately addresses the issue it should be a whole
Greg Copeland wrote:
Of course that gives up the hope of faster connection startup that has
always been touted as a major reason to want Postgres to be threaded...
regards, tom lane
Faster startup, should never be the primary reason as there are many
ways to addre
1 - 100 of 364 matches
Mail list logo
