Jesse Denardo escribió:
> Alvaro,
>
> I applied the patch and tried upgrading again, and everything seemed to
> work as expected. We are now up and running the beta!
Pushed, thanks.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Se
On 2013-08-02 22:25:36 -0400, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> > > Alvaro Herrera escribió:
> > >
> > > > As it turns out, I have a patched slru.c that adds a new function to
> > > > verify whether a page exists on disk. I c
On Fri, Aug 2, 2013 at 11:20:37PM -0400, Jesse Denardo wrote:
> Alvaro,
>
> I applied the patch and tried upgrading again, and everything seemed to work
> as
> expected. We are now up and running the beta!
Yeah, great, thanks everyone!
--
Bruce Momjian http://momjian.us
Enterpris
Alvaro,
I applied the patch and tried upgrading again, and everything seemed to
work as expected. We are now up and running the beta!
--
Jesse Denardo
On Fri, Aug 2, 2013 at 10:25 PM, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> > >
Andres Freund escribió:
> On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> > Alvaro Herrera escribió:
> >
> > > As it turns out, I have a patched slru.c that adds a new function to
> > > verify whether a page exists on disk. I created this for the commit
> > > timestamp module, for the BDR b
On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> Alvaro Herrera escribió:
>
> > As it turns out, I have a patched slru.c that adds a new function to
> > verify whether a page exists on disk. I created this for the commit
> > timestamp module, for the BDR branch, but I think it's what we need
Alvaro Herrera escribió:
> As it turns out, I have a patched slru.c that adds a new function to
> verify whether a page exists on disk. I created this for the commit
> timestamp module, for the BDR branch, but I think it's what we need
> here.
Here's a patch that should fix the problem. Jesse,
Jesse Denardo escribió:
> $ 9.2_dev/bin/pg_controldata data
> Latest checkpoint's NextMultiXactId: 2982
> Latest checkpoint's NextMultiOffset: 6479
So what's happening here is that the MultiXact 2982 lives in a SLRU page
that doesn't exist. pg_upgrade didn't copy the pg_multixact files from
t
$ 9.2_dev/bin/pg_controldata data
pg_control version number:922
Catalog version number: 201204301
Database system identifier: 5789770930315980286
Database cluster state: shut down
pg_control last modified: Tue 30 Jul 2013 09:57:54 AM EDT
On Wed, Jul 31, 2013 at 12:56:33PM -0400, Alvaro Herrera wrote:
> Bruce Momjian escribió:
> > On Tue, Jul 30, 2013 at 10:17:52AM -0400, Jesse Denardo wrote:
>
> > So, first, this is new in 9.3, and second, it seems the comment "we need
> > to reset pg_control so that the new server doesn't attempt
Bruce Momjian escribió:
> On Tue, Jul 30, 2013 at 10:17:52AM -0400, Jesse Denardo wrote:
> So, first, this is new in 9.3, and second, it seems the comment "we need
> to reset pg_control so that the new server doesn't attempt to read
> multis older than the cutoff value" is not working. Alvaro, ca
On Tue, Jul 30, 2013 at 10:17:52AM -0400, Jesse Denardo wrote:
> Name: Jesse Denardo
> Release: 9.2.2 -> 9.3beta2
> Test Type: Install/Upgrade Test
> Test Detail: pg_upgrade in a fresh install of 9.3beta2
> Platform: Debian Linux 6.0.5
> Installation Method: From source
> Platform Detail: Debian Li
Name: Jesse Denardo
Release: 9.2.2 -> 9.3beta2
Test Type: Install/Upgrade Test
Test Detail: pg_upgrade in a fresh install of 9.3beta2
Platform: Debian Linux 6.0.5
Installation Method: From source
Platform Detail: Debian Linux 6.0.5, 2.6.32.45-grsec-2.2.2-r3, x86_64
Test Procedure:
I made a byte fo
13 matches
Mail list logo
