Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
От | Andrew Dunstan |
---|---|
Тема | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
Дата | |
Msg-id | 43B570C9.6060406@dunslane.net обсуждение исходный текст |
Ответ на | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
|
Список | pgsql-hackers |
Tom Lane wrote: >"Andrew Dunstan" <andrew@dunslane.net> writes: > > >>Simon Riggs said: >> >> >>>Following Andrew's concerns, I'd also note that ALTER TABLE requires a >>>much higher level of privilege to operate than does COPY. That sounds >>>like it will make things more secure, but all it does is open up the >>>administrative rights, since full ownership rights must be obtained >>>merely to load data. >>> >>> > > > >>My concern is more about making plain that this is for special operations, >>not normal operations. Or maybe I have misunderstood the purpose. >> >> > >Rephrase that as "full ownership rights must be obtained to load data in >a way that requires dropping any existing indexes and locking out other >users of the table". I don't think the use-case for this will be very >large for non-owners, or indeed even for owners except during initial >table creation; and so I don't think the above argument is strong. > > > > Those restrictions aren't true of Bruce's proposed drop and delete/truncate recovery modes, are they? People do crazy things in pursuit of performance. Illustration: a few months ago I was instrumenting an app (based on MySQL/ISAM) and I noticed that under load it simply didn't update the inventory properly - of 1000 orders placed within a few seconds it might reduce inventory by 3 or 4. I reported this and they shrugged their shoulders and said "well, we'd have to lock the table and that would slow everything down ...". I just want to be sure we aren't providing a footgun. "Oh, just set recovery mode to delete. It won't make any difference unless you crash and you'll run faster." cheers andrew
В списке pgsql-hackers по дате отправления: