Jorge Godoy wrote:
> I'll have to dig if the libraries I use support that. It
> would be much more interesting changing certificates once
> a year than hardcoding passwords on code...
But remember that you will still be asked for a password
unless you use trust authentication.
Yours,
Laurenz Alb
I'm writing a python script to update some tables in a db. My problem is
that I need to lock a couple of tables, perform several operations and
read the corresponding output.
I was thinking about lock in exclusive mode, but in the documentation I
found that it is valid only in a transaction. But s
Ottavio Campana wrote:
> I'm writing a python script to update some tables in a db. My
> problem is
> that I need to lock a couple of tables, perform several operations and
> read the corresponding output.
>
> I was thinking about lock in exclusive mode, but in the
> documentation I
> found that
On Thu, Sep 20, 2007 at 04:33:25PM -0500, Scott Marlowe wrote:
> On 9/20/07, Robert Fitzpatrick <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-09-20 at 16:38 -0400, Bill Moran wrote:
> > > In response to Robert Fitzpatrick <[EMAIL PROTECTED]>:
> > > Why does everyone leave of the IO subsystem? It's a
Albe Laurenz ha scritto:
> Ottavio Campana wrote:
>> I'm writing a python script to update some tables in a db. My
>> problem is
>> that I need to lock a couple of tables, perform several operations and
>> read the corresponding output.
>>
>> I was thinking about lock in exclusive mode, but in the
mytable has 1857 rows, copy_mytable is a copy of mytable and I want to
know which new rows have been entered. I used the where id not in, and
the query works. My problem is that if I run the same command on another
table with 378415 rows, it is terribly slow. I ran explain analyze on
the first tabl
On Fri, Sep 21, 2007 at 11:53:54AM +0200, Ottavio Campana wrote:
> the point is that for each table I have a copy I previously made and I
> want to create an incremental backup. My problem is that I don't want
> the original table to change, so I lock it.
>
> I admin that exclusive lock is probabl
Alban Hertroys ha scritto:
> Ottavio Campana wrote:
>> 2) how can I speed it up? by using indexes? or by changing the query?
>
> Do you have indices on mytable.id and copy_mytable.id?
> Does using NOT EXISTS get you any better results?
mytable.id is primary key.
I create copy_mytable with
create
Hi,
Where in the source code can I see the error message that says foreign key
to a view is not allowed
The exact error message as it appears when I try foreign key reference on a
view is
referenced relation "xyz_view" is not a table
I just wanted to know where is this error message thrown
I thought I would give this question a second try.
--- Richard Broersma Jr <[EMAIL PROTECTED]> wrote:
> A while back it was pointed out the that the Windows version of 8.2.3 had a
> bug that prevented
> auto-vacuum from working correctly.
>
> http://archives.postgresql.org/pgsql-general/2007-04
Richard Broersma Jr wrote:
> A while back it was pointed out the that the Windows version of 8.2.3
> had a bug that prevented auto-vacuum from working correctly.
>
> http://archives.postgresql.org/pgsql-general/2007-04/msg00139.php
>
> I wasn't able to determine from the release notes if this bug
I have to agree with both of you...
But unfortunately there are still some loose ends... See bug 3596...
http://archives.postgresql.org/pgsql-bugs/2007-09/msg9.php
But leaving bugs aside, I will have to say "Bravo!" to the development team!
Ciprian Craciun.
P.S.: I forgot
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Hmm, maybe it was, but then I cannot recall what bug I was referring to
> :-( I can't find a relevant CVS log message either.
Okay. FWIW, I am still seeing the same behavior in Version 8.2.4. But I am
about to upgrade to
8.2.5, and I will check
On 9/21/07, Ottavio Campana <[EMAIL PROTECTED]> wrote:
> My problem is that if I run the same command on another
> table with 378415 rows, it is terribly slow.
How much is "terribly slow"?
Did you VACUUM ANALYZE?
Anyways, try this:
SELECT * FROM MYTABLE T1
LEFT JOIN COPY_MYTABLE T2
ON T1.ID = T
On 9/21/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 20, 2007 at 04:33:25PM -0500, Scott Marlowe wrote:
> > On 9/20/07, Robert Fitzpatrick <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2007-09-20 at 16:38 -0400, Bill Moran wrote:
> > > > In response to Robert Fitzpatrick <[EMAIL PROTECTE
Ottavio Campana <[EMAIL PROTECTED]> írta:
> mytable.id is primary key.
>
> I create copy_mytable with
> create table copy_mytable as (select * from mytable);
>
> the planer behavior does not change no matter if I create and index
> on copy_mytable.id or not.
Try this, with an index on copy_myt
--- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Maybe you should restate your problem so we can try to discover the
> cause.
Okay.
I will dis-able the hourly manual vacuum/analyze script that I implemented as a
work-around to
this problem to see if auto-vacuum is ever triggered.
But to start o
Woah, when did that come around? Talk about sweet syntactic sugar
On Sep 20, 2007, at 10:12 PM, D. Dante Lorenso wrote:
I'm loving the new RETURNING clause in PostgreSQL. This is really
cool stuff ...
---(end of broadcast)---
TIP 9: In ve
Richard Broersma Jr wrote:
> --- Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Hmm, maybe it was, but then I cannot recall what bug I was referring to
> > :-( I can't find a relevant CVS log message either.
>
> Okay. FWIW, I am still seeing the same behavior in Version 8.2.4. But
> I am abou
You blinked again, didn't you? :)
On 9/21/07, Ben <[EMAIL PROTECTED]> wrote:
> Woah, when did that come around? Talk about sweet syntactic sugar
>
> On Sep 20, 2007, at 10:12 PM, D. Dante Lorenso wrote:
>
> > I'm loving the new RETURNING clause in PostgreSQL. This is really
> > cool stuff ..
--- Richard Broersma Jr <[EMAIL PROTECTED]> wrote:
> I will dis-able the hourly manual vacuum/analyze script that I implemented as
> a work-around to
> this problem to see if auto-vacuum is ever triggered.
it appears to be working fine in 8.2.5:
proj02u20411=> begin transaction;
BEGIN
proj02u20
Hi all,
I'm seeing a problem where pg_dump takes at least 5 minutes to execute
no matter what I ask it to dump -- even a non-existent or empty table.
One possible red flag is that pg_type contains 56508 rows. This
doesn't seem excessive to me, but perhaps it should. I've looked
through the source c
"Josh Harrison" <[EMAIL PROTECTED]> writes:
> I just wanted to know where is this error message thrown in the source
> code.?
"\set VERBOSITY verbose" would help...
regression=# create view v as select * from int4_tbl;
CREATE VIEW
regression=# \set VERBOSITY verbose
regression=# create table t (f
"Nikita The Spider The Spider" <[EMAIL PROTECTED]> writes:
> I'm seeing a problem where pg_dump takes at least 5 minutes to execute
> no matter what I ask it to dump -- even a non-existent or empty table.
> One possible red flag is that pg_type contains 56508 rows. This
> doesn't seem excessive to
Just a quick question. Are there any issues or incompatibilities
that I should be aware of if I want to build out 64 bit binaries to
run on a db that's previously been run by 32 bit binaries?
Erik Jones
Software Developer | Emma®
[EMAIL PROTECTED]
800.595.4401 or 615.292.5888
615.292.0777 (
On 9/21/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Nikita The Spider The Spider" <[EMAIL PROTECTED]> writes:
> > I'm seeing a problem where pg_dump takes at least 5 minutes to execute
> > no matter what I ask it to dump -- even a non-existent or empty table.
> > One possible red flag is that pg_typ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Jones wrote:
> Just a quick question. Are there any issues or incompatibilities that I
> should be aware of if I want to build out 64 bit binaries to run on a db
> that's previously been run by 32 bit binaries?
Its a dump reload.
Joshua D. Drak
On Sep 21, 2007, at 11:59 AM, Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erik Jones wrote:
Just a quick question. Are there any issues or incompatibilities
that I
should be aware of if I want to build out 64 bit binaries to run
on a db
that's previously been run
On Sep 21, 2007, at 12:02 PM, Alvaro Herrera wrote:
Erik Jones wrote:
Just a quick question. Are there any issues or incompatibilities
that I
should be aware of if I want to build out 64 bit binaries to run
on a db
that's previously been run by 32 bit binaries?
Obviously you are already
Erik Jones wrote:
> Just a quick question. Are there any issues or incompatibilities that I
> should be aware of if I want to build out 64 bit binaries to run on a db
> that's previously been run by 32 bit binaries?
Obviously you are already aware that you need to dump/reload, so I won't
mentio
... Or something like that. :)
Sorry for so many questions! I have another "how do I create this
query?" question, if it's okay.
I've got three tables; 'foo', 'bar' and 'baz'.
In 'foo' I've got 'foo_id' which is a PK. I've also got a bunch of
other info, but in essence this is the "parent"
Guys,
Is there any exposed PG-specific API to utilize shared memory while
working with SPI ? Thanks!
Best regards,
Alex Vinogradovs
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an in
On Sep 21, 2007, at 2:17 PM, Madison Kelly wrote:
... Or something like that. :)
Sorry for so many questions! I have another "how do I create this
query?" question, if it's okay.
I've got three tables; 'foo', 'bar' and 'baz'.
In 'foo' I've got 'foo_id' which is a PK. I've also got a bun
Thanks to both of you, Erik and Jon!
I had to tweak your two replies to get what I wanted (all 'foo' rows
returned, was only getting ones with a match in 'baz'). You two sent me
on the right path though and I was able to work out the rest using the
PgSQL docs on 'CASE' and 'JOIN'.
Here i
Madison Kelly wrote:
> I want to create a query that will allow me to say "show me all 'foo'
> rows and tell me if a specific 'baz_id' belongs to it". Normally, I
> would do this:
>
> SELECT foo_id FROM foo;
> (for each returned row)
> {
> # Where '$foo_id' is the current 'foo_id' and '$
Madison Kelly wrote:
Thanks to both of you, Erik and Jon!
I had to tweak your two replies to get what I wanted (all 'foo' rows
returned, was only getting ones with a match in 'baz'). You two sent me
on the right path though and I was able to work out the rest using the
PgSQL docs on 'CASE'
Madison Kelly wrote:
It's returning a row from 'foo' for every entry in baz that has an
entry pointing to foo (possibly same problem with each pointer to an
entry in bar, not sure yet). The 'true/false' part is working though...
Back to reading. *sigh* :)
Madi
I'm sorry for all the line n
PostgreSQL Version: v1.8.2
System: Windows 2000 Server
I am having a problem starting the PostgreSQL server. I
get the following Log errors:
LOG: unrecognized win32 error code: 487
FATAL: could not reattach to shared memory (key=5432001, addr=015E):
Invalid argument
What do I need to do
Daniel B. Thurman wrote:
>
> PostgreSQL Version: v1.8.2
> System: Windows 2000 Server
>
> I am having a problem starting the PostgreSQL server. I
> get the following Log errors:
>
> LOG: unrecognized win32 error code: 487
> FATAL: could not reattach to shared memory (key=5432001, addr=015E000
Christian Schröder wrote:
> I think it is my job as db admin to make the database work the way my users
> need it, and not the user's job to find a solution that fits the database's
> needs ...
>
> Is there really nothing that I can do?
You can improve the selectivity estimator function. One i
>"Andrew J. Kopciuch" <[EMAIL PROTECTED]> wrote on 09/19/2007 08:31:08 PM:
> Or just run the dump through psql.
> psql -U postgres -d template1 -f /tmp/$(date +%F)owl.sql
Thank you this worked.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
*** ***
Margaret Gillon, IS De
>Andrew Sullivan <[EMAIL PROTECTED]> wrote on 09/19/2007 10:12:26 AM:
> It wouldn't, but your old data still need to be dumped and restored;
> and without a running 8.1, that won't help you. Unless you mean that
> you'd install 8.2.x and load from a backup.
>
Thank you for your help. I wasn't ab
>>
>> PostgreSQL Version: v1.8.2
>> System: Windows 2000 Server
>>
>> I am having a problem starting the PostgreSQL server. I
>> get the following Log errors:
>>
>> LOG: unrecognized win32 error code: 487
>> FATAL: could not reattach to shared memory (key=5432001,
>addr=015E): Invalid ar
On Fri, 2007-09-21 at 12:50 -0700, Alex Vinogradovs wrote:
> Guys,
>
>
> Is there any exposed PG-specific API to utilize shared memory while
> working with SPI ? Thanks!
>
What are you trying to do?
The available SPI functions don't include any shared memory access, do
you actually want access
Yes, I'd like to get some memory of my own, so that it can
be shared between functions executing in different connections.
Is there an existent API, or should I just straight use Unix IPC ?
Thanks!
Alex.
On Fri, 2007-09-21 at 16:33 -0700, Jeff Davis wrote:
> On Fri, 2007-09-21 at 12:50 -0700, Al
On Thursday 20 September 2007 18:38, Merlin Moncure wrote:
> On 9/20/07, Collin <[EMAIL PROTECTED]> wrote:
> > Well, the subject says it pretty well but to elaborate:
> >
> > I have a database from our ERP package that uses btrieve (PervasiveSQL)
> > for it's database engine. I'd like to transition
On 9/21/07, Robert Treat <[EMAIL PROTECTED]> wrote:
> On Thursday 20 September 2007 18:38, Merlin Moncure wrote:
> > On 9/20/07, Collin <[EMAIL PROTECTED]> wrote:
> > > Well, the subject says it pretty well but to elaborate:
> > >
> > > I have a database from our ERP package that uses btrieve (Perv
Alex Vinogradovs <[EMAIL PROTECTED]> writes:
> Yes, I'd like to get some memory of my own, so that it can
> be shared between functions executing in different connections.
> Is there an existent API, or should I just straight use Unix IPC ?
As of (I think) 8.2, there's RequestAddinShmemSpace and R
Alvaro Herrera wrote:
Christian Schröder wrote:
I think it is my job as db admin to make the database work the way my users
need it, and not the user's job to find a solution that fits the database's
needs ...
Is there really nothing that I can do?
You can improve the selectivity e
49 matches
Mail list logo
