We see that the win32 version of PostgreSQL sometime does not respond
to pgbench -S running on Linux. Try something like:
pgbench -h windows_host -S -c 128 -t 1000 your_database
on Linux/FreeBSD/UNIX or whatever.
--
Tatsuo Ishii
> I think we are getting closer to a final release. I haven't seen
I think we are getting closer to a final release. I haven't seen many
_major_ failures in a few weeks, and the open items list is shrinking. I
would like us to make a concentrated effort to address or fix all the
open items by November 1 and consider a final 8.0 release during November.
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The question in my mind is "What are we protecting against?" ISTM it is
the use of the pl as a vector to attack the machine and postgres. Does a
segfault come into that category? After all, isn't it one of postgres's
strengths that w
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The question in my mind is "What are we protecting against?" ISTM it is
> the use of the pl as a vector to attack the machine and postgres. Does a
> segfault come into that category? After all, isn't it one of postgres's
> strengths that we can surviv
Hi Tom,
On Fri, Oct 15, 2004 at 11:27:05AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > On Thu, Oct 14, 2004 at 11:08:54PM +0200, Yann Michel wrote:
> >> BTW: Is there any more documented CVS-version available? I mean it would
> >> be really nice to read some comments fr
Tom Lane wrote:
Having seen a couple recent reports of "could not access status of
transaction" for old, not-obviously-corrupt transaction numbers, I went
looking to see if I could find a way that the system could truncate CLOG
before it's really marked all occurrences of old transaction numbers as
Tom Lane wrote:
David Helgason <[EMAIL PROTECTED]> writes:
A postgres question I don't know the answer to is whether allowing the
user to trigger a segfault is a security problem.
It would not be cool for a trusted language to allow such things, that's
for sure.
You could debate back and
Peter Eisentraut wrote:
> Am Freitag, 15. Oktober 2004 06:24 schrieb Bruce Momjian:
> > I have modified these reports so they print the full path used.
> >
> > Typical pg_dumpall output is:
> >
> > The program "pg_dump" is needed by pg_dumpall but was not found in the
> > same directory as "/usr/
David Helgason wrote:
On 14. okt 2004, at 21:09, Andrew Dunstan wrote:
It has just been brought to my attention that we are being very
restrictive about what we allow to be done in trusted plperl.
Basically we allow the :default and :base_math set of operations (run
perldoc Opcode or see
http:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Thu, Oct 14, 2004 at 11:08:54PM +0200, Yann Michel wrote:
>> BTW: Is there any more documented CVS-version available? I mean it would
>> be really nice to read some comments from time to time or at least more
>> comments about each function/method's p
David Helgason <[EMAIL PROTECTED]> writes:
> A postgres question I don't know the answer to is whether allowing the
> user to trigger a segfault is a security problem.
It would not be cool for a trusted language to allow such things, that's
for sure.
You could debate back and forth about whether
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> You can now - it's part of :base_math. What we should do, however, is
> disallow is calling srand, since pg goes to quite a bit of trouble to
> seed the PRNG.
But changing the PRNG seed within one backend is not a security issue.
At least, we allow an
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Andrew Dunstan
> Sent: 15 October 2004 15:07
> To: PostgreSQL-development
> Subject: [HACKERS] get_progname and .exe suffix
>
>
> Somewhere along the way, probably when we moved to using a
> ge
My original code for initdb stripped the .exe suffix off the progname
stored, in this snippet of code:
carg0 = xstrdup(argv[0]);
canonicalise_path(carg0);
lastsep = strrchr(carg0, *'/'*);
progname = lastsep ? xstrdup(lastsep + 1) : carg0;
#*if* *defined*(__CYGWIN__
Dann Corbit wrote:
> Create a 64 bit hash (e.g. UMAC) of the prepared statement (removing
> hardwired parameters as needed so that "SELECT Col1, col2 FROM
Some_Table
> where FOO = 'BAR'" becomes "SELECT COL1, COL2 FROM SOME_TABLE WHERE
FOO =
> ?", form consistent capitalization of the statement by
Am Freitag, 15. Oktober 2004 06:24 schrieb Bruce Momjian:
> I have modified these reports so they print the full path used.
>
> Typical pg_dumpall output is:
>
> The program "pg_dump" is needed by pg_dumpall but was not found in the
> same directory as "/usr/local/postgres/bin/pg_dumpall".
> Che
> I saw your message on the postgresql mailing lists. The TelegraphCQ
> project at Berkeley is implemented using the Postgres code base as a
> starting point. TelegraphCQ has a generalized mechanism for receiving
> data from remote data sources, and also for on demand request-response
> style queri
17 matches
Mail list logo
