Bruno Wolff III wrote:
On Thu, Apr 03, 2003 at 13:26:01 -0500,
[EMAIL PROTECTED] wrote:
I don't know that it meets your criteria, but.
I have a set of scripts and a program that will load the US Census TigerUA
database into PostgreSQL. The thing is absolutely freak'n huge. I forget
whic
Jan Wieck wrote:
"Marc G. Fournier" wrote:
On Wed, 2 Apr 2003, scott.marlowe wrote:
If that is a real objective, I'm surprised.
The base source tree has always been as BSD pure as we can make it ... its
never been kept a secret ...
True. But not linking to LGPLd libs
Tom Lane wrote:
On other Unixoid systems you can link against BSD-license libc code, or
some-random-proprietary-license code from HP or Sun or whomever. glibc
doesn't have a monopoly in that sphere. But mlw is offering code that
will *only* run against a single implementation that is
Hannu Krosing wrote:
[EMAIL PROTECTED] kirjutas N, 03.04.2003 kell 02:01:
mlw wrote:
I think you are interpreting the spec a bit too restrictively. The
syntax is fairly rigid, but the spec has a great degree of flexibility.
I agree that, syntactically, it must work through a parser
Hannu Krosing wrote:
mlw kirjutas K, 02.04.2003 kell 15:56:
Hannu Krosing wrote:
What you have come up with _is_not_ a SOAP v1.1 message at all. It does
use some elements with similar names but from different namespace.
the SOAP Envelope, Header and Body elemants must be from namespace
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.
My SOAP/XML function will probably require my LGPL library as there is a
lot of
Hannu Krosing wrote:
mlw kirjutas T, 01.04.2003 kell 15:29:
Hannu Krosing wrote:
[EMAIL PROTECTED] kirjutas E, 31.03.2003 kell 19:52:
Actually, as far as I am aware, the header is for metadata, i.e. it is the
place to describe the data being returned.
Did you read
cords has very little
affect on efficiency. I think the table2xml function is great for 99% of
all the queries, but for those huge resultsets, I think it may be
problematic.
What do you think?
BTW, I routinely have queries that return millions of rows.
Peter Eisentraut wrote:
mlw writes:
Gi
I know nothing in contrib should be GPL, I have no problem with that.
The question is the requirement of a GPL library to build a contrib project.
My SOAP/XML function will probably require my LGPL library as there is a
lot of code I have written that I would need to implement it.
Is there any
Hannu Krosing wrote:
[EMAIL PROTECTED] kirjutas E, 31.03.2003 kell 19:52:
Actually, as far as I am aware, the header is for metadata, i.e. it is the
place to describe the data being returned.
Did you read the SOAP spec ?
yes
The description of the fields
isn't the actual data retrie
A
203429573
1
203429573
177516
1
1
Papa Was A Rolling Stone
10411
P
2
1
2
Steve Wampler wrote:
On Fri, 2003-03-28 at 14:39, mlw wrote:
I was thinking of using SOAP over HTTP as the protocol, and a
minimalist version at b
g better than SOAP." It still stands that a SOAP
interface would be useful for people.
On Fri, Mar 28, 2003 at 09:01:08AM -0500, mlw wrote:
I have been working on moving some of my software to a more SOAP
compatible interface. As I was doing it, it occured to me that a generic
functi
I have been working on moving some of my software to a more SOAP
compatible interface. As I was doing it, it occured to me that a generic
function could be written, in PostgreSQL's new function manager that
allows multiple columns to be returned, that is a generic SOAP interface.
All one would
I was at a client office reviewing some code. They use MSSQL and I
noticed that:
select * from table where field = 'blah';
gave the same results as:
select * from table where field = 'BLah';
I was shocked. (a) because I know a lot of my code could be easier to
write, and (b) that their code woul
Justin Clift wrote:
Hi everyone,
Thinking about the numbering further.
Would it be cool to decide on the version numbering of our next
release like this:
+ If it looks like we'll have Win32 and/or PITR recovery in time for
the next release, we call it PostgreSQL 8.0
+ If not, we call it
I haven't been able to get to it all morning.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
I read your post, and I am struck by a few things, I am not sure I will
answer all your points, but maybe a discussion is in order.
I use PostgreSQL with C++ all the time. I actually have a SQL class that
abstracts libpq and ODBC, so I'm pretty much past a lot of the "how I
want to use it" stuf
Merlin Moncure wrote:
-Original Message-
From: mlw [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 05, 2003 3:47 PM
To: [EMAIL PROTECTED]
Subject: [HACKERS] Aggregate "rollup"
I had written a piece of code about two years ago that used the
aggregate feature of PostgreSQL to
I had written a piece of code about two years ago that used the
aggregate feature of PostgreSQL to create an array of integers from an
aggregate, as:
select int_array_aggregate( column ) from table group by column
While it seems pointless to create an array on a select, it has a
purpose in OLA
The idea of a RAM disk based database and reliable storage are in
complete opposition. Forget it.
The question is: What do you need the *raw* speed of a RAM disk for, and
what can you tollerate for overhead for reliability?
You have posed a question about how to implement a flawed solution, wha
D'Arcy J.M. Cain wrote:
On Thursday 27 February 2003 13:12, mlw wrote:
Tom Lane wrote:
A single ANALYZE at the end of the script would be sufficient. I'm not
sure that pg_dump should do this automatically though. If you're not
done restoring then it's mostly a wast
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
Should pg_dump appened an ANALYZE for each table?
A single ANALYZE at the end of the script would be sufficient. I'm not
sure that pg_dump should do this automatically though. If you're not
done restoring then it
I just dumped and restored a rather large database, I upgraded from
7.2.x to 7.3.x. When I went to test my application against the new
database, it was dog slow. It had all the indexes, and looked fine.
Then it dawned on me, Doh! ANALYZE!
Should pg_dump appened an ANALYZE for each table?
On sm
I don't understand why you would want to remove a working feature. Even
if they are features which you do not like, why remove them? One of the
things about the PostgreSQL core team that troubles me is a fairly
arbitrary feature selection process.
It seems a feature has to be "liked" by someone
I am not familiar with ILIKE, but I suspect that if people are moving
from a platfrom on which it exists, or even creatingmulti-platform
applications, there may be a substancial amount of code that may use it.
Peter Eisentraut wrote:
AFAICT, ILIKE cannot use an index. So why does ILIKE even ex
Bruce Momjian wrote:
mlw wrote:
I raised the possibility of moving the pid file only last week. Tom
pointed out that it acts as a lock on the database to prevent two
postmasters' trying to manage the same database. As such it should NOT
be a configurable parameter.
This
Oliver Elphick wrote:
On Wed, 2003-02-19 at 02:43, mlw wrote:
PostgreSQL Extended Configuration Patch
...
--- Run-time process ID ---
postmaster -R /var/run/postmaster.pid
This will direct PostgreSQL to write its process ID number
to a file, /var/run/postgresql.conf
:B:b:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) != -1)
+ while ((opt = getopt(argc, argv, "A:a:B:b:C:c:D:d:Fh:ik:lm:MN:no:p:R:Ss-:"))
!= -1)
{
switch (opt)
{
@@ -441,6 +442,9 @@
:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) != -1)
+ while ((opt = getopt(argc, argv, "A:a:B:b:C:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) !=
+-1)
{
switch (opt)
{
@@ -441,6 +441,9 @@
case 'b':
/* Can
Bruce Momjian wrote:
mlw wrote:
I don't like the idea of specifying a directory, per se' because if you
have multiple database installations, how would you share the
configuration without symlinks?
Oh, for example, you would be sharing postgresql.conf, perhaps, but not
p
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
If no hba_conf and/or ident_conf setting is specified, the default
$PGDATA/pg_hba.conf and/or $PGDATA/pg_ident.conf will be used.
Doesn't anybody see the (a) inconsistency and (b) uselessness of this?
If you are trying to keep
t;A:a:B:b:C:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) !=
+-1)
{
switch (opt)
{
@@ -441,6 +441,9 @@
case 'b':
/* Can no longer set the backend executable file to
use. */
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
The idea of using a "directory" puts us back to using symlinks to share
files.
So? If you want to share files, you're probably sharing all three
config files and don't need a separate directory at all.
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Tom Lane writes:
I would favor a setup that allows a -C *directory* (not file) to be
specified as a postmaster parameter separately from the -D directory;
A directory is not going to satisfy people.
Why not?
Martin Coxall wrote:
On Thu, 2003-02-13 at 20:28, Steve Crawford wrote:
I don't see why we can't keep everyone happy and let the users choose the
setup they want. To wit, make the following, probably simple, changes:
1) Have postgresql default to using /etc/postgresql.conf
/etc/postg
Robert Treat wrote:
Seems like some are saying one of the problems with the current system
is it doesn't follow FHS or LSB. If those are valid reasons to change
the system, it seems like a change which doesn't actually address those
concerns would not be acceptable. (Unless those really aren't
One of the things that I HATE about this discussion is that everyone
wants to put limits on configurability.
I am an old fashion UNIX guy, capability without enforcing policy!
Adding an ability is different than enforcing a policy. All I any to do
is add the capability of configuration in a way
s-:")) != -1)
+ while ((opt = getopt(argc, argv, "A:a:B:b:C:c:D:d:Fh:ik:lm:MN:no:p:Ss-:")) !=
+-1)
{
switch (opt)
{
@@ -441,6 +441,9 @@
case 'b':
/* Can no longer set the backend e
Robert Treat wrote:
On Thu, 2003-02-13 at 14:51, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra
Bruce Momjian wrote:
Robert Treat wrote:
IIRC the postmaster.pid file should be in /var/run according to FHS, I'm
not sure about postmaster.opts though...
Again, if we're going to make a change, let's make sure we think it
through.
Can non-root write to /var/run?
scott.marlowe wrote:
These are not issues at all. You could put the configuration file
anywhere, just as you can for any UNIX service.
postmaster --config=/home/myhome/mydb.conf
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get t
Peter Eisentraut wrote:
mlw writes:
AFAIK it wasn't actually done. It was more of a, "we should do something
different" argument. At one point it was talked about rewriting the
configuration system to allow "include" and other things.
The cor
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
Stephan Szabo wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to
Bruce Momjian wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile
Robert Treat wrote:
On Thu, 2003-02-13 at 12:13, mlw wrote:
My patch only works on the PostgreSQL server code. No changes have been
made to the initialization scripts.
The patch declares three extra configuration file parameters:
hbafile= '/etc/postgres/pg_hba.conf'
Bruce Momjian wrote:
Well, in a sense, it trades passing one parameter, PGDATA, for another.
I see your point that we should specify configuration first, and let
everything pass from there. However, it does add extra configuration
parameters, and because you still need to specify/create pgdat
Bruce Momjian wrote:
Oliver Elphick wrote:
On Thu, 2003-02-13 at 17:52, Vince Vielhaber wrote:
Seems to me that if FHS allows such a mess, it's reason enough to avoid
compliance. Either that or those of you who build for distributions are
making an ill advised ch
Stephan Szabo wrote:
On Thu, 13 Feb 2003, mlw wrote:
Robert Treat wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt
Bruno Wolff III wrote:
On Thu, Feb 13, 2003 at 09:23:20 -0500,
mlw <[EMAIL PROTECTED]> wrote:
Personally, however, I think the configuration issue is a no-brainer and
I am amazed that people are balking. EVERY other service on a UNIX box
is configured in this way, why
Robert Treat wrote:
On Thu, 2003-02-13 at 09:23, mlw wrote:
I deal with a number of PG databases on a number of sites, and it is a
real pain in the ass to get to a PG box and hunt around for data
directory so as to be able to administer the system. What's really
annoyi
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instan
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
Here is the test, configure a server, with sendmail, named, apache, and
PostgreSQL. Tell me which of these systems doesn't configure right.
AFAIK, only one of those four is designed to support multiple instan
Christopher Browne wrote:
In the last exciting episode, [EMAIL PROTECTED] (Curt Sampson) wrote:
On Wed, 12 Feb 2003, Peter Bierman wrote:
What do you gain by having the postmaster config and the database
data live in different locations?
You can t
Peter Bierman wrote:
At 12:31 AM -0500 2/13/03, mlw wrote:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "right"
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
The idea that a, more or less, arbitrary data location determines the
database configuration is wrong. It should be obvious to any
administrator that a configuration file location which controls the
server is the "ri
Tom Lane wrote:
Kevin Brown <[EMAIL PROTECTED]> writes:
I assume $PGDATA was around long before GUC?
Yes, it was. But I have not yet seen an argument here that justifies
why $SOMECONFIGDIRECTORY/postgresql.conf is better than
$PGDATA/postgresql.conf. The latter keeps
Robert Treat wrote:
I'm going to be lazy and ask if you can post what the better solution
that was coming was (or a link to the thread). While I'll grant you that
the "it's coming" argument is pretty weak after two releases, that fact
that it may have been a better solution could still hold up.
The debate on the configuration file sparked a memory of an old patch I
submitted in 7.1 days.
One of the things I do not like about PostgreSQL is, IMHO, is a
backwards configuration process. Rather than specify a data directory,
the administrator should specify a database configuration file. W
Apology
After Mark calms down and, in fact, sees that Greg was saying the right thing
after all, chagrin is the only word.
I'm sorry.
Greg Copeland wrote:
On Tue, 2003-02-11 at 11:23, mlw wrote:
Greg Copeland wrote:
I'd personally rather have peop
Greg Copeland wrote:
I'd personally rather have people stumble trying to get PostgreSQL
running, up front, rather than allowing the lowest common denominator
more easily run PostgreSQL only to be disappointed with it and move on.
After it's all said and done, I would rather someone simply s
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
May I make a suggestion that maybe it is time to start thinking about
tuning the default config file, IMHO its just a little bit too
conservative,
It's a lot too conservative. I've been thinking for awhile t
Dann Corbit wrote:
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 31, 2003 8:24 PM
To: mlw
Cc: Lamar Owen; Dann Corbit; PostgresSQL Hackers Mailing List
Subject: Re: [mail] Re: [HACKERS] Windows Build System
mlw <[EMAIL PROTECTED]>
Tom Lane wrote:
mlw <[EMAIL PROTECTED]> writes:
Like it or not, if PG releases a very good Win32 port, ALL the unixoids
combined will be out numbered by the windoze users.
A lot of us are *not* looking forward to that prospect.
regards, tom lane
No doubt to that, but, dep
Like it or not, if PG releases a very good Win32 port, ALL the unixoids
combined will be out numbered by the windoze users.
Lamar Owen wrote:
On Friday 31 January 2003 20:22, Dann Corbit wrote:
Now, as far as the Win32 animosity goes, I think that is a natural thing
too. There is a culture c
Original Message
Subject: Re: [mail] Re: [HACKERS] Windows Build System
Date: Fri, 31 Jan 2003 15:46:20 -0500
From: mlw <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
CC: Curtis Faith <[EMAIL PROTECTED]>, 'Al Sutton'
<[EMAIL PROTECTED]>,
Tom Lane wrote:
"Curtis Faith" <[EMAIL PROTECTED]> writes:
If a developer can simply download the source, click on the Visual C++
project in the win32 directory and then build PostgreSQL, and they can
see that Windows is not the "poor stepchild" because the VC project is
well laid out, they
D'Arcy J.M. Cain wrote:
On Thursday 30 January 2003 14:02, mlw wrote:
Forgive my stupidity, are you running PostgreSQL with the data on an NFS
share?
Yes, sorry. PostgreSQL is running from the local disk but the data is on the
mounted drive.
I'm not sure, I guess it could
Forgive my stupidity, are you running PostgreSQL with the data on an NFS
share?
D'Arcy J.M. Cain wrote:
I have posted before about this but I am now posting to both NetBSD and
PostgreSQL since it seems to be some sort of interaction between the two. I
have a NetAPP filer on which I am puttin
st encourage them to do
so. I think that would do more harm than not having the option. When
PostgreSQL has a native Windows version, I'll add it. Until then, I
think of it more as a "desktop" version for small offices and
developers. The "server" version currently
Sorry, I think there was a misunderstanding. What were you looking for?
I used inno setup as well. If you want I can send my install script.
I thought I was being very forth coming.
I even help out on the Windows PG console window.
Justin Clift wrote:
Hi everyone,
Mark (mlw) put together
Greg Copeland wrote:
On Thu, 2003-01-23 at 09:12, Steve Wampler wrote:
On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:
Also remember that in even well developed OS's like FreeBSD, all a
process's threads will execute only on one CPU.
I doubt that
I have been following the debate about the Windows build environment.
I would like to say that the build environment is not a real issue for
Windows developers. For the most part Windows developers will be happy
with a working binary and an interface library. The one is savvy enough
to want to
This is an interesting thought. My gut tells me it is a viable
opportunity for the corporate entities that offer support and wish to
have 'VAR' status.
This is just my opinion, but I view the core development group as pure
development, and the various people that resell or distribute PostgreSQL
Peter Eisentraut wrote:
Adrian 'Dagurashibanipal' von Bidder writes:
- postgres should auto-tune itself - the *cost could perhaps be
adjusted after some statistics have been collected, and there should be
some sensible way to determine an optimal setting for the famous
shared_b
I don't think a semicolon is a comment. It causes the execution of the
previous statement.
Christopher Kings-Lynne wrote:
Hi,
In postgresql 7.3.1, if I do pg_dumpall -c, at the top of the dump file is
this:
DROP DATABASE au_shipping
;CREATE DATABASE au_shipping WITH OWNER = auadmin TEMPLATE =
Does anyone think it would be a good idea, or is it even practical, to
have a 'indx' subdirectory along side of the 'base' directory?
I was thinking that, if it were an easy modification, that it could be
an easy way to separate data and indexes to different hard disks.
---
Gavin Sherry wrote:
On Wed, 15 Jan 2003, mlw wrote:
I just wanted to post this note.
I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how
I just wanted to post this note.
I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how much easier
PostgreSQL is to work with.
We all may bitch and moan about
Dann Corbit wrote:
Message
I have
a machine with 4 CPU's and 2 gigabytes of physical ram.
I would
like to get PostgreSQL to use as much memory as possible. I can't seem
to get PostgreSQL to use more than 100 megabytes or so.
How can
I optimize the us
This is a serious inquiry, very serious. People are complaining about ads.
What do we need in the form of equipment, bandwidth, etc.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Please understand something here ... a large portion of the banner ads are
*not* paid ... they are recognition of the many mirror sites that are
supporting the project by reducing the amount of bandwidth that is
requi
Mon, 6 Jan 2003, Neil Conway wrote:
On Mon, 2003-01-06 at 13:26, Marc G. Fournier wrote:
On Mon, 6 Jan 2003, mlw wrote:
The PHP site shows adds.
Ok -- but the vast majority (say, 95%) of OSS sites don't show ads.
Neil Conway wrote:
On Sun, 2003-01-05 at 17:15, Dave Page wrote:
There were always ads there
Yes -- but AFAIK there were in the process of being phased out
(furthermore, the old site only had ads on the initial mirror page,
whereas they are much more widespread on the
Marc G. Fournier wrote:
Any volunteers to act as a tertiary? :)
We're actually working on adding a new server online that is offshore,
which will also give us another subnet to work off of ... but having a
third-party secondary server wouldn't hurt, you are right ...
OK, add 64.46.156.80 as
The site looks fantastic! Great work!
Marc G. Fournier wrote:
I'm just announcing here, since I'd like to see some ppl testing this out
and let us know if there are any problems ... DNS is going to take a
little while to propogate, so the old site may still come up in the
interium ... another re
I'll do it on my site.
Marc G. Fournier wrote:
Any volunteers to act as a tertiary? :)
We're actually working on adding a new server online that is offshore,
which will also give us another subnet to work off of ... but having a
third-party secondary server wouldn't hurt, you are right ...
Bruce Momjian wrote:
pg_upgrade does work, assuming there are no changes to the index or heap
file formats. (However, I now need to update it for schemas.) However,
the last time I worked on it for 7.2, no one was really interested in
testing it, so it never got done. In fact, there was a bu
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
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
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
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
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:
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
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
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
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
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
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
1 - 100 of 364 matches
Mail list logo
