Re: timeout implementation issues
От | Bruce Momjian |
---|---|
Тема | Re: timeout implementation issues |
Дата | |
Msg-id | 200204181432.g3IEW5t03803@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: timeout implementation issues (Hiroshi Inoue <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
Hiroshi Inoue wrote: > Michael Loftis wrote: > > > > Tom Lane wrote: > > > > >Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > > > >>I have added this to the TODO list, with a question mark. Hope this is > > >>OK with everyone. > > >> > > > > > >> o Abort SET changes made in aborted transactions (?) > > >> > > > > > >Actually, I was planning to make only search_path act that way, because > > >of all the push-back I'd gotten on applying it to other SET variables. > > >search_path really *has* to have it, but if there's anyone who agrees > > >with me about doing it for all SET vars, they didn't speak up :-( > > > > > I did and do, strongly. TRANSACTIONS are supposed to leave things as > > they were before the BEGIN. It either all happens or it all doesnt' > > happen. If you need soemthing inside of a transaction to go > > irregardless then it shouldn't be within the transaction. > > Oops is this issue still living ? > I object to the TODO(why ????) strongly. > Please remove it from the TODO first and put it back > to the neutral position. OK, how is this: o Abort all or commit all SET changes made in an aborted transaction Is this neutral? I don't think our current behavior is defended by anyone. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: