On Tue, Mar 3, 2015 at 3:13 AM, Andres Freund wrote:
>> toast_save_datum() is called with a heap_insert() call before heap
>> insertion for the tuple proper. We're relying on the assumption that
>> if there is no immediate super deletion record, things are fine. We
>> cannot speculatively insert i
On 2015-02-25 14:04:55 -0800, Peter Geoghegan wrote:
> On Wed, Feb 25, 2015 at 3:26 AM, Andres Freund wrote:
> > I'm pretty sure this will entirely fail if you have a transaction that's
> > large enough to spill to disk. Calling ReorderBufferIterTXNNext() will
> > reuse the memory for the in memor
On 2/19/15 4:11 AM, Andres Freund wrote:
Thoughts? Can't say that I've given conflict resolution for
>multi-master systems a great deal of thought before now, so I might be
>quite off the mark here.
I don't think conflict resolution actually plays a role here. This is
about consistency inside a
On Wed, Feb 25, 2015 at 3:26 AM, Andres Freund wrote:
> I'm pretty sure this will entirely fail if you have a transaction that's
> large enough to spill to disk. Calling ReorderBufferIterTXNNext() will
> reuse the memory for the in memory changes.
>
> It's also borked because it skips a large numb
Hi,
> > Well, that implies that we'd actually know that we'd succeed when WAL
> > logging the speculative heap tuple's insertion. We literally have no
> > way of knowing if that's the case at that point, though - that's just
> > the nature of value locking scheme #2's optimistic approach.
>
> Att
On Fri, Feb 20, 2015 at 3:44 PM, Peter Geoghegan wrote:
>>> they'd only see a
>>> REORDER_BUFFER_CHANGE_INSERT when that was the definitive outcome of
>>> an UPSERT, or alternatively a REORDER_BUFFER_CHANGE_UPDATE when that
>>> was the definitive outcome. No need for output plugins to consider
>>>
On Fri, Feb 20, 2015 at 3:52 PM, Andres Freund wrote:
> On 2015-02-20 15:44:12 -0800, Peter Geoghegan wrote:
>> On Thu, Feb 19, 2015 at 2:11 AM, Andres Freund
>> wrote:
>> > Yes. It'd be easiest if the only the final insert/update were actually
>> > WAL logged as full actions.
>>
>> Well, that i
On 2015-02-20 15:44:12 -0800, Peter Geoghegan wrote:
> On Thu, Feb 19, 2015 at 2:11 AM, Andres Freund wrote:
> > Yes. It'd be easiest if the only the final insert/update were actually
> > WAL logged as full actions.
>
> Well, that implies that we'd actually know that we'd succeed when WAL
> loggi
On Thu, Feb 19, 2015 at 2:11 AM, Andres Freund wrote:
> On 2015-02-18 16:35:14 -0800, Peter Geoghegan wrote:
>> Andres pointed out that the INSERT ... ON CONFLICT UPDATE patch
>> doesn't work well with logical decoding.
>
> Just to make that clear: I didn't actually test it, but it ddidn't look
>
Hi,
On 2015-02-18 16:35:14 -0800, Peter Geoghegan wrote:
> Andres pointed out that the INSERT ... ON CONFLICT UPDATE patch
> doesn't work well with logical decoding.
Just to make that clear: I didn't actually test it, but it ddidn't look
good.
> I guess that the best way of fixing this is exposi
Andres pointed out that the INSERT ... ON CONFLICT UPDATE patch
doesn't work well with logical decoding. Basically, as things stand,
there is no means of determining that an INSERT had an ON CONFLICT
UPDATE clause from logical decoding. It isn't obvious that this
matters - after all, the relevant W
11 matches
Mail list logo
