Simon Riggs wrote:
>> Tom Lane wrote:
>>> [ scratches head ... ] Why is hot standby messing with this sort of
>>> thing at all? It sounds like a performance optimization that should
>>> be considered separately, and *later*.
>> Yeah, I too considered just ripping it out. Simon is worried that
>>
While playing with conflict resolution, I bumped into this:
postgres=# begin ISOLATION LEVEL SERIALIZABLE;
BEGIN
postgres=# SELECT * FROM foo;
id | data
+--
12 |
(1 row)
postgres=# SELECT * FROM foo;
id | data
+--
12 |
(1 row)
postgres=# SELECT * FROM foo;
id | data
+---
On Fri, 2009-10-02 at 10:32 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I will docuemnt the recommendation to set max_standby_delay = 0 if
> > performing an archive recovery (and explain why).
>
> Hmm, not sure if that's such a good piece of advice either. It will mean
> waiting for
On Thu, 2009-10-01 at 18:47 +0300, Heikki Linnakangas wrote:
> And if you could please review the changes I've been doing, just to
> make sure I haven't inadvertently introduced new bugs. That has
> happened before, as you've rightfully reminded me :-).
You posted 17 patches here.
I've reviewed
On Sun, 2009-09-27 at 13:57 +0300, Heikki Linnakangas wrote:
> Per Simon's request, for the benefit of the archive, here's all the
> changes I've done on the patch since he posted the initial version for
> review for this commitfest as incremental patches. This is extracted
> from my git reposito
On Tue, 2009-10-06 at 01:10 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > We discussed briefly your change
> > 0011-Replace-per-proc-counters-of-loggable-locks-with-per.patch.
> >
> > I don't see how that helps at all. The objective of lock counters was to
> > know if we can skip acq
On Mon, 2009-10-05 at 18:30 -0400, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
> >> Heikki Linnakangas wrote:
> >>> Per Simon's request, for the benefit of the archive, here's all the
> >>> changes I've done on the patch since he
Simon Riggs wrote:
> On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
>> Heikki Linnakangas wrote:
>>> Per Simon's request, for the benefit of the archive, here's all the
>>> changes I've done on the patch since he posted the initial version for
>>> review for this commitfest as increme
Simon Riggs wrote:
> We discussed briefly your change
> 0011-Replace-per-proc-counters-of-loggable-locks-with-per.patch.
>
> I don't see how that helps at all. The objective of lock counters was to
> know if we can skip acquiring an LWlock on all lock partitions. This
> change keeps the lock coun
On Mon, 2009-10-05 at 10:19 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > I don't see how that helps at all. The objective of lock counters was to
> > know if we can skip acquiring an LWlock on all lock partitions. This
> > change keeps the lock counters yet acquires the locks we were trying t
Simon Riggs writes:
> I don't see how that helps at all. The objective of lock counters was to
> know if we can skip acquiring an LWlock on all lock partitions. This
> change keeps the lock counters yet acquires the locks we were trying to
> avoid. This change needs some justification since it is
On Sun, 2009-09-27 at 13:57 +0300, Heikki Linnakangas wrote:
> Per Simon's request, for the benefit of the archive, here's all the
> changes I've done on the patch since he posted the initial version for
> review for this commitfest as incremental patches. This is extracted
> from my git repositor
On Mon, 2009-09-28 at 11:25 +0300, Heikki Linnakangas wrote:
> Heikki Linnakangas wrote:
> > Per Simon's request, for the benefit of the archive, here's all the
> > changes I've done on the patch since he posted the initial version for
> > review for this commitfest as incremental patches. This is
On Fri, 2009-10-02 at 18:04 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I will add code to make a shutdown checkpoint be a valid starting place
> > for Hot Standby, as long as there are no in-doubt prepared transactions.
> > That way we know there are no xids still running and no loc
Simon Riggs wrote:
> I will add code to make a shutdown checkpoint be a valid starting place
> for Hot Standby, as long as there are no in-doubt prepared transactions.
> That way we know there are no xids still running and no locks, without
> needing to write a record to say so.
Ok, I can live wit
On Fri, 2009-10-02 at 13:52 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I'd rather just skip this for now. It's a minor case anyway and there's
> > nothing stopping writing their own RunningXactData records with a
> > function, if it is needed. I can add a function for that.
>
> Tha
Simon Riggs wrote:
> I'd rather just skip this for now. It's a minor case anyway and there's
> nothing stopping writing their own RunningXactData records with a
> function, if it is needed. I can add a function for that.
That won't help. There's no way to have it in a right place wrt. the
shutdown
On Fri, 2009-10-02 at 11:26 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote:
> >
> >> It seems dangerous to write a WAL record after the shutdown checkpoint.
> >> It will be overwritten by subsequent startup, which is a recipe
On Fri, 2009-10-02 at 11:26 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote:
> >
> >> It seems dangerous to write a WAL record after the shutdown checkpoint.
> >> It will be overwritten by subsequent startup, which is a recipe
Simon Riggs wrote:
> On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote:
>
>> It seems dangerous to write a WAL record after the shutdown checkpoint.
>> It will be overwritten by subsequent startup, which is a recipe for trouble.
>
> I've said its a corner case and not worth spending tim
On Fri, 2009-10-02 at 10:43 +0300, Heikki Linnakangas wrote:
> It seems dangerous to write a WAL record after the shutdown checkpoint.
> It will be overwritten by subsequent startup, which is a recipe for trouble.
I've said its a corner case and not worth spending time on. I'm putting
it in at y
On Fri, 2009-10-02 at 10:32 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I will docuemnt the recommendation to set max_standby_delay = 0 if
> > performing an archive recovery (and explain why).
>
> Hmm, not sure if that's such a good piece of advice either. It will mean
> waiting for
Simon Riggs wrote:
> On Fri, 2009-10-02 at 10:04 +0300, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
>>> @@ -7061,6 +7061,15 @@ ShutdownXLOG(int code, Datum arg)
>>> else
>>> {
>>> /*
>>> +* Take a snapshot of running transactions and write this to WAL.
>>> +* Thi
On Fri, 2009-10-02 at 10:04 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > @@ -7061,6 +7061,15 @@ ShutdownXLOG(int code, Datum arg)
> > else
> > {
> > /*
> > +* Take a snapshot of running transactions and write this to WAL.
> > +* This allows us to recons
Simon Riggs wrote:
> I will docuemnt the recommendation to set max_standby_delay = 0 if
> performing an archive recovery (and explain why).
Hmm, not sure if that's such a good piece of advice either. It will mean
waiting for queries forever, which probably isn't what you want if
you're performing
Simon Riggs wrote:
> @@ -7061,6 +7061,15 @@ ShutdownXLOG(int code, Datum arg)
> else
> {
> /*
> +* Take a snapshot of running transactions and write this to WAL.
> +* This allows us to reconstruct the state of running transactions
> +* during archive recovery
On Thu, 2009-10-01 at 18:48 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Hmm, yes. ISTM that I'm still calculating latestRunningXid the old way
> > while assuming it is calculated the new way. The new way is just to grab
> > nextXid since we have XidGenLock and do TransactionIdRetreat
On Thu, 2009-10-01 at 18:47 +0300, Heikki Linnakangas wrote:
> Could you look into these two TODO items you listed on the wiki page:
Unless we agree otherwise, if its listed on the Wiki page then I will
work on it.
Maybe not as when you might like it, but I am working through the list.
5 new ch
Simon Riggs wrote:
> Hmm, yes. ISTM that I'm still calculating latestRunningXid the old way
> while assuming it is calculated the new way. The new way is just to grab
> nextXid since we have XidGenLock and do TransactionIdRetreat() on it.
Ok, good, that's what I thought too. I'll fix that.
--
Simon Riggs wrote:
> On Wed, 2009-09-30 at 09:33 +0300, Heikki Linnakangas wrote:
>
>> Looking at the changes to StartupMultiXact, you're changing the locking
>> so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
>> are acquire first before changing anything. Why? Looking at th
On Wed, 2009-09-30 at 09:33 +0300, Heikki Linnakangas wrote:
> Looking at the changes to StartupMultiXact, you're changing the locking
> so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
> are acquire first before changing anything. Why? Looking at the other
> functions in th
On Thu, 2009-10-01 at 14:29 +0300, Heikki Linnakangas wrote:
> + /*
> +* If our initial RunningXactData had an overflowed snapshot then we
> +* knew we were missing some subxids from our snapshot. We can use
> +* this data as an initial snapshot, but we cannot yet mark it valid.
> +
On Wed, 2009-09-30 at 18:45 +0300, Heikki Linnakangas wrote:
> Regarding this in InitStandbyDelayTimers:
> + /*
> +* If replication delay is enormously huge, just treat that as
> +* zero and work up from there. This prevents us from acting
> +* foolishly when replaying old log files.
+ /*
+* If our initial RunningXactData had an overflowed snapshot then we
+* knew we were missing some subxids from our snapshot. We can use
+* this data as an initial snapshot, but we cannot yet mark it valid.
+* We know that the missing subxids are equal to or earlier than
+
Regarding this in InitStandbyDelayTimers:
+ /*
+* If replication delay is enormously huge, just treat that as
+* zero and work up from there. This prevents us from acting
+* foolishly when replaying old log files.
+*/
+ if (*currentDelay_ms < 0)
+ *currentDelay_ms = 0;
+
Looking at the changes to StartupMultiXact, you're changing the locking
so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
are acquired first before changing anything. Why? Looking at the other
functions in that file, all others that access both files are happy to
acquire one lo
Looking at the changes to StartupMultiXact, you're changing the locking
so that both MultiXactOffsetControlLock and MultiXactMemberControlLock
are acquire first before changing anything. Why? Looking at the other
functions in that file, all others that access both files are happy to
acquire one loc
Heikki Linnakangas wrote:
> Per Simon's request, for the benefit of the archive, here's all the
> changes I've done on the patch since he posted the initial version for
> review for this commitfest as incremental patches. This is extracted
> from my git repository at
> git://git.postgresql.org/git/
Per Simon's request, for the benefit of the archive, here's all the
changes I've done on the patch since he posted the initial version for
review for this commitfest as incremental patches. This is extracted
from my git repository at
git://git.postgresql.org/git/users/heikki/postgres.git.
--
He
Mark Mielke escribió:
> Most real life code gets a little more complicated. For example,
> what if we want to simulate a network failure or "out of disk space"
> condition? What if we want to test out what happens when the Y2038
> date is reached? This requires either complex test case setup that
On Sep 26, 2009, at 12:33 PM, Josh Berkus wrote:
There's always pgtap. Whenever we find a new corner case, we add it
to
the development test suite.
Also, for C TAP, there's [libtap](http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/LibTap
). You can then use `prove` which you likely already have
On 09/26/2009 02:28 PM, Dan Colish wrote:
There are a variety of projects dedicated to creating C unit test
frameworks. I don't have a lot of experience with them, but I have heard
good things about check and cunit. Here's a link I found with a longer
list of frameworks. http://www.opensourcetest
> I feel like I need a better way of unit testing new code. Some of the
> code in the patch is to handle corner cases, so recreating them is
> fairly hard. It is a nagging feeling that I am missing some knowledge
> here and would welcome some insight, or research, into better ways of
> doing gener
On Sat, Sep 26, 2009 at 10:45:17AM -0400, Mark Mielke wrote:
> On 09/26/2009 10:04 AM, Simon Riggs wrote:
> >>If you think there's
> >>something useful I could do, let me know and I'll take a look.
> >I feel like I need a better way of unit testing new code. Some of the
> >code in the patch is to h
On 09/26/2009 10:04 AM, Simon Riggs wrote:
If you think there's
something useful I could do, let me know and I'll take a look.
I feel like I need a better way of unit testing new code. Some of the
code in the patch is to handle corner cases, so recreating them is
fairly hard. It is a naggi
On Sat, 2009-09-26 at 09:29 -0400, Robert Haas wrote:
> > I estimate that making the remaining changes noted on the Wiki and
> fully
> > testing them will take at least 2 weeks. Gabriele Bartolini is assisting
> > in this area, though neither of us are able to work full time on this.
> > We still
On Sat, Sep 26, 2009 at 5:49 AM, Simon Riggs wrote:
>
> Just a note to say that Hot Standby patch is now on git repository
> git://git.postgresql.org/git/users/simon/postgres
> Branch name: hot_standby
Awesome! Thanks for taking the time to get this set up.
> The complete contents of that repo
47 matches
Mail list logo
