[HACKERS] Postgresql 9.1 replication failing

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.  Same 2 lines over and over since yesterday.2011-12-01 07:46:30 EST  >LOG:  restored log file "0001000

Re: [HACKERS] Postgresql 9.1 replication failing

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 writes:All,I have a large PG 9.1.1 server (over 1TB of data) and replica using log shipping.  I had

Re: [HACKERS] Postgresql 9.1 replication failing

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 &qu

[HACKERS] bt_fixroot: not valid old root page

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: bt_getroot[billed_features_btn_idx

Re: [HACKERS] How to REINDEX in high volume environments?

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 grea

Re: Table spaces again [was Re: [HACKERS] Threaded Sorting]

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 tablespaces/loc

[HACKERS] Fw: Running config vars

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 include

Re: [HACKERS] Fw: Running config vars

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 t

[HACKERS] Running config vars

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 included

[HACKERS]

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 -

[HACKERS] pg_dump -C and locations (with subject this time)

(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 | datistemp

[HACKERS] pg_dump -C option

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 -

[HACKERS] PG_DUMP -C option

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 --

[HACKERS] Index location patch for review

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

Re: [HACKERS] pg_dump -C option

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 cor

Re: [HACKERS] Index location patch for review

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

Re: [HACKERS] Index location patch for review

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...).

Re: [HACKERS] Index location patch for review

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 7.1.

Re: [HACKERS] Index location patch for review

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

Re: [HACKERS] Index location patch for review

Here is my pgbench results. As you can see the I am getting 2X tps with the 2 directories. I believe this is a BIG win for Postgresql if we can figure out the WAL recovery issues. Can someone other than me apply the patch and verify the pgbench results. My hardward setup is a dual processor

Re: [HACKERS] Index location patch for review (more pgbench results)

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 doesn'

[HACKERS] Status of index location patch

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 cha

Re: [HACKERS] Status of index location patch

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 snpr

Re: [HACKERS] Status of index location patch

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, keepi

Re: [HACKERS] Bulkloading using COPY - ignore duplicates?

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' ]

Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...

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? >

Re: [HACKERS] Re: Final Call: RC1 about to go out the door ...

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

Re: [HACKERS] Problem with group by in conjuction with Views

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 |

Re: [HACKERS] more contrib: log rotator

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 c

[HACKERS] xlog flush request not satisfied after server reboot

--- ERROR: xlog flush request 1F6/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

Re: [HACKERS] How to configure Postgres to make it not to use (load) crypto libraries.

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 u

[HACKERS] pg_dump and inherits issue

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 "public

[HACKERS] ERROR: could not open relation with OID 909391158

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 followin

[HACKERS] Missing segment 3 of index

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 b

Re: [HACKERS] Missing segment 3 of index

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 Sent: Sat, 26 Mar 2005 11:02:39 +1100 (EST) Subject: Re: [HACK

Re: [HACKERS] minor windows & cygwin regression failures on stable

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 Sen

Re: [HACKERS] minor windows & cygwin regression failures on stable

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: W

Re: [HACKERS] BuildFarm status: recent check failures

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 Sent: Mon, 0

Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch

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 -- O

Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch

should > mean that machine passed the whole test suite. > > cheers > > andrew > > 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 >

[HACKERS] unexpected pageaddr on startup/recovery

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:

Re: [HACKERS] unexpected pageaddr on startup/recovery

thanks -- Original Message --- From: Tom Lane <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: "pgsql-hackers" Sent: Sat, 06 Aug 2005 17:24:46 -0400 Subject: Re: [HACKERS] unexpected pageaddr on startup/recovery > "Jim Buttafuoco" <[EMAIL PROTECTE

[HACKERS] PANIC: hash table "Shared Buffer Lookup Table" corrupted

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 isPostgre

[HACKERS] beta 1 failed on linux mipsel

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 "p

Re: [HACKERS] beta 1 failed on linux mipsel

-- Original 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 PROTECTE

Re: [HACKERS] beta 1 failed on linux mipsel

ok, will look at it in the morning. -- Original Message --- From: Tom Lane <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: "pgsql-hackers" <[EMAIL PROTECTED]> Sent: Sun, 29 Aug 2004 21:42:57 -0400 Subject: Re: [HACKERS] beta 1 failed on linux mipsel >

Re: [HACKERS] Analyze and vacuum, they are sort of mandatory....

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 PROTE

[HACKERS] create type error message

# 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 a

[HACKERS] drop database command blocking other connections

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

Re: [HACKERS] drop database command blocking other connections

ED] Cc: "pgsql-hackers" 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

Re: [HACKERS] drop database command blocking other connections

ubject: 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

Re: [HACKERS] Per-table freeze limit proposal

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 Sent: Wed, 14 Sep 2005 22:14:23 -0400 Subject: [HACKERS] Per-table freeze limit proposal >

Re: [HACKERS] (View and SQL) VS plpgsql

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 =

Re: [HACKERS] What bison versions are installed on buildfarm machines?

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? >

[HACKERS] Fw: Is anyone interested in getting PostgreSQL working on mips[el]?

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

Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working

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

Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working

<[EMAIL PROTECTED]> To: pgsql-hackers 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 m

Re: [HACKERS] Fw: Is anyone interested in getting PostgreSQL working

I see that also, What I am testing now, it downgrading gcc to the sarge versions. If it works on testing then I know it's a gcc issue. Jim -- Original Message --- From: Kurt Roeckx <[EMAIL PROTECTED]> To: Stefan Kaltenbrunner <[EMAIL PROTECTED]> Cc: pgsql-hackers , [EMAIL PRO

[HACKERS] Fw: Returned mail: see transcript for details

a.contactbda.com (8.12.11/8.12.11/Debian-3) with ESMTP id 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

Re: [HACKERS] Is anyone interested in getting PostgreSQL working on mips[el]?

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 Buttafu

Re: [HACKERS] beta 1 failed on linux mipsel

MAIL PROTECTED]> Sent: Mon, 30 Aug 2004 13:23:03 -0400 Subject: Re: [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.[c

[HACKERS] System crash - invalid page header messages in log

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

Re: [HACKERS] System crash - invalid page header messages in log

Subject: Re: [HACKERS] System 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 O

[HACKERS] Beta 4 on Debian Sarge (MIPS/MIPSEL)

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 ca

Re: [HACKERS] Beta 4 on Debian Sarge (MIPS/MIPSEL)

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, > > > &

[HACKERS] float4/float8 regression failure on Alpha Linux

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

[HACKERS] Fw: float4/float8 regression failure on Alpha Linux

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

Re: [HACKERS] Fw: float4/float8 regression failure on Alpha Linux

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 PROTECT

Re: Buildfarm coverage (was Re: [HACKERS] OK, ready for RC1 or Beta6)

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 somethi

[HACKERS] arm rc1 regression failures

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)');

Re: [HACKERS] arm rc1 regression failures

ion.diff? That should show the differences. > > ------- > > Jim Buttafuoco wrote: > > Just compiled RC1 on a netwinder ARM system running Debian Linux (sarge). > > All tests passed except "poin

Re: [Fwd: Re: [HACKERS] race condition for drop schema cascade?]

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 <[EM

Re: [HACKERS] race condition for drop schema cascade?

;The theory that is in my mind is that the bgwriter could have written > >out a page for the table in the test tablespace, 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 DR

Re: [HACKERS] race condition for drop schema cascade?

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 Sent: Wed, 29 Dec 2004 12:26:5

Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 3

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 Rel

Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 3

PROTECTED]>, pgsql-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). > &g

Re: [HACKERS] [ANNOUNCE] PostgreSQL 8.0.0 Release Candidate 3

To: [EMAIL PROTECTED] Cc: 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 M

[HACKERS] CSV arm check failure

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

Re: [HACKERS] CSV arm check failure

Eisentraut <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: "pgsql-hackers" 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

Re: [HACKERS] CSV arm check failure

ent: 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. > >

Re: [HACKERS] CSV arm check failure

To: Peter Eisentraut <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], pgsql-hackers 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 But

Re: [HACKERS] CSV arm check failure

Marko, See my email with test program. I will recompile the kernel and get back to the list Jim -- Original Message --- From: Marko Kreen To: Jim Buttafuoco <[EMAIL PROTECTED]> Cc: Peter Eisentraut <[EMAIL PROTECTED]>, pgsql-hackers Sent: Thu, 6 Jan 2005 16

Re: [HACKERS] CSV arm check failure

ssage --- From: Marko Kreen To: Jim Buttafuoco <[EMAIL PROTECTED]> Cc: Peter Eisentraut <[EMAIL PROTECTED]>, pgsql-hackers 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 wrote: > > I

[HACKERS] PANIC: right sibling's left-link doesn't match

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 memory.

Re: [HACKERS] PANIC: right sibling's left-link doesn't match

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-lin

[HACKERS] pg_clog problem (PG version 7.4.5)

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 "/usr/local/pgsql/data/pg_clog/0

Re: [HACKERS] pg_clog problem (PG version 7.4.5)

I just upgraded to 7.4.6 and have the same error message. -- Original Message --- From: "Jim Buttafuoco" <[EMAIL PROTECTED]> To: "pgsql-hackers" Sent: Sat, 22 Jan 2005 09:35:02 -0500 Subject: [HACKERS] pg_clog problem (PG version 7.4.5) > hacker

Re: [HACKERS] pg_clog problem (PG version 7.4.5)

ECTED]> To: [EMAIL PROTECTED] Cc: pgsql-hackers 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 >

Re: [HACKERS] pg_clog problem (PG version 7.4.5)

Alvaro Herrera <[EMAIL PROTECTED]> To: Jim Buttafuoco <[EMAIL PROTECTED]> Cc: "Joshua D. Drake" <[EMAIL PROTECTED]>, pgsql-hackers 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:46P

Re: [HACKERS] pg_clog problem (PG version 7.4.5)

ks for the help Jim -- Original Message --- From: Tom Lane <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Alvaro Herrera <[EMAIL PROTECTED]>, "pgsql-hackers" Sent: Sat, 22 Jan 2005 13:41:04 -0500 Subject: Re: [HACKERS] pg_clog problem (PG version 7.4.5) >

Re: [HACKERS] cvs TIP, tsearch2 and Solaris 8 Sparc

seems to have fixed my arm problem that you (Tom) looking into the other day. Jim -- Original Message --- From: Tom Lane <[EMAIL PROTECTED]> To: Darcy Buskermolen <[EMAIL PROTECTED]> Cc: pgsql-hackers@postgresql.org Sent: Wed, 26 Jan 2005 13:50:11 -0500 Subject: Re: [HACKERS] cvs

[HACKERS] float4 regression test failed on linux parisc

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 CheckFloat4Val

Re: [HACKERS] float4 regression test failed on linux parisc

ROTECTED]> To: "Jim Buttafuoco" <[EMAIL PROTECTED]> Cc: "pgsql-hackers" 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

Re: [HACKERS] float4 regression test failed on linux parisc

-0500 Subject: Re: [HACKERS] float4 regression test failed on linux parisc > "Jim Buttafuoco" <[EMAIL PROTECTED]> writes: > > Change: > > CheckFloat4Val(result); > > To: > > CheckFloat4Val((float4)result); > > CheckFloat4Val is defined to ta

Fw: Re: [HACKERS] float4 regression test failed on linux parisc

em and solution. Jim -- Forwarded Message ------- From: "Jim Buttafuoco" <[EMAIL PROTECTED]> To: Tom Lane <[EMAIL PROTECTED]> Cc: "pgsql-hackers" Sent: Tue, 1 Feb 2005 17:20:17 -0500 Subject: Re: [HACKERS] float4 regression test failed on linux pari

Re: [HACKERS] float4 regression test failed on linux parisc

these platforms? Jim -- Original Message --- From: Tom Lane <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: "pgsql-hackers" Sent: Tue, 08 Feb 2005 10:25:26 -0500 Subject: Re: [HACKERS] float4 regression test failed on linux parisc > "Jim Buttafuoco&quo

Re: [HACKERS] float4 regression test failed on linux parisc

S] float4 regression 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 be

Re: [HACKERS] buildfarm issues

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 run_build.p

[HACKERS] Recording vacuum/analyze/dump times

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 ---

Re: [HACKERS] Recording vacuum/analyze/dump times

track). I was just 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 2

  1   2   >