Hi all,
A customer's database has started whining about a busted block:
postgresql-8.4-main.log:2012-10-02 18:51:33 EST ERROR: invalid page header in
block 8429809 of relation base/807305056/950827614
postgresql-8.4-main.log:2012-10-02 18:56:52 EST ERROR: invalid page header in
block 8429809
On 02/11/2011, at 2:16 PM, Tom Lane wrote:
> Royce Ausburn writes:
>> [ random() is evaluated only once in ]
>> test=# select (select random()) from generate_series(1,10); -- rows are the
>> same
>
>> I understand that it's likely an optimisation thing -- p
I'm having trouble understanding why these two queries produce different
results:
test=# select (select random()) from generate_series(1,10); -- rows are the same
?column?
---
0.770797704812139
0.770797704812139
0.770797704812139
0.770797704812139
0.770797704812139
On 26/10/2011, at 1:17 PM, Lee Hachadoorian wrote:
> I need some advice on storing/retrieving data in large rows. Invariably
> someone points out that very long rows are probably poorly normalized, but I
> have to deal with how to store a dataset which cannot be changed,
> specifically the ~23
>
> On 30/09/2011, at 8:57 AM, Jason Long wrote:
>
>> I thought I had read somewhere that Postges could ignore a join if it
>> was not necessary because there were no columns from the table or view
>> selected in the query. Is this possible?
>
> You might be thinking of this enhancement introd
On 30/09/2011, at 8:57 AM, Jason Long wrote:
> I thought I had read somewhere that Postges could ignore a join if it
> was not necessary because there were no columns from the table or view
> selected in the query. Is this possible?
You might be thinking of this enhancement introduced in 9.0:
I'm in the process of testing out Postgres 9.0 for production use. I've been
using it for development on my mac, a build from EnterpriseDB. We've just
installed a 9.0.5 on an Ubuntu (Ubuntu 10.04.3 LTS) machine from a backport
from lucid. There's an existing 8.4.8 postgres install also on tha
> I created a new view called "clients2" with the same member tables as clients
> and it works I can query it.
>
> But due to the many hardcoded places that use "clients" view, I have to have
> "clients" view. So I tried to drop clients view but cannot
>
> #DROP view clients;
> ERROR: missin
void any query parsing overhead, and averaging the time over several
> thousand queries). I'm not sure why...?
I'm not sure, Chris - perhaps others on the mailing list can answer this?
>
>
>
> On Tue, Aug 23, 2011 at 8:14 PM, Royce Ausburn wrote:
>> This might
This might help you:
http://www.postgresql.org/docs/8.4/static/queries-with.html
On 24/08/2011, at 9:54 AM, Chris Hanks wrote:
> I have two tables:
>
> CREATE TABLE items
> (
> root_id integer NOT NULL,
> id serial NOT NULL,
> -- Other fields...
>
> CONSTRAINT items_pkey PRIMARY KEY (root_
Hi all,
A few days ago one of our postgres (8.3.12) servers was a bit unhappy, and
someone decided to try a kill -9 on a backend process after a kill (TERM) was
ineffective. I've read many times in the past that a kill -9 can be pretty
hazardous to a postgres' health, and now it seems I get to
On 02/03/2011, at 2:16 PM, Andy Colson wrote:
> Its getting id1 from the parent table. (test2) You can use fields from the
> parent table in subselects.
>
> try this and it'll complain:
>
> select * from test2 where id1 in (select junk from test1) and charge=70;
Oh! Of course! What a fool
Hi all,
Got an odd one.
test=# select version();
version
---
>
> Don't the bash scripts get checked in to .../perforce/cvs/svn/git/...?
> Aren't they part of the resources of the project(s)?
Yep - they absolutely are. The issue is that there're multiple branches
*potentially* having new scripts committed. Fortunately it's rare as the
release branches
>
> So, 10.0 at 10057.
> 11.0 at 11023.
>
> then 10.1 needs some fixes so db is bumped to 10058.
>
> Then, later, you can upgrade 10057 to 11023, but you cant get 10058 to 11023.
>
> Humm... maybe you need smarter upgrade scripts? Would having logic in the
> script help? Something like:
>
>
On 11/02/2011, at 9:59 AM, Thomas Kellerer wrote:
> Royce Ausburn wrote on 10.02.2011 22:38:
>> I'm really interested to hear how you guys manage schema upgrades in
>> the face of branches and upgrading from many different versions of
>> the database.
>
> We are
Hi all,
My company is having trouble managing how we upgrade schema changes across many
versions of our software. I imagine this is a common problem and there're
probably some neat solutions that we don't know about.
For the last 10 years we have been writing bash shell scripts essentially
G'day all,
We recently had a bit of a catastrophe when one of our postgres databases
opened too many files. It was a reasonably easy fix, but it did get me
thinking. Is there a rule of thumb in determining how many file descriptors
should be available to a postgres database/cluster?
I'd be h
18 matches
Mail list logo
