Re: [HACKERS] [RFC] Transaction management overhaul is necessary?

2016-10-25 Thread Tsunakawa, Takayuki
From: Craig Ringer [mailto:cr...@2ndquadrant.com] > >> This was because psqlODBC starts and ends a subtransaction for each > >> SQL statement by default to implement statement-level rollback. And > >> PostgreSQL creates one CurTransactionContext memory context, which is > >> 8KB, for each

Re: [HACKERS] [RFC] Transaction management overhaul is necessary?

2016-10-21 Thread Craig Ringer
On 21 October 2016 at 18:57, Pavel Stehule wrote: > 2016-10-21 10:24 GMT+02:00 Tsunakawa, Takayuki > : >> >> Hello, >> >> From our experience in handling customers' problems, I feel it's necessary >> to evolve PostgreSQL's transaction

Re: [HACKERS] [RFC] Transaction management overhaul is necessary?

2016-10-21 Thread Pavel Stehule
2016-10-21 10:24 GMT+02:00 Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com>: > Hello, > > From our experience in handling customers' problems, I feel it's necessary > to evolve PostgreSQL's transaction management. The concrete problems are: > > 1. PostgreSQL cannot end and begin

[HACKERS] [RFC] Transaction management overhaul is necessary?

2016-10-21 Thread Tsunakawa, Takayuki
Hello, >From our experience in handling customers' problems, I feel it's necessary to >evolve PostgreSQL's transaction management. The concrete problems are: 1. PostgreSQL cannot end and begin transactions in PL/pgSQL and PL/Java stored functions. This is often the reason people could not