On Apr 12, 2008, at 7:11 AM, Jaisen N.D. wrote:
localhost:/home/user# su - postgres
[EMAIL PROTECTED]:~$ /usr/lib/postgresql/8.1/bin/initdb -D /var/
lib/postgresql/data
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.
T
I would like to create a rule that, by updating a view, allows me to update
one table and insert into another.
The following example illustrates what I'm trying to do:
--Create Tables
CREATE TABLE my_table
(
my_table_id serial,
a character varying(255),
Hello:
This is a newbie question as I have not used the product before. After
installation of PG 8.2 I noticed that I have 2 servers: postgresql database
server 8.2 (localhost:5432) and another one differing only in the name (the
second one is 8.3). The problem is that I did not request the 8
"My premise is that someone will do mistakes in the php code and I'd like to
mitigate the effect of these mistakes."
- Prepared statements is the only "bulletproof" technique
- You can use a database abstraction layer (there are more than many
libraries for PHP) Fast to implement, all queries goe
On Sat, Apr 12, 2008 at 03:05:41PM +, william wayne wrote:
> This is a newbie question as I have not used the product before. After
> installation of PG 8.2 I noticed that I have 2 servers: postgresql
> database server 8.2 (localhost:5432) and another one differing only
> in the name (the secon
On Sat, 12 Apr 2008 11:11:48 -0400
"Jonathan Bond-Caron" <[EMAIL PROTECTED]> wrote:
> "My premise is that someone will do mistakes in the php code and
> I'd like to mitigate the effect of these mistakes."
>
> - Prepared statements is the only "bulletproof" technique
I'm not looking for something
On Fri, Apr 11, 2008 at 04:48:03PM -0500, Erik Jones wrote:
> On Apr 11, 2008, at 4:23 PM, Stefan Sturm wrote:
>> I don''t want to kill them. So how can I find out, what ist locking them?
>> Is there a tool, which shows me such Information?
>
> There is a system catalog view called pg_locks that ha
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> I may sound naive but having a way to protect the DB from this kind
> of injections looks as a common problem, I'd thought there was
> already a common solution.
Use prepared statements.
regards, tom lane
--
Sent via pg
On Fri, Apr 11, 2008 at 2:54 PM, Craig Ringer
<[EMAIL PROTECTED]> wrote:
> Pavan Deolasee wrote:
> > I wonder if it would make sense to add support to mount database in
> > *read-only* mode from multiple servers though. I am thinking about
> > data warehouse kind of operations where multiple server
On Sat, Apr 12, 2008 at 11:00 PM, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
>
> Not quite workable. Remember that table data is not always available on
> the block device -- there are pages modified in the buffer cache (shared
> memory), and other machines have no access to the other's shared
On Sat, 12 Apr 2008 12:39:38 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> > I may sound naive but having a way to protect the DB from this
> > kind of injections looks as a common problem, I'd thought there
> > was already a common solution.
>
>
On Sat, Apr 12, 2008 at 8:11 PM, Pavan Deolasee
<[EMAIL PROTECTED]> wrote:
> On Sat, Apr 12, 2008 at 11:00 PM, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > Not quite workable. Remember that table data is not always available on
> > the block device -- there are pages modified in the buffer ca
On Fri, Apr 11, 2008 at 9:21 PM, Ivan Sergio Borgonovo
<[EMAIL PROTECTED]> wrote:
> Is there a switch (php side or pg side) to avoid things like:
>
> pg_query("select id from table1 where a=$i");
>
> into becoming
>
> pg_query("select id from table1 where a=1 and 1=1; do something
> nasty; -- "
Ivan Sergio Borgonovo wrote:
Yeah... but how can I effectively enforce the policy that ALL input
will be passed through prepared statements?
Code reviews are about the only way to enforce this.
If I can't, and I doubt there is a system that will let me enforce
that policy at a reasonable
Pavan Deolasee wrote:
[...]
I am not suggesting one read-write and many read-only architecture. I am
rather suggesting all read-only systems. I would be interested in this
setup if I run large read-only queries on historical data and need easy
scalability. With read-only setup, you can easily
paul rivers wrote:
Ivan Sergio Borgonovo wrote:
Yeah... but how can I effectively enforce the policy that ALL input
will be passed through prepared statements?
Code reviews are about the only way to enforce this.
That's not entirely true - if you have a policy that says thou-shalt-not-use
"paul rivers" <[EMAIL PROTECTED]> writes:
>> If I can't, and I doubt there is a system that will let me enforce
>> that policy at a reasonable cost, why not providing a safety net that
>> will at least raise the bar for the attacker at a very cheap cost?
>
> How do you do this? Disallow string con
Gregory Stark wrote:
"paul rivers" <[EMAIL PROTECTED]> writes:
If I can't, and I doubt there is a system that will let me enforce
that policy at a reasonable cost, why not providing a safety net that
will at least raise the bar for the attacker at a very cheap cost?
How do you do thi
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> I am not suggesting one read-write and many read-only architecture. I am
> rather suggesting all read-only systems. I would be interested in this
> setup if I run large read-only queries on historical data and need easy
> scalability. With read-only
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> Use prepared statements.
> Yeah... but how can I effectively enforce the policy that ALL input
> will be passed through prepared statements?
Modify the PHP code (at whatever corresponds to the DBD layer)
to
On Sat, 12 Apr 2008 20:25:36 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "paul rivers" <[EMAIL PROTECTED]> writes:
>
> >> If I can't, and I doubt there is a system that will let me
> >> enforce that policy at a reasonable cost, why not providing a
> >> safety net that will at least raise the
I dumped the db with:
pg_dump -C -f dbname.dump
$ uname -a
Linux myhost.mydomain.net 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25
EST 2007 x86_64 x86_64 x86_64 GNU/Linux
Postgresql 8.2.7
And restored in another machine:
$ uname -a
Linux dkt 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:54:46 EDT 2008 i686
My mistake. Sorry for the noise.
Regards, Clodoaldo
2008/4/12, Clodoaldo <[EMAIL PROTECTED]>:
> I dumped the db with:
> pg_dump -C -f dbname.dump
>
> $ uname -a
> Linux myhost.mydomain.net 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25
> EST 2007 x86_64 x86_64 x86_64 GNU/Linux
>
> Postgresql 8.
On Sat, Apr 12, 2008 at 11:06:42PM +0200, Ivan Sergio Borgonovo wrote:
> But what about already written code that use pg_query?
If you rewrite the database interface then it doesn't matter, the calls
to pg_query will end up being calls to prepare/execute underneath so
you'll have their protection.
paul rivers wrote:
Ivan Sergio Borgonovo wrote:
Yeah... but how can I effectively enforce the policy that ALL input
will be passed through prepared statements?
Code reviews are about the only way to enforce this.
(Note: I'm clueless about PHP, so I'm basing this on perl/python/etc):
Somet
I am running into problems vacuuming my larger tables. It seems for tables
greater than 1 million rows, Vacuum just hangs. I could leave it running
for hours and it never comes to completion.
Things like copying the whole table to a temp table with bulk insert such as
(SELECT * INTO temp FROM
"Paragon" <[EMAIL PROTECTED]> writes:
> I am running into problems vacuuming my larger tables. It seems for tables
> greater than 1 million rows, Vacuum just hangs. I could leave it running
> for hours and it never comes to completion.
Is it actually *doing* anything, like consuming CPU or I/
>"Paragon" <[EMAIL PROTECTED]> writes:
>> I am running into problems vacuuming my larger tables. It seems for
>> tables greater than 1 million rows, Vacuum just hangs. I could leave it
running
>> for hours and it never comes to completion.
>Is it actually *doing* anything, like consuming C
28 matches
Mail list logo
