On Sat, Oct 27, 2012 at 04:57:46PM +0530, Amit Kapila wrote:
On Saturday, October 27, 2012 4:03 AM Noah Misch wrote:
Could you elaborate on your reason for continuing to treat TOAST as a
special
case? As best I recall, the only reason to do so before was the fact
that
TOAST can change
On 27.10.2012 16:43, Tom Lane wrote:
Jan Wieckjanwi...@yahoo.com writes:
The reason why we need full_page_writes is that we need to guard against
torn pages or partial writes. So what if smgr would manage a mapping
between logical page numbers and their physical location in the relation?
At
On 27.10.2012 14:27, Amit Kapila wrote:
On Saturday, October 27, 2012 4:03 AM Noah Misch wrote:
In my previous review, I said:
Given [not relying on the executor to know which columns changed],
why not
treat the tuple as an opaque series of bytes and not worry about
datum
On Sat, Oct 27, 2012 at 3:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think you're just moving the atomic-write problem from the data pages
to wherever you keep these pointers.
If the pointers are stored as simple 4-byte integers, you probably could
assume that they're
Claudio Freire klaussfre...@gmail.com writes:
On Sat, Oct 27, 2012 at 3:41 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I think you're just moving the atomic-write problem from the data pages
to wherever you keep these pointers.
If the pointers are stored as simple 4-byte integers,
On 28/10/12 07:41, Heikki Linnakangas wrote:
On 27.10.2012 16:43, Tom Lane wrote:
Jan Wieckjanwi...@yahoo.com writes:
The reason why we need full_page_writes is that we need to guard
against
torn pages or partial writes. So what if smgr would manage a mapping
between logical page numbers and
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
This was actually kind of anti-climactic, since it only
took about 5 minutes to make the change and get it
working. Didn't really feel the way I expected it to ;)
Well, we can reject your patch and start bike-shedding
it for the next
