All,I have a large PG 9.1.1 server (over 1TB of data) and replica using log shipping. I had some hardware issues on the replica system and now I am getting the following in my pg_log/* files. Same2 lines over and over since yesterday.2011-12-01 07:46:30 EST LOG: restored log file
the WAL file on the master is long gone, how would one inspect the web segment? Any way to have PG "move" on?On Dec 1, 2011, at 2:02 PM, Jerry Sievers wrote:Jim Buttafuoco j...@contacttelecom.com writes:All,I have a large PG 9.1.1 server (over 1TB of data) and replica using log shipping. I had
Simon,What do you mean, start over with a base backup?JimOn Dec 1, 2011, at 4:08 PM, Simon Riggs wrote:On Thu, Dec 1, 2011 at 7:09 PM, Jim Buttafuoco j...@contacttelecom.com wrote:
the WAL file on the master is long gone, how would one inspect the web segment? Any way to have PG "
Rebuild from source and DO NOT specify --with-openssl
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tom Dong
Sent: Saturday, January 27, 2007 12:16 PM
To: pgsql-hackers@postgresql.org
Cc: Tom Dong
Subject: [HACKERS] How to configure Postgres to make it not to
/3A0F605C is not satisfied --- flushed only to
1F1
/57CD76FC
CONTEXT: writing block 3387032 of relation 3717272/4158444/4158627
_
Jim Buttafuoco
Contact Telecom LLC
Office: 603-647-7170
Fax: 603-606-4243
Cell: 603-490-3409
Hackers,
I have been loading 200+ million call records into a new Postgresql 8.1.4
install. Everything has been going great
until a couple of minutes ago. After the process loads a single file (300k to
500k records), it summaries the data into
a summary table. I have been getting the
I have an issue with pg_dump and inherits with pg 8.1.3 and 8.1.4
if I run the following SQL
create table t (a text check (a = '*'));
create table s () inherits (t);
alter table s drop constraint t_a_check;
alter table s add constraint a_check check (a='s');
I get the following
Table
from time to time I have to drop a very large database (1TB+). The drop
database command takes a long time to complete
while its deleting the files. During this time, no one can connect to the
database server, ps displays startup
waiting. This is with Postgresql 7.4. Has this been addressed
: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Wed, 03 May 2006 14:23:08 -0400
Subject: Re: [HACKERS] drop database command blocking other connections
Jim Buttafuoco [EMAIL PROTECTED] writes:
from time to time I have to drop a very large database (1TB+). The drop
database command takes
Subject: Re: [HACKERS] drop database command blocking other connections
On 5/3/06, Jim Buttafuoco [EMAIL PROTECTED] wrote:
from time to time I have to drop a very large database (1TB+). The drop
database command takes a long time to
complete
while its deleting the files. During this time
# select version();
version
PostgreSQL 8.1.3 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.5 (Debian
1:3.3.5-13)
(1 row)
simple example:
# create type a
if we had a pg_vacuum table that had the last timestamp of a vacuum/analyze for
each table and the stats looked like
the default, why not just print a warning message out to the user?
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Peter Eisentraut [EMAIL
@postgresql.org
Sent: Mon, 09 Jan 2006 08:55:06 +0100
Subject: Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working
Jim Buttafuoco wrote:
Hackers,
I can confirm that HEAD does not initdb because of a SIGBUS as reported
below by Martin Pitt @ debian (see his email
below). My
PROTECTED]
To: pgsql-hackers pgsql-hackers@postgresql.org
Cc: [EMAIL PROTECTED]
Sent: Mon, 09 Jan 2006 15:03:28 +0100
Subject: Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working
Jim Buttafuoco wrote:
Stefan,
first i would ask you to fix your mailserver setup because my last
k091GQxs027867
for [EMAIL PROTECTED]; Sun, 8 Jan 2006 20:16:26 -0500
From: Jim Buttafuoco [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working
on mips[el]?
Date: Sun, 8 Jan 2006 20:16:26 -0500
Martin,
I have installed the Sarge binutils on my testing/Etch system and all of the
Postgresql regression test pass. I
don't know where to go from here, any suggestions?
Jim
-- Original Message ---
From: Martin Pitt [EMAIL PROTECTED]
To: Jim Buttafuoco [EMAIL PROTECTED
Hackers,
I can confirm that HEAD does not initdb because of a SIGBUS as reported below
by Martin Pitt @ debian (see his email
below). My build farm member (corgi) did pass all checks 6 days ago (I was
having some issues with the build farm
code before that). If anyone would like to SSH into
Tom,
On corgi (debian sarge)
raq:~# bison -V
bison (GNU Bison) 1.875a
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: pgsql-hackers@postgresql.org
Sent: Mon, 02 Jan 2006 12:54:42 -0500
Subject: [HACKERS] What bison versions are installed on buildfarm machines?
try this, i had no data to check the plan and didn't have time to invent any.
Jim
create index idx_archive_jb_idx on
archive_event(inst,utctime,src,bid,tid);
explain
SELECT count(cid) AS hits,src, bid,
tid,
(select MIN(utctime)
from archive_event
where src = ae.src
AND bid =ae.bid
AND tid =
while you are at it, can you put in some audit timestamps as to when the vacuum
occurred (full vs not full).
-- Original Message ---
From: Alvaro Herrera [EMAIL PROTECTED]
To: Hackers pgsql-hackers@postgresql.org
Sent: Wed, 14 Sep 2005 22:14:23 -0400
Subject: [HACKERS]
Hackers,
I had a system crash today. When Postgresql started I had the following in my
pg.log file.
2005-08-06 14:14:26 [3352] LOG: database system was interrupted at 2005-08-06
11:57:28 EDT
2005-08-06 14:14:26 [3352] LOG: checkpoint record is at 5E5/9CAEA594
2005-08-06 14:14:26 [3352] LOG:
thanks
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Sat, 06 Aug 2005 17:24:46 -0400
Subject: Re: [HACKERS] unexpected pageaddr on startup/recovery
Jim Buttafuoco [EMAIL PROTECTED] writes
Tom,
I agree with NOT fixing the tsearch2 code for this failure in 7.4. I have left
penguin building 7.4 just to see if the
core code continues to compile. I would be nice if the build farm code would
let me exclude a contrib module if
necessary. What do you think Andrew?
Jim
--
Jim Buttafuoco wrote:
Tom,
I agree with NOT fixing the tsearch2 code for this failure in 7.4. I have
left penguin building 7.4 just to see if the
core code continues to compile. I would be nice if the build farm code
would let me exclude a contrib module if
necessary. What do you
Why doesn't the regression test set the timezone to GMT instead of PST. I
believe the horology test would just work then.
Jim
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Michael Glaesemann [EMAIL PROTECTED]
Cc: PostgreSQL-development Hackers
Andrew,
I can confirm that the latest cygwin snapshot (cygwin1-20050328.dll) corrects
the stats regression failure.
Jim
-- Original Message ---
From: Andrew Dunstan [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], pgsql-hackers@postgresql.org
Sent: Wed,
Andrew,
I can set one up a dedicated windows XP system on monday. I also have some w2k
systems that can be used.Are there
directions anywhere?
Jim
-- Original Message ---
From: Andrew Dunstan [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: PostgreSQL-development
All,
I had to abort a vacuum full after 36 hours on a large table (16 million rows).
I started the vacuum again and after
10 minutes in got to the place I aborted it (control-c) yesterday. I recieved
the following error
ERROR: could not open segment 3 of relation emi_110101_idx1 (target
After I do a vacuum full, I will run memtest and some disk diags.
Thanks
Jim
-- Original Message ---
From: Gavin Sherry [EMAIL PROTECTED]
To: Jim Buttafuoco [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Sat, 26 Mar 2005 11:02:39 +1100 (EST)
Subject: Re
Its there a reason postgresql doesn't record vacuum/analyze and dump times in
pg_class (or another table). This seems
like it would be a very helpful feature.
for pg_dump I would add an option --record=YES|NO
for vacuum and analyze I would add a NORECORD|RECORD option
Jim
thinking of
using these dates as a check that the
automated processes are working.
Jim
-- Original Message ---
From: Heikki Linnakangas [EMAIL PROTECTED]
To: Jim Buttafuoco [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Sent: Mon, 7 Mar 2005 20:35:21 +0200 (EET)
Subject: Re
]
Cc: pgsql-hackers@postgresql.org
Sent: Mon, 07 Mar 2005 13:56:04 -0500
Subject: Re: [HACKERS] Recording vacuum/analyze/dump times
Jim Buttafuoco wrote:
Its there a reason postgresql doesn't record vacuum/analyze and dump times
in pg_class (or another table). This seems
like it would
think vacuum and analyze
should update the autovacuum table this way autovacuum won't redundantly
vacuum tables that were just vacuumed manually.
Jim Buttafuoco wrote:
But what happens if I go in and manually vacuum a table (either because I
just deleted a bunch of records or
whatever
Andrew,
A couple of things,
1. we need to develop a matrix of systems/os/compiler to see what coverage we
do have and compare it to the INSTALL
guide.
2. the run_build.pl should be changed to keep the information on the system to
date (and have the matrix in 1 change)
3. have the
.
Jim
-- Forwarded Message ---
From: Jim Buttafuoco [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 1 Feb 2005 17:20:17 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc
Tom,
The issue
on these platforms?
Jim
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 08 Feb 2005 10:25:26 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc
Jim Buttafuoco [EMAIL
test failed on linux parisc
Jim Buttafuoco [EMAIL PROTECTED] writes:
this test is likely to fail. I have now seen this on my real old Alpha
and now HP PARISC systems.
It works fine on PARISC, and has ever since I've been associated with
this project --- I run these tests multiple times
I am getting a float4 regression test failure. I have extracted the SQL from
both the float4 and float8 tests below.
Both should return NAN
I looked at the code, The float4div does the operation as float8's then checks
the value. The value is a valid
float8 NAN. The call to
Buttafuoco [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Tue, 01 Feb 2005 12:06:30 -0500
Subject: Re: [HACKERS] float4 regression test failed on linux parisc
Jim Buttafuoco [EMAIL PROTECTED] writes:
I am getting a float4 regression test failure. I have extracted the SQL
: [HACKERS] float4 regression test failed on linux parisc
Jim Buttafuoco [EMAIL PROTECTED] writes:
Change:
CheckFloat4Val(result);
To:
CheckFloat4Val((float4)result);
CheckFloat4Val is defined to take a double, so whatever the above is
accomplishing is wrong: probably it's
hackers,
I am having a problem with table (identified by pg_dump). I get the follow
error when I try to COPY the table to
stdout (or /dev/null).
DB=# copy rnk to '/dev/null';
ERROR: could not access status of transaction 1076101119
DETAIL: could not open file
I just upgraded to 7.4.6 and have the same error message.
-- Original Message ---
From: Jim Buttafuoco [EMAIL PROTECTED]
To: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Sat, 22 Jan 2005 09:35:02 -0500
Subject: [HACKERS] pg_clog problem (PG version 7.4.5)
hackers,
I
: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Sat, 22 Jan 2005 08:00:25 -0800
Subject: Re: [HACKERS] pg_clog problem (PG version 7.4.5)
Jim Buttafuoco wrote:
hackers,
I am having a problem with table (identified by pg_dump). I get the follow
error when I try to COPY the table to
stdout
PROTECTED]
To: Jim Buttafuoco [EMAIL PROTECTED]
Cc: Joshua D. Drake [EMAIL PROTECTED], pgsql-hackers
pgsql-hackers@postgresql.org
Sent: Sat, 22 Jan 2005 15:07:35 -0300
Subject: Re: [HACKERS] pg_clog problem (PG version 7.4.5)
On Sat, Jan 22, 2005 at 12:06:46PM -0500, Jim Buttafuoco wrote:
didn't
for the help
Jim
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Alvaro Herrera [EMAIL PROTECTED], pgsql-hackers
pgsql-hackers@postgresql.org
Sent: Sat, 22 Jan 2005 13:41:04 -0500
Subject: Re: [HACKERS] pg_clog problem (PG version 7.4.5)
Jim Buttafuoco
Postgres on one of my big database servers just crashed with the following
message
PANIC: right sibling's left-link doesn't match
Does any one have any idea's what might cause this.
Some background. This is a Debian Sarge system running PG 7.4.5 on i386 dual
XEON system with 4G of
:11 -0500
Subject: Re: [HACKERS] PANIC: right sibling's left-link doesn't match
Jim Buttafuoco [EMAIL PROTECTED] writes:
Postgres on one of my big database servers just crashed with the following
message
PANIC: right sibling's left-link doesn't match
Does any one have any idea's what
Eisentraut [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers pgsql-hackers@postgresql.org
Sent: Thu, 6 Jan 2005 10:18:58 +0100
Subject: Re: [HACKERS] CSV arm check failure
Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
ARM platform fails the point test see below.
For the 7.4
-hackers@postgresql.org
Sent: Thu, 6 Jan 2005 15:26:05 +0200
Subject: Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
ARM platform fails the point test see below.
For the 7.4
PROTECTED]
Cc: [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org
Sent: Thu, 6 Jan 2005 15:26:05 +0200
Subject: Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
ARM
Marko,
See my email with test program. I will recompile the kernel and get back to
the list
Jim
-- Original Message ---
From: Marko Kreen marko@l-t.ee
To: Jim Buttafuoco [EMAIL PROTECTED]
Cc: Peter Eisentraut [EMAIL PROTECTED], pgsql-hackers
pgsql-hackers@postgresql.org
---
From: Marko Kreen marko@l-t.ee
To: Jim Buttafuoco [EMAIL PROTECTED]
Cc: Peter Eisentraut [EMAIL PROTECTED], pgsql-hackers
pgsql-hackers@postgresql.org
Sent: Thu, 6 Jan 2005 17:25:20 +0200
Subject: Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 10:21:43AM -0500, Jim Buttafuoco
-hackers@postgresql.org
Sent: Mon, 3 Jan 2005 22:56:22 +0100
Subject: Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 3
Jim Buttafuoco wrote:
I also don't see MIPSEL and ARM on the list, both running debian
sarge (in the build farm).
The mips entry is actually a mipsel, but uname
: Robert Treat [EMAIL PROTECTED], pgsql-hackers@postgresql.org
Sent: Tue, 4 Jan 2005 15:07:38 +0100
Subject: Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 3
Am Dienstag, 4. Januar 2005 14:53 schrieb Jim Buttafuoco:
I have both a MIPS and MIPSEL in the buildfarm. i have also reported
ARM platform fails the point test see below.
parallel group (13 tests): text name char boolean varchar oid int8 int2 float4
int4 float8 bit numeric
boolean ... ok
char ... ok
name ... ok
varchar ... ok
text
I also don't see MIPSEL and ARM on the list, both running debian sarge (in the
build farm).
Jim
-- Original Message ---
From: Robert Treat [EMAIL PROTECTED]
To: pgsql-hackers@postgresql.org
Sent: 03 Jan 2005 08:35:19 -0500
Subject: Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.0.0
, and thereby be holding
an open file pointer for it. On standard Unix filesystems this would
not disrupt the backend's ability to unlink the table at the DROP stage,
but I'm wondering about nonstandard filesystems ...
Jim Buttafuoco reported on December 16th that he had rebuilt
Tom,
my systems are all EXT3 (Debian 3.1) (andrew can tell you which ones they are).
Jim
-- Original Message ---
From: Tom Lane [EMAIL PROTECTED]
To: Andrew Dunstan [EMAIL PROTECTED]
Cc: Kurt Roeckx [EMAIL PROTECTED], PostgreSQL-development
pgsql-hackers@postgresql.org
Sent:
I have rebuild the filesystem on my indy (MIPS) that Andrew reported on. The
first run completed 100%, I would give
it a couple more runs before we can say its the filesystem not Postgresql that
was causing the drop to fail.
-- Original Message ---
From: Andrew Dunstan
Just compiled RC1 on a netwinder ARM system running Debian Linux (sarge). All
tests passed except point with the
following in results/point
Jim
--
-- POINT
--
CREATE TABLE POINT_TBL(f1 point);
INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
show the differences.
---
Jim Buttafuoco wrote:
Just compiled RC1 on a netwinder ARM system running Debian Linux (sarge).
All tests passed except point with
the
following in results/point
Jim
Tom/all,
I have setup the following running debian linux. MIPS, MIPSEL, ALPHA, PARISC,
M68K, ARM, SPARC, I386. I have the
build farm running local and I have just started to get the systems registered.
I am also willing to aquire other
hardware/ operating systems in an effort to give
I am still having this problem with the latest CSV snapshot. Is anyone else running
on an Alpha. Can any of the
hackers point me to where in the code this might be failing?
Thanks
Jim
-- Forwarded Message ---
From: Jim Buttafuoco [EMAIL PROTECTED]
To: pgsql-hackers [EMAIL
just to follow up.
On i386/mipsel/mips I get the following for pow(10,309)
ERROR: result is out of range
on alpha, I get 3.09434604738258e-308
-- Original Message ---
From: Jim Buttafuoco [EMAIL PROTECTED]
To: pgsql-hackers [EMAIL PROTECTED]
Sent: Wed, 3 Nov 2004 08:44:02
Hi all,
I am getting a regression failure on float8 (and float4) when running on Debian Sarge
on Alpha (gcc 3.3.4). Postgres
is a HEAD checkout from yesterday.
test=# select version();
version
Buskermolen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers [EMAIL PROTECTED]
Sent: Thu, 28 Oct 2004 10:35:04 -0700
Subject: Re: [HACKERS] Beta 4 on Debian Sarge (MIPS/MIPSEL)
On October 27, 2004 05:57 pm, Jim Buttafuoco wrote:
Hackers,
just an fyi, Beta 4 passed ALL tests on Debian Sarge
Hackers,
just an fyi, Beta 4 passed ALL tests on Debian Sarge for both MIPS (Indy) and MIPSEL
(Cobalt RAQ)
I can test Debian Sarge Sparc, Alpha, PowerPC, PA-RISC and M68K if no one else has
reported on these systems yet.
Also, with a little work I could test Solaris, Tru64 (or what ever its
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
crash - invalid page header messages in log
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
: [HACKERS] beta 1 failed on linux mipsel
Jim Buttafuoco [EMAIL PROTECTED] writes:
I have confirmed that 7.4.3 works on the cobalt raq mipsel system. I
have not looked at the s_lock.[ch] code as I have not coded in C for
years and don't know the backend code very well. Do you have any
trying to test beta 1 on Debian linux mipsel (sarge). I am getting the following
error PANIC: stuck spinlock
(0x2b052030) detected at lwlock.c:246 during initdb. here is the complete initdb run.
[EMAIL PROTECTED]:~$ initdb
The files belonging to this database system will be owned by user
Message ---
From: Tom Lane [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: pgsql-hackers [EMAIL PROTECTED]
Sent: Sun, 29 Aug 2004 15:27:32 -0400
Subject: Re: [HACKERS] beta 1 failed on linux mipsel
Jim Buttafuoco [EMAIL PROTECTED] writes:
trying to test beta 1 on Debian linux mipsel (sarge
All,
Just started an upgrade from 7.2.X to 7.4.2. I am getting the following PANIC when
loading the data from a 7.2.4 db
using 7.4.2 pg_dump via a pipe
pg_dump -h bda4c OLD_DB |psql -h bda5 -e NEW_DB
bda4c isPostgreSQL 7.2.4 on i686-pc-linux-gnu, compiled by GCC 2.95.4
bda5 is
Would the plan be to add it to pg_ctl?
Andrew Sullivan [EMAIL PROTECTED] writes:
Is anyone interested in having pglog-rotator?
FWIW, I saw an early version of pglog-rotator about a year and a half
ago (while consulting for LibertyRMS), and thought at the time that
it was pretty cool. So
Is this NOT what I have been after for many months now. I dropped the
tablespace/location idea before 7.2 because that
didn't seem to be any interest. Please see my past email's for the SQL commands and
on disk directory layout I have
proposed. I have a working 7.2 system with
Just wanted to pipe in here. I am still very interested in tablespaces ( I have many
database systems that are over
500GB and growing) and am willing to port my tablespace patch to 7.4. I have
everything (but only tested here) working
in 7.2 but the patch was not accepted. I didn't see a
Hi all,
I started getting these errors today on my test database (pg
7.2.1). I have been vacuum/reindex/analyze(ing) the table
all day (after updating 10+ rows) and wondering what
could have caused this.
Thanks
Jim
2002-05-19 18:16:18 [1673] NOTICE:
I have used Oracle SQLOADER for many years now. It has the ability to
put rejects/discards/bad into an output file and keep on going, maybe
this should be added to the copy command.
COPY [ BINARY ] table [ WITH OIDS ]
FROM { 'filename' | stdin }
[ [USING] DELIMITERS 'delimiter' ]
Vadim,
I guess I am still confused...
In dbcommands.c resolve_alt_dbpath() takes the db oid as a argument.
This number is used to find the directory where the data files live.
All the patch does is put the indexes into a db oid_index directory
instead of db oid
This is for tables
Yes that is exactly what I am going to do for 7.3 (had trouble adding
tblNode to pg_class so I stopped for now...)
Can you explain how I would get the tblNode for an existing database
index files if it doesn't have the same OID as the database entry
in
pg_databases.
Well, keeping in
All,
Just wondering what is the status of this patch. Is seems from comments
that people like the idea. I have also looked in the archives for other
people looking for this kind of feature and have found alot of interest.
If you think it is a good idea for 7.2, let me know what needs to be
just change the work tablespace below to location and that is exactly
what this patch is trying to do. You can think of the LOCATION and
INDEX_LOCATION provided to the create database command as the default
storage locations for these objects. In the future, I want to enable
the DBA to specify
I agree that groups of objects in separate data storage areas are needed
and that is what I am trying to get to. Don't you think that Postgresql
with locations/files is the same as Oracle tablespaces. I don't think
we want to invent our own filesystem (which is what a tablespace really
is...).
Vadim,
I don't understand the WAL issue below, can you explain. The dir name
is the same name as the database with _index added to it. This is how
the current datpath stuff works. I really just copied the datpath code
to get this patch to work...
Also I have been running this patch (both
I could also symlink all index files back to the tblnode directory?
I don't understand the WAL issue below, can you explain. The dir
name
is the same name as the database with _index added to it. This is
how
the current datpath stuff works. I really just copied the datpath
code to get
Moving the test to a system with SCSI disks gave different results.
There is NO difference between having the indexes on the same disk or
different disk with the data while running pgbench. So I leave it up to
you guys as to include the patch or not. I do believe that even if
performance
Hi all,
Attached is a patch that adds support for specifying a location for
indexes via the create database command.
I believe this patch is complete, but it is my first .
Thanks
Jim
location.diffs
---(end of broadcast)---
TIP 2: you can
All,
I am working a some patches to the code and I noticed that pg_dump -C
database doesn't provide the database location information in the dump
file. Is this correct?
Thanks
Jim
Example:
datname | datdba | encoding | datistemplate | datallowconn |
datlastsysoid | datpath | idxpath
All,
I am working a some patches to the code and I noticed that pg_dump -C
database doesn't provide the database location information in the dump
file. Is this correct?
Thanks
Jim
Example:
datname | datdba | encoding | datistemplate | datallowconn |
datlastsysoid | datpath | idxpath
will do.
Jim Buttafuoco writes:
I am working a some patches to the code and I noticed that pg_dump
-C
database doesn't provide the database location information in the
dump
file. Is this correct?
Your observation is correct, but the behaviour is not. Feel free to
send a patch
All,
I am working a some patches to the code and I noticed that pg_dump -C
database doesn't provide the database location information in the dump
file. Is this correct?
Thanks
Jim
Example:
datname | datdba | encoding | datistemplate | datallowconn |
datlastsysoid | datpath | idxpath
(sorry for the repost. I forgot the subject last time...)
All,
I am working a some patches to the code and I noticed that pg_dump -C
database doesn't provide the database location information in the dump
file. Is this correct?
Thanks
Jim
Example:
datname | datdba | encoding |
Hi all (I hope this is the correct list),
Under Oracle there is v$parameter which list ALL config varables. Under
psql there is the SHOW command, but this only lists 1 variable. I have
written a shell script (attached) that shows ALL know variables. My
questions is can this script get
Hi all (I hope this is the correct list),
Under Oracle there is v$parameter which list ALL config varables. Under
psql there is the SHOW command, but this only lists 1 variable. I have
written a shell script (attached) that shows ALL know variables. My
questions is can this script get
I was looking for some way via standard SQL (I use perl DBI) to list
these variables. I don't believe the SHOW command is available via DBI
Jim
I think the way to do this is for SHOW ALL to show all setttings.
[ Charset ISO-8859-1 unsupported, converting... ]
Hi all (I hope this is
This seems to work for me. I used the snapshot from 3/28 on Solaris 8
SELECT service, count(*) AS GebruikersAantal
FROM tbtrouble GROUP BY service;
service | gebruikersaantal
---+--
Service 1 |2
Service 3 |2
Service 4 |
Time to speak up, I have a HPUX 9.07 system and will test today.
Jim
Thomas Lockhart [EMAIL PROTECTED] writes:
HPUX 10.20 (HP-PA architecture)
Time to drop 9.2 from the list?
I don't have it running here anymore. Is there anyone on the list
who can test on HPUX 9?
HPUX 9.07 with GCC 2.8.1 fails the regression tests. I will look into
this later. I would NOT hold anything up because of this
Jim
Time to speak up, I have a HPUX 9.07 system and will test today.
Jim
Thomas Lockhart [EMAIL PROTECTED] writes:
HPUX 10.20 (HP-PA
98 matches
Mail list logo
