Simon Riggs wrote:
I did want you to commit those changes, but that was 8 days ago and much
has changed since then. Now, I'm slightly worried that this may be a
retrograde step. The last 3 days I've been refactoring the code to
account for other requirements, as I have been discussing, and some o
On Tue, 2009-01-20 at 21:01 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It would be useful to nibble away at the patch, committing all the
> > necessary refactorings to make the patch work. That will reduce size of
> > eventual commit.
>
> I committed this part now; one less thing t
Simon Riggs wrote:
It would be useful to nibble away at the patch, committing all the
necessary refactorings to make the patch work. That will reduce size of
eventual commit.
I committed this part now; one less thing to review. Please adjust the
patch accordingly.
--
Heikki Linnakangas
E
On Thu, 2009-01-15 at 18:16 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> Is the first really useful? I would understand "advance until next
> cleanup record *that would block/kill queries*", but why would you
> want to advance until the next cleanup record?
Minor difference there, b
On Thu, 2009-01-15 at 18:05 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The idea outlined before didn't deal with all call points for
> > RecordIsCleanupRecord(), so doesn't actually work.
>
> Are we talking about the same thing?
I guess not. Look at the other call points for that
Simon Riggs wrote:
The idea outlined before didn't deal with all call points for
RecordIsCleanupRecord(), so doesn't actually work.
Hmm, grep finds two call points for that:
! case RECOVERY_TARGET_PAUSE_CLEANUP:
! /*
!
Simon Riggs wrote:
The idea outlined before didn't deal with all call points for
RecordIsCleanupRecord(), so doesn't actually work.
Are we talking about the same thing? If we put the control of locking to
the hands of the redo-function, I don't see why it couldn't use a lock
of the right stre
On Fri, 2009-01-09 at 19:34 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It would be useful to nibble away at the patch, committing all the
> > necessary refactorings to make the patch work. That will reduce size of
> > eventual commit.
>
> Agreed. This in particular is a change I f
Please commit soon
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
> The hot standby patch has some hacks to decide which full-page-images
> can be restored holding an exclusive lock and which ones need a
> vacuum-strength lock. It's not very pretty as is, as mentioned in
> com
Simon Riggs wrote:
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
How about we refactor things?
Was that a patch against HEAD or a patch on patch?
Against HEAD.
It would be useful to nibble away at the patch, committing all the
necessary refactorings to make the patch work. T
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
> How about we refactor things?
Was that a patch against HEAD or a patch on patch?
It would be useful to nibble away at the patch, committing all the
necessary refactorings to make the patch work. That will reduce size of
eventual comm
On Fri, 2009-01-09 at 18:30 +0200, Heikki Linnakangas wrote:
> The hot standby patch has some hacks to decide which full-page-images
> can be restored holding an exclusive lock and which ones need a
> vacuum-strength lock. It's not very pretty as is, as mentioned in
> comments too.
Agreed!
>
The hot standby patch has some hacks to decide which full-page-images
can be restored holding an exclusive lock and which ones need a
vacuum-strength lock. It's not very pretty as is, as mentioned in
comments too.
How about we refactor things so that redo-functions are responsible for
calling
13 matches
Mail list logo
