On Tue, Feb 12, 2019 at 07:13:45PM -0300, Alvaro Herrera wrote:
> It was reasonable to close this patch as returned-with-feedback in
> January commitfest, but what you did here was first move it to the March
> commitfest and then close it as returned-with-feedback in the March
> commitfest, which h
On 2019-Feb-04, Michael Paquier wrote:
> On Thu, Jan 31, 2019 at 04:38:27AM -0800, Andres Freund wrote:
> > Is this still in development? Or should we mark this as returned with
> > feedback?
>
> Marked as returned with feedback, as it has already been two months.
> If you have an updated patch s
On Thu, Jan 31, 2019 at 04:38:27AM -0800, Andres Freund wrote:
> Is this still in development? Or should we mark this as returned with
> feedback?
Marked as returned with feedback, as it has already been two months.
If you have an updated patch set, please feel free to resubmit.
--
Michael
signa
On 2019-Jan-31, Greg Stark wrote:
> This looks like repeating the autocommit mistakes of the past.
Yeah, this argument has been made before. Peter E argued against that:
https://postgr.es/m/ea395aa8-5ac4-6bcd-366d-aab2ff2b0...@2ndquadrant.com
> And based on that experience wouldn't the replacem
On Fri 7 Dec 2018, 21:43 Robert Haas On Fri, Dec 7, 2018 at 3:34 PM Alvaro Herrera
> wrote:
> > Yeah, I agree that this downside is real. I think our only protection
> > against that is to say "don't do that". Like any other tool, it has
> > upsides and downsides; we shouldn't keep it away from
On 2018-12-08 17:55:03 -0300, Alvaro Herrera wrote:
> On 2018-Dec-08, Andres Freund wrote:
>
> > On 2018-12-08 17:10:27 -0300, Alvaro Herrera wrote:
>
> > > This is what patch 0001 does -- it's only allowed in the connection
> > > string, or on ALTER USER / ALTER DATABASE. Setting it in
> > > po
From: Andres Freund [mailto:and...@anarazel.de]
> Isn't the realistic scenario for migrations that people will turn this
> feature on on a more global basis? If they need to do per transaction choices,
> that makes this much less useful for easy migrations.
Agreed. My approach of per transaction
On 2018-Dec-08, Andres Freund wrote:
> On 2018-12-08 17:10:27 -0300, Alvaro Herrera wrote:
> > This is what patch 0001 does -- it's only allowed in the connection
> > string, or on ALTER USER / ALTER DATABASE. Setting it in
> > postgresql.conf is forbidden, as well as changing from transaction t
Hi,
On 2018-12-08 17:10:27 -0300, Alvaro Herrera wrote:
> On 2018-Dec-07, Andres Freund wrote:
>
> > I think it could partially be addressed by not allowing to set it on the
> > commandline, server config, etc. So the user would have to set it on a
> > per-connection basis, potentially via the co
On 2018-Dec-07, Andres Freund wrote:
> I think it could partially be addressed by not allowing to set it on the
> commandline, server config, etc. So the user would have to set it on a
> per-connection basis, potentially via the connection string.
This is what patch 0001 does -- it's only allowed
On Fri, Dec 7, 2018 at 3:50 PM Alvaro Herrera wrote:
> On 2018-Dec-07, Robert Haas wrote:
> > More generally, whether or not we should "keep something away from our
> > users" really depends on how likely the upsides are to occur relative
> > to the downsides. We don't try to keep users from runn
On Fri, Dec 7, 2018 at 7:25 PM Alexander Korotkov
wrote:
> The first thing, which comes to the mind is undo log. When you have
> undo log, then on new subtransaction you basically memorize the
> current undo log position. If subtransaction rollbacks, you have to
> just play back undo log until r
On Fri, Dec 7, 2018 at 11:34 PM Alvaro Herrera wrote:
> On 2018-Dec-07, Robert Haas wrote:
> > Full disclosure: EDB has a feature like this and has for years, but it
> > uses a subtransaction per statement, not a subtransaction per row.
>
> Well, this implementation only uses one subtransaction pe
Hi,
On 2018-12-07 16:02:53 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > Well, look at this from this point of view: EnterpriseDB implemented
> > this because of customer demand (presumably). Fujitsu also implemented
> > this for customers. The pgjdbc driver implemented this for its users
Alvaro Herrera writes:
> Well, look at this from this point of view: EnterpriseDB implemented
> this because of customer demand (presumably). Fujitsu also implemented
> this for customers. The pgjdbc driver implemented this for its users.
> Now 2ndQuadrant also implemented this, and not out of t
Robert Haas writes:
> I have a hard time arguing against that given that EDB has this thing
> in our bag of tricks, but if it weren't for that I'd be fighting
> against this tooth and nail. Behavior-changing GUCs sck.
Uh, we're not seriously considering a GUC that changes transactional
behav
On 12/7/18 12:50 PM, Alvaro Herrera wrote:
On 2018-Dec-07, Robert Haas wrote:
More generally, whether or not we should "keep something away from our
users" really depends on how likely the upsides are to occur relative
to the downsides. We don't try to keep users from running DELETE
because th
On 2018-Dec-07, Robert Haas wrote:
> More generally, whether or not we should "keep something away from our
> users" really depends on how likely the upsides are to occur relative
> to the downsides. We don't try to keep users from running DELETE
> because they might delete data they want; that w
On Fri, Dec 7, 2018 at 3:34 PM Alvaro Herrera wrote:
> Yeah, I agree that this downside is real. I think our only protection
> against that is to say "don't do that". Like any other tool, it has
> upsides and downsides; we shouldn't keep it away from users only because
> they might misuse it.
I
On 2018-Dec-07, Robert Haas wrote:
> Full disclosure: EDB has a feature like this and has for years, but it
> uses a subtransaction per statement, not a subtransaction per row.
Well, this implementation only uses one subtransaction per statement;
Andres says per-row referring to the case of one I
On Fri, Dec 7, 2018 at 2:57 PM Alvaro Herrera wrote:
> The way I envision this to be used in practice is that it's enabled
> globally when the migration effort starts, then gradually disabled as
> parts of applications affected by these downsides are taught how to deal
> with the other behavior.
On 2018-Dec-07, Andres Freund wrote:
> On December 7, 2018 11:56:55 AM PST, Alvaro Herrera
> wrote:
> >BTW, a couple of months ago I measured the performance implications for
> >a single update under pgbench and it represented a decrease of about
> >3%-5%. Side-effects such as xid consumption h
On December 7, 2018 11:56:55 AM PST, Alvaro Herrera
wrote:
>BTW, a couple of months ago I measured the performance implications for
>a single update under pgbench and it represented a decrease of about
>3%-5%. Side-effects such as xid consumption have worse implications,
>but as far as perfor
Hi
On 2018-Dec-07, Andres Freund wrote:
> Isn't the realistic scenario for migrations that people will turn this
> feature on on a more global basis? If they need to do per transaction
> choices, that makes this much less useful for easy migrations.
The way I envision this to be used in practice
Hi,
On December 7, 2018 11:44:17 AM PST, Alvaro Herrera
wrote:
>On 2018-Dec-07, Andres Freund wrote:
>
>> Hi,
>>
>> On 2018-12-07 16:20:06 -0300, Alvaro Herrera wrote:
>> >case TBLOCK_BEGIN:
>> > + s->rollbackScope = XactRollbackScope;
>> >s->blo
On 2018-Dec-07, Andres Freund wrote:
> Hi,
>
> On 2018-12-07 16:20:06 -0300, Alvaro Herrera wrote:
> > case TBLOCK_BEGIN:
> > + s->rollbackScope = XactRollbackScope;
> > s->blockState = TBLOCK_INPROGRESS;
> > + if (s->rollbackSco
Hi,
On 2018-12-07 16:20:06 -0300, Alvaro Herrera wrote:
> case TBLOCK_BEGIN:
> + s->rollbackScope = XactRollbackScope;
> s->blockState = TBLOCK_INPROGRESS;
> + if (s->rollbackScope == XACT_ROLLBACK_SCOPE_STMT)
> +
27 matches
Mail list logo
