-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
My version:
ANALYZE;
SELECT n.nspname, relname, reltuples
FROM pg_class c, pg_namespace n
WHERE c.relnamespace=n.oid
AND relkind='r'
AND NOT n.nspname ~ '^pg_'
ORDER BY 1,2;
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200
Folks,
I've noticed that when coming into an organization, I need to do some
counting on what's in all the tables in a db. This shortens that
process considerably, with the usual caveat that count(*) is a heavy
operation.
By the way, the 3 lines following "godawful hack" point to something
PL/Pg
First error know to be caught by the buildfarm - this is one of DarcyB's
test client machines. All the details below were pulled from the
buildfarm test server's database.
This report is from HEAD, but it might also apply to earlier branches.
cheers
andrew
Machine details:
Sola
thanks for the reply. I will do a dump of the databases tonight (around 400GB of data)
Jim
-- Original Message ---
From: Tom Lane <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: "pgsql-hackers" <[EMAIL PROTECTED]>
Sent: Tue, 28 Sep 2004 17:42:04 -0400
Subject: Re: [HACKERS] Syste
On Tue, Sep 28, 2004 at 04:18:44PM -0400, Jim Buttafuoco wrote:
> One of my systems crashed today and when Postgres started it gave the
> following warnings. Is this OK? I am going to find which database
> has these relations and do some checking. It would be nice if the
> startup wal code gave
"Jim Buttafuoco" <[EMAIL PROTECTED]> writes:
> One of my systems crashed today and when Postgres started it gave the
> following warnings. Is this OK?
Should theoretically be OK --- all of those pages were overwritten with
valid data from WAL playback. What you need to worry about more is
whethe
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> According to postgresql.conf, using these settings the lock table eats
> 64*260*100 bytes = < 2M. Well, if it's running my server out of shared
> memory, it's eating much, much more shmem than previously thought.
Hmm, the 260 is out of date I think.
tgl wrote:
> There is a secondary issue here, which is that we don't have provision
> to recycle hash table entries back into the general shared memory pool
> (mainly because there *is* no "shared memory pool", only never-yet-
> allocated space). So when you do release these locks, the freed space
Joshua D. Drake wrote:
Shachar Shemesh wrote:
I have a complaint from an OLE DB user that when he does "select
'a'", he gets an "unhanded type" error. Since OLE DB uses a binary
interface, it has to know about all variable types that pass through it.
The debug information for the problem show th
One of my systems crashed today and when Postgres started it gave the following
warnings. Is this OK? I am going to
find which database has these relations and do some checking. It would be nice if the
startup wal code gave the
database oid also and database version.
Thanks
Jim
select ver
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > In other words, after doing a select user_write_lock_oid(t.oid) from
> > big_table t;
> > It's server restart time.
>
> User locks are not released at transaction failure. Quitting that
> backend should have got you out of it, however.
Right, my
Shachar Shemesh wrote:
I have a complaint from an OLE DB user that when he does "select 'a'",
he gets an "unhanded type" error. Since OLE DB uses a binary interface,
it has to know about all variable types that pass through it.
The debug information for the problem show that the returned type is
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> In other words, after doing a select user_write_lock_oid(t.oid) from
> big_table t;
> It's server restart time.
User locks are not released at transaction failure. Quitting that
backend should have got you out of it, however.
> What's really interes
Tom,
I noticed your recent corrections to lock.c regarding the releasing of
locks in an out of shared memory condition. This may or may not be
relevant, but when I purposefully use up all the lock space with user
locks, the server runs out of shared memory and stays out until it is
restarted (not
I have a complaint from an OLE DB user that when he does "select 'a'",
he gets an "unhanded type" error. Since OLE DB uses a binary interface,
it has to know about all variable types that pass through it.
The debug information for the problem show that the returned type is
705, which is "unknow
Hi!
create table foo (
id int4 primary key,
);
create function bar
returns setof int4
langauge 'C'
as '...'
immutable strict
;
So query:
select foo.* from foo, bar() as b where foo.id=b;
Function foo() always returns ordered values and after first call it knows exact
number o
>Hannu Krosing [mailto:[EMAIL PROTECTED]
> On P, 2004-09-26 at 09:17, Tom Lane wrote:
> > "Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> > > ... So, all this append-only writing leads to files with lots of dead
> > > tuples, so the vacuum command was added to reclaim space.
> >
> > Actually, I
17 matches
Mail list logo
