Re: [HACKERS] parallel.c is not marked as test covered

On Tue, Jun 21, 2016 at 1:24 AM, Robert Haas wrote: > > On Mon, Jun 20, 2016 at 1:13 PM, Tom Lane wrote: > > Robert Haas writes: > >> On Sun, Jun 19, 2016 at 10:23 PM, Tom Lane wrote: > >>> Personally, I'm +1 for such tinkering if it makes the feature either more > >>> controllable or more unde

[HACKERS] Missing checks when malloc returns NULL...

Hi all, While auditing the code, I got surprised that there are a couple of code paths that do nothing for this error handling: - pg_regress and isolationtester use malloc extensively, in case of failure those would just crash crash. I think that it matters for buildfarm members that are under mem

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 9:08 AM, Thomas Munro wrote: > > On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote: > > On Tue, Jun 21, 2016 at 1:03 AM, Andres Freund wrote: > >> Well, I think generally nobody seriously looked at actually refactoring > >> heap_update(), even though that'd be a good ide

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 9:16 AM, Thomas Munro wrote: > > On Tue, Jun 21, 2016 at 3:29 PM, Amit Kapila wrote: > > Some others ways could be: > > > > Before releasing the lock on buffer containing old tuple, clear the VM and > > visibility info from page and WAL log it. I think this could impact >

Re: [HACKERS] Reviewing freeze map code

On Tue, Jun 21, 2016 at 9:21 AM, Andres Freund wrote: > > On 2016-06-21 08:59:13 +0530, Amit Kapila wrote: > > Can we consider to use some strategy to avoid deadlocks without releasing > > the lock on old page? Consider if we could have a mechanism such that > > RelationGetBufferForTuple() will e

<    1   2