Check out this link, if you need something to laugh at:
http://www.postgresql.org/idocs/index.php?1'
Keeping in mind, that there are bunch of overflows in PostgreSQL(really?),
it is
very dangerous i guess. Right?
This
On Tue, 8 Oct 2002, Sir Mordred The Traitor wrote:
Check out this link, if you need something to laugh at:
http://www.postgresql.org/idocs/index.php?1'
Keeping in mind, that there are bunch of overflows in PostgreSQL(really?),
it is
very dangerous i guess. Right?
I'm not sure what list
On Tue, 8 Oct 2002, Sir Mordred The Traitor wrote:
Check out this link, if you need something to laugh at:
http://www.postgresql.org/idocs/index.php?1'
Keeping in mind, that there are bunch of overflows in PostgreSQL(really?),
it is
very dangerous i guess. Right?
Don't see what you're
On Tue, Oct 08, 2002 at 12:35:22PM +0200, Erwan DUROSELLE wrote:
What I understood from the Administrator's guide is:
- Yes, PostgreSQL provides hot backup: it's the pg_dump utility. It'h
hot because users can still be connected and work whil pg_dump is running
( though they will be
Nice. That little, cute admin :-).
This is already fixed, and where is 'thanks' i wonder?
I've been talking about sql injection.
How about that in http://www.postgresql.org/mirrors/index.php:
---
Warning: PostgreSQL query failed: ERROR: invalid INET value 'r'
in
This is one of the reasons I usually recommend running with magic quotes
on, it provides a bit of insurance for those spots where your data
validation is not up to snuff.
Robert Treat
On Tue, 2002-10-08 at 06:11, Nigel J. Andrews wrote:
On Tue, 8 Oct 2002, Sir Mordred The Traitor wrote:
Since in your case all transactions A-E want the same buffer written,
the memory (not it's content) will also be the same.
But no, it won't: the successive writes will ask to write different
snapshots of the same buffer.
Successive writes would write different NON-OVERLAPPING sections of
Curtis Faith [EMAIL PROTECTED] writes:
Successive writes would write different NON-OVERLAPPING sections of the
same log buffer. It wouldn't make sense to send three separate copies of
the entire block. That could indeed cause problems.
So you're going to undo the code's present property that
Curtis Faith [EMAIL PROTECTED] writes:
Successive writes would write different NON-OVERLAPPING sections of the
same log buffer. It wouldn't make sense to send three separate
copies of
the entire block. That could indeed cause problems.
So you're going to undo the code's present property
Curtis Faith [EMAIL PROTECTED] writes:
I'm not really worried about doing page-in reads because the
disks internal
buffers should contain most of the blocks surrounding the end
of the log
file. If the successive partial writes exceed a block (which
they will in
heavy use) then most of
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
1. Where is the cleanest place to call SetQuerySnapshot() for utility
statements that need it?
Without looking at it too closely, I would think postgres.c would be best,
unless there is a legit reason for a utility statement to *not*
Hi,
My friend just notice me with some thing that make using dump files harder
to use.
So here we go:
first we make some chaos :)
\c template1 postgres
create user foo with password 'bar' createdb nocreateuser;
\c template1 foo
create database foodb;
\c template1 postgres
alter user foo with
Jim Buttafuoco wrote:
Is this NOT what I have been after for many months now. I dropped the
tablespace/location idea before 7.2 because that
didn't seem to be any interest. Please see my past email's for the SQL commands and
on disk directory layout I have
proposed. I have a working 7.2
Robert Partyka [EMAIL PROTECTED] writes:
\connect template1
.
CREATE USER foo WITH SYSID 32 PASSWORD 'bar' NOCREATEDB NOCREATEUSER;
.
\connect template1 foo
CREATE DATABASE foodb WITH TEMPLATE = template0 ENCODING = 'LATIN2';
\connect foodb foo
I think evryone see why it dont
I said:
... So I had
been thinking of pulling it out to postgres.c anyway. I will do that.
I did this and ended up with a rather long list of statement types that
might need a snapshot:
elog(DEBUG2, ProcessUtility);
/* set snapshot if utility stmt needs one
Tom Lane wrote:
I did this and ended up with a rather long list of statement types that
might need a snapshot:
elog(DEBUG2, ProcessUtility);
/* set snapshot if utility stmt needs one */
/* XXX maybe cleaner to list those that shouldn't set
Marc G. Fournier writes:
On Mon, 7 Oct 2002, Peter Eisentraut wrote:
Marc G. Fournier writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?
Probably not, because the version number needs to be changed and they need
to be
On Mon, Oct 07, 2002 at 05:42:12PM +0200, Zeugswetter Andreas SB SD wrote:
Hackers, do you think it's possible to hack together a quick and dirty
patch, so that string length is represented by one byte? IOW can a
database be built that doesn't contain any char/varchar/text value
longer
On Mon, 7 Oct 2002, Peter Eisentraut wrote:
Marc G. Fournier writes:
Looks good from my end, Peter, I pulled the same docs that I pulled for
v7.2.2, which I hope is okay?
Probably not, because the version number needs to be changed and they need
to be rebuilt for each release.
should I
On Tue, 2002-10-08 at 04:15, Zeugswetter Andreas SB SD wrote:
Can the magic be, that kaio directly writes from user space memory to the
disk ? Since in your case all transactions A-E want the same buffer written,
the memory (not it's content) will also be the same. This would automatically
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Can the magic be, that kaio directly writes from user space memory to the
disk ?
This makes more assumptions about the disk drive's behavior than I think
are justified...
Since in your case all transactions A-E want the same buffer
So you think if I try to write a 1 gig file, it will write enough to
fill up the buffers, then wait while the sync'er writes out a few blocks
every second, free up some buffers, then write some more?
Take a look at vfs_bio::getnewbuf() on *BSD and you will see that when
it can't get a
You example of 1 trx/proc/rev will wok _only_ if no more and no less
than 1/4 of platter is filled by _other_ log writers.
Not really, if 1/2 the platter has been filled we'll still get in one more
commit in for a given rotation. If more than a rotation's worth of writing
has occurred that
Hi,
First of all, sorry for disturbing you all guys with my email talking about
this subject again.
I am a Spanish student and I following a course about Genetic Algorithms. My
teacher suggested me to search for some information of how to optimize things
in a database. Then I thought about
Curtis Faith [EMAIL PROTECTED] writes:
Do you not think this is a potential performance problem to be explored?
I agree that there's a problem if the kernel runs short of buffer space.
I am not sure whether that's really an issue in practical situations,
nor whether we can do much about it at
Bruce,
Is there remarks along these lines in the performance turning section of
the docs? Based on what's coming out of this it would seem that
stressing the importance of leaving a notable (rule of thumb here?)
amount for general OS/kernel needs is pretty important.
Greg
On Tue, 2002-10-08
Can the magic be, that kaio directly writes from user space memory to the
disk ?
This makes more assumptions about the disk drive's behavior than I think
are justified...
No, no assumption about the drive, only the kaio implementation, namely, that
the kaio implementation reads the
A lot of different things going on but my perl program (whose backend crashed)
was doing a lot of insert into table as select * from another table for a
lot of different tables. I see triggers referenced here and it should be
noted that for one of the tables the triggers were first disabled
Shridhar Daithankar wrote:
On 7 Oct 2002 at 13:48, Neil Conway wrote:
Sandeep Chadha [EMAIL PROTECTED] writes:
Postgresql has been lacking this all along. I've installed postgres
7.3b2 and still don't see any archive's flushed to any other
place. Please let me know how is hot backup
What I understood from the Administrator's guide is:
- Yes, PostgreSQL provides hot backup: it's the pg_dump utility. It'h hot because
users can still be connected and work whil pg_dump is running ( though they will be
slowed down). ( See Administrator's guide ch9)
- No, PostgreSQL does
Curtis Faith kirjutas T, 08.10.2002 kell 01:04:
I may be missing something obvious, but I don't see a way to get more
than 1 trx/process/revolution, as each previous transaction in that
process must be written to disk before the next can start, and the only
way it can be written to the
On Tue, Oct 08, 2002 at 11:14:11AM +0530, Shridhar Daithankar wrote:
On 7 Oct 2002 at 11:21, Tom Lane wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
I say if it's a char field, there should be no indicator of length as
it's not required. Just store those many characters straight
ISTM aio_write only improves the picture if there's some magic in-kernel
processing that makes this same kind of judgment as to when to issue the
ganged write for real, and is able to do it on time because it's in
the kernel. I haven't heard anything to make me think that that feature
Hi everyone,
The Italian translation of the PostgreSQL Advocacy and Marketing site,
done by Stefano Reksten [EMAIL PROTECTED] is now complete and ready for
public use:
http://advocacy.postgresql.org?lang=it
Thanks heaps Stefano, you've put in a lot of effort and it's really
going to help. :-)
34 matches
Mail list logo
