On Thu, Sep 11, 2014 at 04:58:12PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Sep 10, 2014 at 02:24:17AM +0100, Greg Stark wrote:
> >> I think the reason nobody's responding is because nobody has anything
> >> significant to add. It's a behavior change from not-working to
> >> work
On 2014-09-11 16:58:12 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Sep 10, 2014 at 02:24:17AM +0100, Greg Stark wrote:
> >> I think the reason nobody's responding is because nobody has anything
> >> significant to add. It's a behavior change from not-working to
> >> working. Why wou
Bruce Momjian writes:
> On Wed, Sep 10, 2014 at 02:24:17AM +0100, Greg Stark wrote:
>> I think the reason nobody's responding is because nobody has anything
>> significant to add. It's a behavior change from not-working to
>> working. Why wouldn't it be backpatched?
> OK, Greg seems to be passion
On Wed, Sep 10, 2014 at 02:24:17AM +0100, Greg Stark wrote:
> On Tue, Sep 9, 2014 at 4:05 PM, Bruce Momjian wrote:
> >> > Yes, I did think about that, but it seems like a behavior change.
> >> > However, it is tempting to avoid future bug reports about this.
> >>
> >> When this came up in March, T
On Tue, Sep 9, 2014 at 4:05 PM, Bruce Momjian wrote:
>> > Yes, I did think about that, but it seems like a behavior change.
>> > However, it is tempting to avoid future bug reports about this.
>>
>> When this came up in March, Tom and I agreed that this wasn't something
>> we wanted to slip into 9
On Sat, Sep 6, 2014 at 09:30:06AM -0400, Bruce Momjian wrote:
> On Fri, Sep 5, 2014 at 07:35:42PM -0400, Bruce Momjian wrote:
> > On Sat, Sep 6, 2014 at 12:26:55AM +0100, Greg Stark wrote:
> > > On Wed, Sep 3, 2014 at 3:59 AM, Bruce Momjian wrote:
> > > > I have developed the attached patch whi
On Fri, Sep 5, 2014 at 07:35:42PM -0400, Bruce Momjian wrote:
> On Sat, Sep 6, 2014 at 12:26:55AM +0100, Greg Stark wrote:
> > On Wed, Sep 3, 2014 at 3:59 AM, Bruce Momjian wrote:
> > > I have developed the attached patch which causes pg_upgrade to preserve
> > > the transaction epoch. I plan t
On Sat, Sep 6, 2014 at 12:26:55AM +0100, Greg Stark wrote:
> On Wed, Sep 3, 2014 at 3:59 AM, Bruce Momjian wrote:
> > I have developed the attached patch which causes pg_upgrade to preserve
> > the transaction epoch. I plan to apply this for PG 9.5.
>
> I would say this is a simple bug and shou
On Wed, Sep 3, 2014 at 3:59 AM, Bruce Momjian wrote:
> I have developed the attached patch which causes pg_upgrade to preserve
> the transaction epoch. I plan to apply this for PG 9.5.
I would say this is a simple bug and should be back patched to 9.4 and
9.3. We're only going to continue to get
On Tue, Sep 2, 2014 at 10:38:55PM -0700, Sergey Konoplev wrote:
> On Tue, Sep 2, 2014 at 7:59 PM, Bruce Momjian wrote:
> > On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote:
> >> On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote:
> >> > Sergey, are you seeing a problem only beca
On Tue, Sep 2, 2014 at 7:59 PM, Bruce Momjian wrote:
> On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote:
>> On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote:
>> > Sergey, are you seeing a problem only because you are
>> > interacting with other systems that didn't reset their e
On Wed, Apr 23, 2014 at 12:41:41PM -0700, Sergey Konoplev wrote:
> On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote:
> > Sergey, are you seeing a problem only because you are
> > interacting with other systems that didn't reset their epoch?
>
> I faced this after upgrading clusters with PgQ S
On Wed, Apr 23, 2014 at 5:26 AM, Bruce Momjian wrote:
> Sergey, are you seeing a problem only because you are
> interacting with other systems that didn't reset their epoch?
I faced this after upgrading clusters with PgQ Skytools3 installed
only. They didn't interact with any other systems.
--
On Wed, Apr 23, 2014 at 07:08:42AM +0400, Sergey Burladyan wrote:
> On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev wrote:
>
>
> BTW, I didn't manage to make a test case yet. Recently, when I was
> migrating several servers to skytools3 and upgrading from 9.0 to 9.2,
> I noticed tha
On Tue, Apr 22, 2014 at 8:08 PM, Sergey Burladyan wrote:
> On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev wrote:
>> BTW, I didn't manage to make a test case yet. Recently, when I was
>> migrating several servers to skytools3 and upgrading from 9.0 to 9.2,
>> I noticed that epoch was copied, tim
On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev wrote:
>
> BTW, I didn't manage to make a test case yet. Recently, when I was
> migrating several servers to skytools3 and upgrading from 9.0 to 9.2,
> I noticed that epoch was copied, timeline id was >0 after upgrade, but
>
...
This is strange, i
On Tue, Apr 22, 2014 at 6:33 PM, Sergey Burladyan wrote:
> Current pg_upgrade copy XID into new cluster, but not it epoch. Why?
>
> Without epoch from old cluster txid_current() in upgraded database return
> lower value than before upgrade. This break, for example, PgQ and it must
> be fixed by ha
Hi All!
Current pg_upgrade copy XID into new cluster, but not it epoch. Why?
Without epoch from old cluster txid_current() in upgraded database return
lower value than before upgrade. This break, for example, PgQ and it must
be fixed by hand after upgrade with pg_resetxlog.
PS: see
http://lists.
18 matches
Mail list logo
