On Jan 8, 2007, at 2:11 PM, Ron Mayer wrote:
If not postgres, what other database could possibly do this, if
any? I
really don't want to have to write our own RDBMS. :)
Doesn't seem much like a database question. I'd say ask on some
trusted
computing (google Trusted Computing) list if y
Hello All,
I am running PostgresSQL 8.2 on Redhat Linux 4.
When I look for the processes that are using postgres
using ps aux|more
I got lots of Idle processes with servers own IP
address. Can anybody please tell me why this is
happening.
Also there are multiple processes for my single
client(same
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Tue, 2007-01-09 at 17:17, Ben wrote:
> If I create an index on a table that needs to be vacuumed in 7.3, will the
> dead rows get indexed as well?
> Yes. I think. I'm pretty sure that's still true in 8.2. as well. The
> way indexes work is that th
Tom Lane wrote:
> Jonathan Hedstrom <[EMAIL PROTECTED]> writes:
>
>> We are running a xen kernel: 2.6.18-1.2798.fc6xen
>>
>
> When did you start doing that ... any relation to the time when the
> problems started?
>
We started using the xen kernel on the 3rd, and there wasn't any
indi
On Tue, 2007-01-09 at 17:17, Ben wrote:
> And a related question: should a vacuum also clean out indexes on 7.3?
Should, might not. There definitely was a problem in 7.2 with indexes
on ever increasing values where the indexes would grow on one side of
the btree only. In 7.2 I had a table of abo
Andrew Kroeger wrote:
> This is the base Xen kernel from the FC 6 release. There have been 3
> updates released since then (most recently 01-Jan). I see a number of
> Xen fixes in the changelog, and I know that the major factor in the
> slippage of the FC 6 release was getting Xen into the distro
And a related question: should a vacuum also clean out indexes on 7.3?
On Tue, 9 Jan 2007, Ben wrote:
If I create an index on a table that needs to be vacuumed in 7.3, will the
dead rows get indexed as well?
---(end of broadcast)---
TIP 9: In ve
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> In this case the test would only be applied when no columns were being used
> in a table being joined to. Since that is also an unusual case, if that case
> could be quickly checked for, then it might conceivably be worth doing the
> more expensive test
Alvaro Herrera wrote:
To be frank, I'm not sure I understand what you're saying here. I'm
sure more analysis is good; that's easy to agree with.
However, I don't want to be trapped in a design that's too hard to
implement, or too hard for DBAs to manage.
+1
> There have been proposals to a
Martijn van Oosterhout writes:
> On Tue, Jan 09, 2007 at 04:09:21PM -0500, Tom Lane wrote:
>> One possibility that might handle Martijn's problem is to allow the
>> construct
>> ARRAY[]::type[]
> I don't think it would be too hard to fix, I'll look tomorrow.
It could be pretty ugly, because type
On Tue, Jan 09, 2007 at 10:33:52 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> No, that's still not right. With a LEFT JOIN you know that each row of
> the narrow table will produce at least one row in the join view. What
> you don't know is whether the row could produce more than one join ro
Jonathan Hedstrom wrote:
Scott Marlowe wrote:
On Tue, 2007-01-09 at 13:38, Jonathan Hedstrom wrote:
We recently upgraded from 8.1.4 to 8.2.0 on Fedora Core 6, and are now
seeing a few rather ominous-looking messages.
[ SNIP ]
Also, schedule some maintenance window for your server to run
On Tue, Jan 09, 2007 at 04:09:21PM -0500, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Unless we can convince ourselves that array-of-UNKNOWN is not dangerous,
> > I don't think this is easily solved.
>
> One possibility that might handle Martijn's problem is to allow the
> constr
Jonathan Hedstrom wrote:
Tom Lane wrote:
Scott Marlowe <[EMAIL PROTECTED]> writes:
Also, schedule some maintenance window for your server to run memtest86
and possibly something to check for bad blocks on your drives.
+1 ... I have not seen any instance of "invalid page header" that co
On Mon, Jan 08, 2007 at 20:20:42 -0500,
Matthew Terenzio <[EMAIL PROTECTED]> wrote:
> Is it true that you can't use COPY FROM to fill a table with a SERIAL
> type column?
>
> Or rather, how does one approach that situation most effectively?
In older versions of postgres you couldn't, in recent
Jonathan Hedstrom <[EMAIL PROTECTED]> writes:
> We are running a xen kernel: 2.6.18-1.2798.fc6xen
When did you start doing that ... any relation to the time when the
problems started?
I've heard some unkind remarks about the stability of Xen, though
I have no direct knowledge about it.
On Mon, Jan 08, 2007 at 14:55:29 -0600,
Jeanna Geier <[EMAIL PROTECTED]> wrote:
>
> Not quite sure what the: CONSTRAINT "Relationship182" is exactly... can
> anyone help me with this one? Haven't seen this one yet...
It is the name of that particular constraint. You would use that if you
wer
If you only want to use one database at a time you might look into using
DRBD. It's a linux block-level package that is like raid-1 over the
network.
On Tue, 9 Jan 2007, dcrespo wrote:
Hi everybody,
I have two computers with a Postgres Database each. I want one of them
to be the replica of t
On Tue, Jan 09, 2007 at 04:09:21PM -0500, Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
> > Unless we can convince ourselves that array-of-UNKNOWN is not dangerous,
> > I don't think this is easily solved.
>
> One possibility that might handle Martijn's problem is to allow the
> constr
Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
>
>> Also, schedule some maintenance window for your server to run memtest86
>> and possibly something to check for bad blocks on your drives.
>>
>
> +1 ... I have not seen any instance of "invalid page header" that could
> be trac
guillermo arias wrote:
> Hello, i am using PostgreSQL 8.2 in a Windows XP pc. I know that this
> file PGPASS.CONF stores the users with password, but because this is a
> plain txt file, it is easy for "curious" people to read the contents.
> By other way, if i do not write the password there, my us
Scott Marlowe <[EMAIL PROTECTED]> writes:
> On Tue, 2007-01-09 at 13:38, Jonathan Hedstrom wrote:
>> We recently upgraded from 8.1.4 to 8.2.0 on Fedora Core 6, and are now
>> seeing a few rather ominous-looking messages.
> First step, update to 8.2.1, it came out yesterday, and there were a few
>
Hello, i am using PostgreSQL 8.2 in a Windows XP pc. I know that this file PGPASS.CONF stores the users with password, but because this is a plain txt file, it is easy for "curious" people to read the contents.By other way, if i do not write the password there, my users will have to write it when t
Joris Dobbelsteen wrote:
> Now we have at least one different model, lets mix in other captures and
> situations. So it cannot be done with only YOUR data, I fully agree.
> But if you have sufficient data you can find the generalization of the
> model to make it work (resonable) in sufficient situ
Scott Marlowe wrote:
> On Tue, 2007-01-09 at 13:38, Jonathan Hedstrom wrote:
>
>> We recently upgraded from 8.1.4 to 8.2.0 on Fedora Core 6, and are now
>> seeing a few rather ominous-looking messages.
>>
>> The problem started with this one, during an update involving a rather
>> complex view:
Joe Conway <[EMAIL PROTECTED]> writes:
> Unless we can convince ourselves that array-of-UNKNOWN is not dangerous,
> I don't think this is easily solved.
One possibility that might handle Martijn's problem is to allow the
construct
ARRAY[]::type[]
that is, you can have an empty ARRAY con
Dave Page wrote:
That's not what Harald was referring to. The server status dialog monitors the
entire server via pg_stat*.
/D
Hi Dave,
It was not just a response to Harald's comment, but also the one right
above his :-)
"You can achieve something similar by enabling query logging in
On Tue, 2007-01-09 at 13:38, Jonathan Hedstrom wrote:
> We recently upgraded from 8.1.4 to 8.2.0 on Fedora Core 6, and are now
> seeing a few rather ominous-looking messages.
>
> The problem started with this one, during an update involving a rather
> complex view:
>
> ERROR: invalid memory allo
> --- Original Message ---
> From: Tony Caduto <[EMAIL PROTECTED]>
> To: Harald Armin Massa <[EMAIL PROTECTED]>
> Sent: 1/9/07, 7:15:52 PM
> Subject: Re: [GENERAL] is there a tracking trace tool like the "SQL Analizer"
>
> Harald Armin Massa wrote:
> > Jeffrey,
> >
> >> Not exactly. SQL
If I create an index on a table that needs to be vacuumed in 7.3, will the
dead rows get indexed as well?
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining colum
We recently upgraded from 8.1.4 to 8.2.0 on Fedora Core 6, and are now
seeing a few rather ominous-looking messages.
The problem started with this one, during an update involving a rather
complex view:
ERROR: invalid memory alloc request size 1174405120
Then, when attempting to re-run the same
Tom Lane wrote:
Martijn van Oosterhout writes:
On Tue, Jan 09, 2007 at 10:02:09AM -0500, Tom Lane wrote:
Define the data type of
SELECT ARRAY[];
The same type as:
SELECT NULL;
Hardly, because whatever type NULL has, it's not an array type.
Here's a link to the initial discussion on
> Hi,
> I may be wrong but:
> Enabling query logging (in the options dialog) will only log the SQL
> pgAdmin III sends to the server, it will not capture the query for a
> selected process
> in the server status dialog.
> If you want something like the trace in MS SQL server Lightning Admin
> has s
Harald Armin Massa wrote:
Jeffrey,
Not exactly. SQL Analyzer also includes live monitoring of whatever
queries
are coming into the database. You can achieve something similar by
enabling
query logging in the settings.
that is within Tools / View Server Status of pgAdmin III
Of course, Qu
On Tue, 2007-01-09 at 07:36, dcrespo wrote:
> Hi everybody,
>
> I have two computers with a Postgres Database each. I want one of them
> to be the replica of the other one; let's say I want a Master to Master
> replication in order to use either one (but only one at a time) as the
> main database:
Csaba Nagy wrote:
On Tue, 2007-01-09 at 17:36, Csaba Nagy wrote:
On Tue, 2007-01-09 at 17:31, Matthew T. O'Connor wrote:
Without getting into all the details, the autovacuum naptime is a GUC
variable right now, so it can be much more frequent than the current
default which is 60 second
Jeffrey,
Not exactly. SQL Analyzer also includes live monitoring of whatever queries
are coming into the database. You can achieve something similar by enabling
query logging in the settings.
that is within Tools / View Server Status of pgAdmin III
Of course, Query Command String has to be
Hi everybody,
I have two computers with a Postgres Database each. I want one of them
to be the replica of the other one; let's say I want a Master to Master
replication in order to use either one (but only one at a time) as the
main database: in case of failure, switch. The ideal synchronization
w
Not exactly. SQL Analyzer also includes live monitoring of whatever queries
are coming into the database. You can achieve something similar by enabling
query logging in the settings.
On 1/8/07, Ian Harding <[EMAIL PROTECTED]> wrote:
There is no GUI tool that I know of, but there is EXPLAIN wh
On Tue, 2007-01-09 at 10:44 -0500, Tom Lane wrote:
> Rafal Pietrak <[EMAIL PROTECTED]> writes:
> > 1. either the new value of "test_days.dnia" as already present in the
> > NEW row, is not visible to "UPDATE test_utarg" sub-statement of the same
> > transaction. But earlier versions of Postgres did
On Tue, Jan 09, 2007 at 08:28:29 -0500,
Chander Ganesan <[EMAIL PROTECTED]> wrote:
> It would. A query that uses an inner join implies that a matching entry
> must exist in both tables - so the join must occur, otherwise you could
> be returning rows that don't satisfy the join condition.
Whi
On Tue, Jan 09, 2007 at 10:10:46 -0600,
Jeanna Geier <[EMAIL PROTECTED]> wrote:
>
> If I cast the entire operation to an INT:
> (a.area * su.units_per_sqfoot::integer)::integer AS area_sq
> or by
> (a.area * su.units_per_sqfoot)::integer AS area_sq,
> I'm getting an 'ERROR: integer out of rang
On Tue, 2007-01-09 at 17:36, Csaba Nagy wrote:
> On Tue, 2007-01-09 at 17:31, Matthew T. O'Connor wrote:
> > Without getting into all the details, the autovacuum naptime is a GUC
> > variable right now, so it can be much more frequent than the current
> > default which is 60 seconds.
>
> Hmm, fo
On Tue, 2007-01-09 at 17:31, Matthew T. O'Connor wrote:
> Without getting into all the details, the autovacuum naptime is a GUC
> variable right now, so it can be much more frequent than the current
> default which is 60 seconds.
Hmm, for some reason I thought the granularity is minutes, but it
Csaba Nagy wrote:
Other thing, how will the vacuum queue be populated ? Or the "queue" here means
nothing, all workers will always go through all tables to pick one based on their own
criteria ? My concern here is that the current way of checking 1 DB per minute is not
going to work with categ
"Jeanna Geier" <[EMAIL PROTECTED]> writes:
> If I cast the entire operation to an INT: ...
> I'm getting an 'ERROR: integer out of range' error returned when I run my
> SELECT statement:
Perhaps use floor() instead?
regards, tom lane
---(end of br
Alban Hertroys <[EMAIL PROTECTED]> writes:
> My conclusion is that this query time is mostly limited to the somewhat
> complex COUNT expressions. Is there any way to do this more efficiently?
Offhand I would bet on the bitstring-AND operations being the
bottleneck; you could test this by comparing
Shouldn't these be using HAVING?
SELECT COUNT(max_persons) ...
GROUP BY NULL
HAVING max_persons >= 5 AND max_persons <= 8;
--
Brandon Aiken
CS/IT Systems Engineer
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alban Hertroys
Sent: Tuesday, January 09, 2
Thanks for the reply! That worked, but I'm running into one other issue that
I'm having some trouble resolving...
Problem: We want all values in the measurement view (and table once I copy
it into there) to be shown in ints vs. floats/decimals.
In my View (called 'measurement'), there is a calc
Hi all,
I need your help on a small performance problem.
I have a table of which I have to do a bunch of counts of various
conditions. The worst case scenario where I have to iterate over every
record in the table performs just a little bit too slow (800ms). That
particular query will be hit a lo
Rafal Pietrak <[EMAIL PROTECTED]> writes:
> 1. either the new value of "test_days.dnia" as already present in the
> NEW row, is not visible to "UPDATE test_utarg" sub-statement of the same
> transaction. But earlier versions of Postgres did allow for that
> visibility.
> 2. or the constrainets in e
Chander Ganesan <[EMAIL PROTECTED]> writes:
> In theory, if the table with 6 columns was the child of the table with
> 200+ columns, and a PK-FK relationship existed, then the optimizer
> wouldn't need to check for the existence of the rows, since the PK-FK
> relationship would indicate that the
Martijn van Oosterhout writes:
> On Tue, Jan 09, 2007 at 10:02:09AM -0500, Tom Lane wrote:
>> Define the data type of
>> SELECT ARRAY[];
> The same type as:
> SELECT NULL;
Hardly, because whatever type NULL has, it's not an array type.
> In fact, you could just make it an unknown
> literal with
>-Original Message-
>From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
>Sent: dinsdag 9 januari 2007 3:43
>To: Joris Dobbelsteen
>Cc: Chris Browne; pgsql-general@postgresql.org
>Subject: Re: [GENERAL] Autovacuum Improvements
>
>Joris Dobbelsteen wrote:
>> Why not collect some information from
On Tue, Jan 09, 2007 at 10:02:09AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Is there a particular reason why the array constructor requires at
> > least one argument?
>
> Define the data type of
>
> SELECT ARRAY[];
The same type as:
SELECT NULL;
or
SELECT '{
Martijn van Oosterhout writes:
> Is there a particular reason why the array constructor requires at
> least one argument?
Define the data type of
SELECT ARRAY[];
regards, tom lane
---(end of broadcast)---
T
Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/09/07 07:28, Chander Ganesan wrote:
Ron Johnson wrote:
On 01/08/07 20:39, Tom Lane wrote:
John Sales <[EMAIL PROTECTED]> writes:
By doing this, I'm hoping that the query optimizer is smart
en
On 09/01/07, Ron Johnson <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/07 20:39, Tom Lane wrote:
> John Sales <[EMAIL PROTECTED]> writes:
>> By doing this, I'm hoping that the query optimizer is smart
>> enough to see that if a query comes in and requests only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/09/07 07:28, Chander Ganesan wrote:
> Ron Johnson wrote:
>>
>> On 01/08/07 20:39, Tom Lane wrote:
>>
>>> John Sales <[EMAIL PROTECTED]> writes:
>>>
By doing this, I'm hoping that the query optimizer is smart
enough to see that if
Ron Johnson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/07 20:39, Tom Lane wrote:
John Sales <[EMAIL PROTECTED]> writes:
By doing this, I'm hoping that the query optimizer is smart
enough to see that if a query comes in and requests only the
six columns (that are in t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/08/07 20:39, Tom Lane wrote:
> John Sales <[EMAIL PROTECTED]> writes:
>> By doing this, I'm hoping that the query optimizer is smart
>> enough to see that if a query comes in and requests only the
>> six columns (that are in the narrower table) t
Joseph Shraibman wrote:
> 8.0.x has the problem that VACUUM FULL on a table does not reclaim space
> from the indexes, and I have to issue a separate REINDEX command. Has
> this been fixed in later versions?
No.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
Th
woger151 wrote:
Thanks for the quick response! And if your email address is correct, at
a very early hour in the morning.
Our Tom never sleeps.
Ray.
---
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
[EMAIL PR
Doh ! Thanks for the swift response ... bet you are right. Getting punch drunk
on too many electrons ...
G
-Original Message-
From: Martijn van Oosterhout [mailto:[EMAIL PROTECTED]
Sent: Tue 1/9/2007 3:55 AM
To: Gregory S. Williamson
Cc: pgsql-general@postgresql.org
Subject
On Tue, Jan 09, 2007 at 03:42:47AM -0800, Gregory S. Williamson wrote:
> This is PostgreSQL 8.1.4, and I am utterly lost.
> The error message:
> psql:e.sql:54: ERROR: syntax error at or near "$2" at character 15
> QUERY: SELECT $1 $2 := $3
> CONTEXT: SQL statement in PL/PgSQL function "
This is PostgreSQL 8.1.4, and I am utterly lost.
This function started in Informix and worked perfectly. Migrating to postgres
resulted in about a *10,000* x slow down as it resorts to doing a sequential
scan. In the sql below the addition of client id and report id to the initial
select are an
Hi,
Is there a particular reason why the array constructor requires at
least one argument? It's a bit irriating to have to special case zero
length arrays.
# select array[];
ERROR: syntax error at or near "]" at character 14
# select array[1];
array
---
{1}
(1 row)
# select '{}'::int4[];
On Mon, 2007-01-08 at 20:11, Ron Mayer wrote:
[snip]
> That's unlikely to work anyway. Organizations protecting valuable data
> using technical approaches (DVDs, etc) find it gets out anyway.
> Since you'll ship a client that can decrypt the data anyway, anyone with
> a debugger could decrypt it (u
On Mon, 2007-01-08 at 22:29, Chris Browne wrote:
[snip]
> Based on the three policies I've seen, it could make sense to assign
> worker policies:
>
> 1. You have a worker that moves its way through the queue in some sort of
>sequential order, based on when the table is added to the queue, to
>
On Tue, 9 Jan 2007, Hannes Dorbath wrote:
Several /contrib/tsearch2 fixes (Teodor)
Is there a more detailed list available?
fixes thesaurus dictionary and rank function.
Does it obsolete tsearch_snowball_82.gz?
No, it's still needed. This is incompatible change, so
we can't apply it for
Several /contrib/tsearch2 fixes (Teodor)
Is there a more detailed list available?
Does it obsolete tsearch_snowball_82.gz?
Thanks!
--
Regards,
Hannes Dorbath
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
71 matches
Mail list logo
