Regression tests need updating...

I committed some fixes to remove 'current' support from the date/time
types. I *think* that these are now in cvs, but I was unable to see some
of the changes (docs changes especially) when trying to get them back
from the master cvsup server. I'm a bit worried that updating cvs from
cvs.postgresql.org was not the right place to do it (but recall that it
is, so ??).

I think I see your changes now (I have not seen the commit messages
yet, though).

Hi,

Greatbridge had a webpage with some benchmarks that they arranged for.
The site is now gone, does anyone know if there is a copy of the
benchmarks, specifically the graphs.

Dave

Thomas Lockhart <lockhart@fourpalms.org> writes:

I did not update the date/time regression tests to reflect these recent
changes, having run out of time. Tom (or someone) can you please do that
for me?

On it now.

Have a good holiday ...

regards, tom lane

Hi,

Greatbridge had a webpage with some benchmarks that they arranged for.
The site is now gone, does anyone know if there is a copy of the
benchmarks, specifically the graphs.

Oh, I do have the graphs. Here they are.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Hi,

I am running PostgreSQL 7.0.3 on a linux box.

My application uses java/persistence layer/jdbc which does the following
when inserting a row

1) gets a connection from the pool and gets a new id for the row using
select nextval('sequence');
2) returns the connection to the pool
3) gets another connection from the pool and inserts the data into the
row using the id retrieved in step 1
4) returns the connection to the pool

Recently we have had instances where the postmaster has 'crashed' and it
appears that the sequence numbers were not written to disk

After the postmaster restarts we have instances where there are rows in
the database with id's greater than the current sequence value. The
interesting part is that values are always different by 4?

In other words there is a row with an id 1004 and the sequence is
currently 1000?

We are running with fsync on. One thing that has changed lately is we
are running with quite a few buffers?

Any insight would be appreciated,

Dave

Tom,

Ok, we're long overdue for upgrading to 7.1.3 anyway, now I have a real
good excuse to do it.

Dave

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, November 23, 2001 2:22 PM
To: dave@fastcrypt.com
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Problems with sequences

"Dave Cramer" <dave@fastcrypt.com> writes:

I am running PostgreSQL 7.0.3 on a linux box.
Recently we have had instances where the postmaster has 'crashed' and
it appears that the sequence numbers were not written to disk After
the postmaster restarts we have instances where there are rows in the
database with id's greater than the current sequence value. The
interesting part is that values are always different by 4? In other
words there is a row with an id 1004 and the sequence is currently
1000?

If you can reproduce this under 7.1.3 or later I'd be interested in
pursuing it. 7.0 is rapidly attaining the status of "ancient history".
Quite aside from plain old bug fixes, the existence of WAL in 7.1 would
make a huge difference in the possible causes of such a problem.

regards, tom lane

"Dave Cramer" <dave@fastcrypt.com> writes:

I am running PostgreSQL 7.0.3 on a linux box.
Recently we have had instances where the postmaster has 'crashed' and it
appears that the sequence numbers were not written to disk
After the postmaster restarts we have instances where there are rows in
the database with id's greater than the current sequence value. The
interesting part is that values are always different by 4?
In other words there is a row with an id 1004 and the sequence is
currently 1000?

If you can reproduce this under 7.1.3 or later I'd be interested in
pursuing it. 7.0 is rapidly attaining the status of "ancient history".
Quite aside from plain old bug fixes, the existence of WAL in 7.1 would
make a huge difference in the possible causes of such a problem.

regards, tom lane

I did not update the date/time regression tests to reflect these recent
changes, having run out of time. Tom (or someone) can you please do that
for me?

On it now.

Thanks! Not sure if there is more current news; I'm wading through > 700
messages and answering as I go :(

- Thomas