[HACKERS] Re: [CORE] WAL & RC1 status

[Tom Lane]

Vadim Mikheev <[EMAIL PROTECTED]> writes:
>> -- Judging from the commit timestamps surrounding prior
>> -- checkpoints, checkpoints were happening every five
>> -- minutes approximately on the 5-minute mark, so

> You can't count on this: postmaster runs checkpoint
> "maker" in 5 minutes *after* prev checkpoint was created,
> not from the moment "maker" started. And checkpoint can
> take *minutes*.

Good point, although with so little going on (this is the *whole*
relevant section of the log), that seems unlikely.

>> -- here.  But it's worse than that: check the commit
>> -- timestamps and the xid numbers before and after the
>> -- discontinuity.  Did time go backwards here?

> Commit timestamps are created *before* XLogInsert call,
> which can suspend backend for some time (in multi-user
> env). Random xid-s are also ok, generally.

Hmm ... maybe.  Though again, this installation doesn't seem to have
been busy enough to cause a commit to be delayed for very long.

What I realized after posting that analysis is that the last checkpoint
record has SUI 30 whereas the earlier ones have SUI 29 ... so there was
a system restart in there somewhere.  That still leaves me wondering
about the discontinuity and broken back-link, but it may account for
the "missing" checkpoint records --- perhaps they weren't generated
because the system wasn't up the entire interval.

>> -- What's even nastier (and the immediate cause of
>> -- Scott's inability to restart) is that the pg_control
>> -- file's checkPoint pointer points to 0/005AF9F0, which
>> -- is *not* the location of this checkpoint, but of
>> -- the record after it.

> Well, well. Checkpoint position is taken from
> MyLastRecord - I wonder how could this internal var
> take "invalid" data from concurrent backend.

I have not been able to figure that one out either.

> Ok, we're leaving Krasnoyarsk in 8 hrs and should
> arrive SF Feb 5 ~ 10pm.

Have a safe trip!

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] why the DB file size does not reduce when 'delete'the data in DB?

[xuyifeng]

- Original Message - 
From: Roberto Mello <[EMAIL PROTECTED]>
To: xuyifeng <[EMAIL PROTECTED]>
Sent: Sunday, March 04, 2001 10:40 AM
Subject: Re: [HACKERS] why the DB file size does not reduce when 'delete'the data in 
DB?


> On Sun, Mar 04, 2001 at 10:01:37AM +0800, xuyifeng wrote:
> > 
> > could anyone remove this nasty bug in 7.2? this is already a big pain and is the 
>reason 
> > why am I still using MySQL in my product server. another nasty thing is it does 
>not 
> > allow me to reference table in another database.  sigh.
> 
> I don "vacuum analyze" in my Postgres database every night very easily
> using a simple cron job. I create the cron job and forget about it. Really
> it's not that hard don't you think?
> Sure, it's not the desired way, but that's not big enough a reason to
> use PostgreSQL. I could think of a dozen reasons that counter that one and
> would favor PostgreSQL in technical terms. Compared to those, this is
> really really a minor issue.
> As to referring to a table in another DB, I don't know when is that
> going to be implemented.
> 
> -Roberto
> 
> -- 
> +| http://fslc.usu.edu USU Free Software & GNU/Linux Club|--+
>   Roberto Mello - Computer Science, USU - http://www.brasileiro.net 
>   http://www.sdl.usu.edu - Space Dynamics Lab, Web Developer
> << Politically Un-Correct Tagline Deleted! >>
> 

I know your situations,  your DB is not updated and inserted lots of records in few 
minutes,
mine is difference,  I have a real time Stock Trading  system, you know, stock, its 
price 
is changed every minute or even every second ,  I need update and insert delta change 
into DB,  
draw their trend graphics,  suppose there are 3000 stocks in market,  there maybe 9000 
records 
changed and inserted in one minutes, because PGSQL's storage manager problem( it does 
not 
reuse deleted record space),  in 4 hours trading period,  my harddisk can be full 
filled.  because in 
the period, the table indeed gets very large, doing VACCUME is impossible in realtime, 
it will lock
out other clients too long time,  my point of view is PGSQL is fit for static or small 
changed database, 
not fit for lots of change in short time.

Regards,
Xu Yifeng





---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]