Re: [osdldbt-general] Re: DBT-3 patchset with random fixes.

[<ma...@os...>]

On 11 Feb, Jenny Zhang wrote:
> I applied most of them except for:
> rm $PGDATA:  people could be very upset if runing dbt-3 removed their
> database since they could have other database under $PGDATA.  In fact,
> this was the first feedback I got whey Tom Lane tried to run dbt3.

Then 'rm -rf $PGDATA/$SID' should be acceptable.
 
> - rm /db_temp (when using LVM) because I was paranoid after experiences
> with the previous item.
> You added rm /db_tmp/* and /db_xlog/*, I do not see it has anything to do with LVM

You're partially right about it being related to LVM.  The way you wrote
the scripts, /db_tmp and /db_xlog are only used when using LVM, hence
that connection.  If you're not using LVM, then the removal of $PGDATA
takes care of that.

The fact remains that inconsistent logs files left behind may break the
scripts because the database won't start (something gets confused, I
wasn't interested in what that was at the time).

You shouldn't have been paranoid. I don't believe multiple database
instances should be sharing a log directory. You'd probably already be
in trouble if that were the case.

> Though I applied the patch for q_time.sh, there is one catch when the run lasts for days.

I don't follow the catch.  What does run time have to do with q_time.sh?

> the *.input files under data_collect/pgsql, I wonder if it is ok to move the to the example dir to keep things together.

Depends.  I put them in data_collect/pgsql because they can be used
without changes. The things I put in the examples directory are specific
case examples. Now if you don't want .input file for gnuplot for
graphing the database statistics in that dir, or at all, then that's
another issue.
 
> Jenny
> On Mon, 2004-02-09 at 11:57, ma...@os... wrote:
>> I have another patchset that should apply after the previous one has
>> been applied:
>> 
>> - rm the $PGDATA and db_xlog (when using LVM) dir in build_db.sh because
>>   if the database is in an unconsistent state for whatever reason, this
>>   is a sure way to clear it up without the scripts failing.  I don't
>>   think we care why the database is in an inconsistent state, and I
>>   certainly don't when it's my fault it got that way.
>> 
>> - rm /db_temp (when using LVM) because I was paranoid after experiences
>>   with the previous item.
>> 
>> - Added a script (graph_query_time.pl) to graph query times from the
>>   power and throughput test.
>> 
>> On  5 Feb, To: jenny zhang wrote:
>> > Jenny,
>> > 
>> > These are random fix ups:
>> > 
>> > - Save the database parameters from the load phase for a sanity check.
>> > 
>> > - Need to change the permission on db_logfile.txt, else they are not
>> >   readable by other users than the one running the database.
>> > 
>> > - Fixed anchor typos (case senstitivity) in dbt3_explain.html.
>> > 
>> > - q_time.sh converts the diff_time into seconds as an additional column,
>> >   should be easy to graph the query times now.
>> > 
>> > - Fixed typos in moving the iostat -x files.
>> > 
>> > - Added more example files for graphing postgresql stats.
>> >