Thread

1. RE: (one more time) Patches with vacuum fixes available .

   Mikheev, Vadim <vmikheev@sectorbase.com> — 2001-01-25T00:55:13Z

   > Did we decide against LAZY? Seems we have a number of people 
   > concerned about vacuum downtime, and I can see this as a win
   > for them. If they don't specify LAZY, the code is not run.
   
   First sorry that I wasn't able to deal with vlazy earlier.
   
   Now I have one more open item for 7.1 - restoring index structure
   at runtime (add tuple to parent page for aborted split op,
   create root page if no one exists). I'll try to deal with both
   items (in any case vlazy will be ported to 7.1, as required
   by contract).
   
   As for reported problem: I just looked at Denis' tgz and
   found only table, index and sequence(?) data files - I would
   need in schema definitions, pg_log and pg_variable files
   as well. Denis? Also, when these copies were made -
   before/after unsuccessful vacuum+lazy?
   
   Vadim
   
   

2. Re: (one more time) Patches with vacuum fixes available .

   Denis Perchine <dyp@perchine.com> — 2001-01-25T14:13:09Z

   > > Did we decide against LAZY? Seems we have a number of people
   > > concerned about vacuum downtime, and I can see this as a win
   > > for them. If they don't specify LAZY, the code is not run.
   >
   > First sorry that I wasn't able to deal with vlazy earlier.
   >
   > Now I have one more open item for 7.1 - restoring index structure
   > at runtime (add tuple to parent page for aborted split op,
   > create root page if no one exists). I'll try to deal with both
   > items (in any case vlazy will be ported to 7.1, as required
   > by contract).
   >
   > As for reported problem: I just looked at Denis' tgz and
   > found only table, index and sequence(?) data files
   
   I sent users* :-)))
   
   > - I would
   > need in schema definitions, pg_log and pg_variable files
   > as well. Denis?
   
   I have sent them to you by private mail.
   Schema:
   
   webmailstation=# \d users
                                    Table "users"
        Attribute     |   Type    |                    Modifier
   -------------------+-----------+------------------------------------------------
    id                | integer   | not null default 
   nextval('users_id_seq'::text)
    account_name      | text      |
    account_pass      | text      |
    blocked           | boolean   | default 'f'
    commercial        | boolean   | default 'f'
    expire_date       | timestamp | default now()
    num_of_pop3       | integer   | default 1
    num_of_local      | integer   | default 1
    first_name        | text      |
    last_name         | text      |
    bd_year           | integer   |
    gender            | integer   |
    occupation        | integer   |
    income            | integer   |
    alternate_email   | text      |
    state             | integer   |
    country           | integer   |
    phone             | text      |
    password_question | integer   |
    password_answer   | text      |
    crypt             | char(13)  |
    last_login_ip     | char(31)  |
    last_seen         | timestamp |
    registered        | timestamp |
    in_limit          | integer   | not null default 30
    out_limit         | integer   | not null default 10
    max_msg_size      | integer   | not null default 64
    max_reply_size    | integer   | not null default 16
    max_attach_size   | integer   | not null default 0
    max_replies       | integer   | not null default 10
    max_attachments   | integer   | default 0
   Indices: ix_users_account_name,
            ix_users_blocked,
            users_id_key
   
   Do you need 2 other indices?
   
   > Also, when these copies were made - before/after unsuccessful vacuum+lazy?
   
   Surely before. :-))) Otherwise they would be almost useless for you.
   
   -- 
   Sincerely Yours,
   Denis Perchine
   
   ----------------------------------
   E-Mail: dyp@perchine.com
   HomePage: http://www.perchine.com/dyp/
   FidoNet: 2:5000/120.5
   ----------------------------------