Re: AW: Plans for solving the VACUUM problem
От | Barry Lind |
---|---|
Тема | Re: AW: Plans for solving the VACUUM problem |
Дата | |
Msg-id | 3B09783C.1080508@xythos.com обсуждение исходный текст |
Ответ на | AW: Plans for solving the VACUUM problem (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Ответы |
Re: AW: Plans for solving the VACUUM problem
|
Список | pgsql-hackers |
Zeugswetter Andreas SB wrote: >>> Vadim, can you remind me what UNDO is used for? >> >> 4. Split pg_log into small files with ability to remove old ones (which >> do not hold statuses for any running transactions). > > > They are already small (16Mb). Or do you mean even smaller ? > This imposes one huge risk, that is already a pain in other db's. You need > all logs of one transaction online. For a GigaByte transaction like a bulk > insert this can be very inconvenient. > Imho there should be some limit where you can choose whether you want > to continue without the feature (no savepoint) or are automatically aborted. > > In any case, imho some thought should be put into this :-) > > Another case where this is a problem is a client that starts a tx, does one little > insert or update on his private table, and then sits and waits for a day. > > Both cases currently impose no problem whatsoever. Correct me if I am wrong, but both cases do present a problem currently in 7.1. The WAL log will not remove any WAL files for transactions that are still open (even after a checkpoint occurs). Thus if you do a bulk insert of gigabyte size you will require a gigabyte sized WAL directory. Also if you have a simple OLTP transaction that the user started and walked away from for his one week vacation, then no WAL log files can be deleted until that user returns from his vacation and ends his transaction. --Barry > > > Andreas > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > >
В списке pgsql-hackers по дате отправления: