On 2015-04-15 18:53:15 +0300, Heikki Linnakangas wrote: > Hmm, ok, I've read the "INSERT ... ON CONFLICT UPDATE and logical decoding" > thread now, and I have to say that IMHO it's a lot more sane to handle this > in ReorderBufferCommit() like Peter first did, than to make the main > insertion path more complex like this.
I don't like Peter's way much. For one it's just broken. For another it's quite annoying to trigger disk reads to figure out what actual type of record something is. If we go that way that's the way I think it should be done: Whenever we encounter a speculative record we 'unlink' it from the changes that will be reused for spooling from disk and do nothing further. Then we just continue reading through the records. If the next thing we encounter is a super-deletion we throw away that record. If it's another type of change (or even bettter a 'speculative insertion succeeded' record) insert it. That'll still require some uglyness, but it should not be too bad. I earlier thought that'd not be ok because there could be a new catalog snapshot inbetween, but I was mistaken: The locking on the source transaction prevents problems. > Another idea is to never spill the latest record to disk, at least if it was > a speculative insertion. Then you would be sure that when you see the > super-deletion record, the speculative insertion it refers to is still in > memory. That seems simple. It's not guaranteed to be the last record, there can be records inbetween (snapshots from other backends at the very least). Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
