[HACKERS] missing pg_clog files ?

2003-09-22 Thread Patrick Welche
There was a thread on missing pg_clog files caused due to dodgy practices in glibc *last year*. I am seeing something similar *now* with a server PostgreSQL 7.4beta1 on i386-unknown-netbsdelf1.6X, compiled by GCC 2.95.3 accessed by a similar client and a client PostgreSQL 7.4devel on

Re: [HACKERS] missing pg_clog files ?

2003-09-22 Thread Tom Lane
Patrick Welche [EMAIL PROTECTED] writes: select * from olddata02_03vac offset 2573719 limit 1; ERROR: could not access status of transaction 1664158221 DETAIL: open of file /usr/local/pgsql/data/pg_clog/0633 failed: No such file or directory # ls -l pg_clog total 32 -rw--- 1

Re: [HACKERS] missing pg_clog files ?

2003-09-22 Thread Patrick Welche
On Mon, Sep 22, 2003 at 10:50:22AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: select * from olddata02_03vac offset 2573719 limit 1; ERROR: could not access status of transaction 1664158221 DETAIL: open of file /usr/local/pgsql/data/pg_clog/0633 failed: No such file

Re: [HACKERS] missing pg_clog files ?

2003-09-22 Thread Tom Lane
Patrick Welche [EMAIL PROTECTED] writes: I hope I guessed the right syntax... % pg_filedump -R 71716 data/base/17148/283342 Yes, but this doesn't give all the available info. Add -i and -f options. A plain -d dump might be interesting too. regards, tom lane

Re: [HACKERS] missing pg_clog files ?

2003-09-22 Thread Patrick Welche
On Mon, Sep 22, 2003 at 11:33:30AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I hope I guessed the right syntax... % pg_filedump -R 71716 data/base/17148/283342 Yes, but this doesn't give all the available info. Add -i and -f options. A plain -d dump might be

Re: [HACKERS] missing pg_clog files ?

2003-09-22 Thread Tom Lane
Patrick Welche [EMAIL PROTECTED] writes: Indeed, the plain -d dump says that I have a chunk of /var/mail/prlw1 in 1000-13ff. No wonder postgres complained! Yipes. We have seen this sort of thing once or twice in the past. I don't know whether you are looking at a disk drive fault (dropping the

Re: [HACKERS] Killing the backend to cancel a long waiting query

2003-09-22 Thread Paulo Scardine
I can implement it as C functions, I think. Would be nice to have something like: Test=# select pg_list_backends(); pid | conn_id | user | database | time | host | status ---+--+--+---+--+---+ 4724 | 35445134 | marcelo |

Re: [HACKERS] missing pg_clog files ?

2003-09-22 Thread Alvaro Herrera
On Mon, Sep 22, 2003 at 05:03:28PM +0100, Patrick Welche wrote: On Mon, Sep 22, 2003 at 11:33:30AM -0400, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: I hope I guessed the right syntax... % pg_filedump -R 71716 data/base/17148/283342 Yes, but this doesn't give all the

Re: [HACKERS] Killing the backend to cancel a long waiting query

2003-09-22 Thread Robert Treat
On Mon, 2003-09-22 at 13:53, Paulo Scardine wrote: I can implement it as C functions, I think. Would be nice to have something like: Test=# select pg_list_backends(); pid | conn_id | user | database | time | host | status

Re: [HACKERS] PostgreSQL not ACID compliant?

2003-09-22 Thread Hannu Krosing
Heikki Tuuri kirjutas P, 21.09.2003 kell 12:51: Tom, - Original Message - From: Tom Lane [EMAIL PROTECTED] To: Heikki Tuuri [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, September 21, 2003 10:32 AM Subject: Re: [HACKERS] PostgreSQL not ACID compliant? Heikki Tuuri

[HACKERS] Back from Mexico

2003-09-22 Thread Bruce Momjian
I am back from speaking in Mexico. I was one of the keynote speakers at this event. This is evidence of how far PostgreSQL has come in just the past year. PostgreSQL is now a must have for most open-source events. FYI, we have lots of PostgreSQL users in Mexico. Catching up on email now. --

[HACKERS] old pgindent change

2003-09-22 Thread Nigel J. Andrews
There was a simple change commited in revision 1.47 of pgindent, listed as being More updates for GNU indent. The questions are: why? and surely I can't be the only one whose hit this problem since November 2001? On a debian (woody or potato, which ever one had a 2.2 series kernal) using GNU

Re: [HACKERS] old pgindent change

2003-09-22 Thread Nigel J. Andrews
On Mon, 22 Sep 2003, Nigel J. Andrews wrote: There was a simple change commited in revision 1.47 of pgindent, listed as being More updates for GNU indent. The questions are: why? and surely I can't be the only one whose hit this problem since November 2001? ... I also had to apply

Re: [HACKERS] More Prelimiary DBT-2 Test Results with PostgreSQL 7.3.4

2003-09-22 Thread Greg Stark
[EMAIL PROTECTED] writes: http://developer.osdl.org/markw/74/ Are those response times in the right unit? 7-10s? Are these mostly full table scans and big batch updates? Personally, I'm more interested in seeing OLTP-oriented benchmarks testing quick index based transactions in the 20-200ms

Re: [HACKERS] Improving REINDEX for system indexes (long)

2003-09-22 Thread Hiroshi Inoue
I've just put back your previous change, sorry. As I already mentioned many times it must be the first thing. Though I don't remenber my code completely yet, I would reply to some points. Unfortunately REINDEX wasn't a eagerly wanted command when I implemented it. Though I

Re: [HACKERS] [GENERAL] Can't Build 7.3.4 on OS X

2003-09-22 Thread Eric Ridge
On Sep 21, 2003, at 9:03 PM, Tom Lane wrote: Eric Ridge [EMAIL PROTECTED] writes: any ideas here? 7.3.2 and 7.4beta3 compile just fine (I noticed that 7.4 has something more cross-platform for tas). What happened in 7.3.4 that broke it? That makes no sense at all --- AFAICT there were *no*

Re: [HACKERS] [GENERAL] Can't Build 7.3.4 on OS X

2003-09-22 Thread E R
On Sep 21, 2003, at 9:03 PM, Tom Lane wrote: That makes no sense at all --- AFAICT there were *no* darwin or ppc specific changes between 7.3.2 and 7.3.4. Can you double check? Not really knowing what I'm doing, I took s_lock.c and s_lock.h from 7.4beta3, copied 'em into the 7.3.4 src tree, and