Re: Non-transactional pg_class, try 2
От | Alvaro Herrera |
---|---|
Тема | Re: Non-transactional pg_class, try 2 |
Дата | |
Msg-id | 20060626213614.GF11926@surnet.cl обсуждение исходный текст |
Ответ на | Re: [PATCHES] Non-transactional pg_class, try 2 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > What I'm after is not freezing for read-only media, nor archive, nor > > read-only tables. What I'm after is removing the requirement that all > > databases must be vacuumed wholly every 2 billion transactions. > > Well, if that's the only goal then I hardly think we need to have a > discussion, because your alternative #1 is *obviously* the winner: > > > 1. Remove the special case, i.e., process frozen databases in VACUUM > > like every other database. > > This is the easiest, because no extra logic is needed. Just make > > sure they are vacuumed in time. The only problem would be that we'd > > need to uselessly vacuum tables that we know are frozen, from time to > > time. But then, those tables are probably small, so what's the > > problem with that? I'm happy to do at least this for 8.2. We can still try to do the non-transactional catalog later, either in this release or the next; the code is almost there, and it'll be easier to discuss/design because we'll have taken the relminxid stuff out of the way. So if everyone agrees, I'll do this now. Beware -- this may make you vacuum databases that you previously weren't vacuuming. (I really doubt anyone is setting datallowconn=false just to skip vacuuming big databases, but there are people with strange ideas out there.) > So if you want to bring in the other goals that you're trying to pretend > aren't there, step right up and do it. You have not here made a case > that would convince anyone that we shouldn't just do #1 and be done with > it. We can do it in a separate discussion. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
В списке pgsql-hackers по дате отправления: