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 want
[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
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
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 b
http://developer.osdl.org/markw/74/
I had a couple of hiccups doubling the database size,
but I have results with proper linux kernel profile data now. The
increase in database size has decreased the overall performance, as
expected...
I haven't had the opportunity to try different database para
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.
--
I do not know how to do that. I learned that I can send a SIGINT to a
backend to cancel a query, but I dont know how to kill just one transaction.
I have only "pg_getpid" and "pg_killpid" as interfaces to system functions
"getpid" and "kill".
BTW, what information can I get about the current runni
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?
>
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
> ---+--+--+---+
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 gi
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 | test
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 r
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
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
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
--
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
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-
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* da
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 i686-pc-l
19 matches
Mail list logo
