On Mon, Dec 26, 2005 at 11:00:51AM -0500, Bruce Momjian wrote:
> I think this brings up an interesting distinction, that having the NO
> LOGGING switch per command doesn't make sense because it modifying the
> table. It has to be a per-object switch, or something that operates
> only on empty tables. This is the exact same distinction we talked
> about for NO LOGGING COPY.
I've thought of one other possibility, which is kind of at the extreme
end of system implementation. Given the suggestion about not losing a
whole table on unclean shutdown, how about using a single table, split.
1. When setting no logging flag, take exclusive lock and record
filesize. This size is X.
2. From now on any data before X is read-only. So no updates. Any new
data needs to be allocated at end, so no FSM either.
3. Any data added after X is not logged to xlog.
4. On unclean shutdown, truncate table to length X.
5. When logging is reenabled, set X back to infinity.
The shared temp tables discussed earlier and basically be above with
X=0. The process of untempifying a table is setting X to infinity. Temp
tables always have X=0.
This allows people to do their ELT, because they can update rows
written after X but without the logging. If you have PITR you simply
never allow changing X of any table.
But this is pretty way out though IMO.
Have a nice day,
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
In response to
pgsql-hackers by date
|Next:||From: Greg Stark||Date: 2005-12-27 18:59:41|
|Subject: Re: [HACKERS] Online backup vs Continuous backup|
|Previous:||From: Bruce Momjian||Date: 2005-12-27 17:54:50|
|Subject: Re: Handling of build-time enabled GUC settings|