Личный кабинет
Укажите e-mail, на который будет выслан код восстановления пароля.
На указанный вами адрес e-mail был выслан код подтверждения аккаунта. Введите полученный код для продолжения:
Введите новый пароль два раза:
On 17 November 2015 at 11:48, Amit Kapila <amit.kapila16@gmail.com> wrote:I think in that case what we can do is if the total number ofsub transactions is lesser than equal to 64 (we can find that byoverflowed flag in PGXact) , then apply this optimisation, else usethe existing flow to update the transaction status. I think for that wedon't even need to reserve any additional memory. Does that soundsensible to you?I understand you to mean that the leader should look backwards through the queue collecting xids while !(PGXACT->overflowed)No additional shmem is required
I think in that case what we can do is if the total number ofsub transactions is lesser than equal to 64 (we can find that byoverflowed flag in PGXact) , then apply this optimisation, else usethe existing flow to update the transaction status. I think for that wedon't even need to reserve any additional memory. Does that soundsensible to you?
В списке pgsql-hackers по дате отправления: