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.
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 h
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 (upda
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
> > l
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
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 should
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 o
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 evryon
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
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 NO
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 no
Request from sender:
--
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
--- Begin Message -
> > 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 t
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 *
> "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 us
"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
> "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 pre
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
"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
"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
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 Po
> > 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 sectio
> 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 m
> 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
"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 w
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:
>
> >
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
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.
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 /usr/local/www/www/mirrors/in
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 s
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'r
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 l
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 let
> 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
34 matches
Mail list logo
