Thread: How to compile with different MAXALIGN?
I'm in the process of moving a large database from an in-house Win32 server to a co-located Ubuntu Linux server. The data's in constant use, so I can't really bring the server down for more than a half hour or so, and I'd like to go ahead and use a base backup + WAL restore strategy to sync the servers up before flipping the switch. After copying over my base backup and setting ACL appropriately, when I go to start the server on Linux it fails with a message in the log stating that the cluster (binary copy from the W32 server) is initialized MAXALIGN 8 and the server is compiled MAXALIGN 4. A search of the Docs tells me that I can compile the server with a different MAXALIGN, but the install docs don't give any indication how this is achieved. Is there a configure or gmake option I can feed, or do I need to change a line in one (or more) of the source files? Or is there a compelling reason (I'm absolutely ignorant here) to do a dump and restore instead of the binary copy because MAXALIGN 4 is better for performance/security/fill-in-the-blank? Or is a binary copy move from W to L hopeless even if this particular issue isn't? Thanks Sean
From experience I would say NEVER NEVER try and do a direct copy across different platforms (Windows -> Linux.) Someone may contradict me, but I think a dump/restore would be the way to go. What sort of size of data are we talking? You'll need to factor in the time it takes to dump the data, the time it takes to transfer the dump to your new machine, and the time it takes to restore it. Andy. Sean Murphy wrote: > I'm in the process of moving a large database from an in-house Win32 > server to a co-located Ubuntu Linux server. The data's in constant use, > so I can't really bring the server down for more than a half hour or so, > and I'd like to go ahead and use a base backup + WAL restore strategy to > sync the servers up before flipping the switch. > > After copying over my base backup and setting ACL appropriately, when I > go to start the server on Linux it fails with a message in the log > stating that the cluster (binary copy from the W32 server) is > initialized MAXALIGN 8 and the server is compiled MAXALIGN 4. A search > of the Docs tells me that I can compile the server with a different > MAXALIGN, but the install docs don't give any indication how this is > achieved. Is there a configure or gmake option I can feed, or do I need > to change a line in one (or more) of the source files? > > Or is there a compelling reason (I'm absolutely ignorant here) to do a > dump and restore instead of the binary copy because MAXALIGN 4 is better > for performance/security/fill-in-the-blank? > > Or is a binary copy move from W to L hopeless even if this particular > issue isn't? > > Thanks > Sean > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > > !DSPAM:37,46141bf689292106146716! > > >
We're talking about 12 GB of data... to do the [probably ill-fated] binary copy in any reasonable amount of time required a portable hard drive and sneaker-net... That's why I'm anxious, probably to the point of stupidity, to avoid a situation where I'll have to bring the db down long enough to pull a backup dump onto portable media, drive to the colo, and restore it... (I'll do a pre-live test run of whatever procedure I go with, but...) Sean Andy Shellam wrote: > From experience I would say NEVER NEVER try and do a direct copy across > different platforms (Windows -> Linux.) > Someone may contradict me, but I think a dump/restore would be the way > to go. > > What sort of size of data are we talking? You'll need to factor in the > time it takes to dump the data, the time it takes to transfer the dump > to your new machine, and the time it takes to restore it. > > Andy. > > Sean Murphy wrote: >> I'm in the process of moving a large database from an in-house Win32 >> server to a co-located Ubuntu Linux server. The data's in constant use, >> so I can't really bring the server down for more than a half hour or so, >> and I'd like to go ahead and use a base backup + WAL restore strategy to >> sync the servers up before flipping the switch. >> >> After copying over my base backup and setting ACL appropriately, when I >> go to start the server on Linux it fails with a message in the log >> stating that the cluster (binary copy from the W32 server) is >> initialized MAXALIGN 8 and the server is compiled MAXALIGN 4. A search >> of the Docs tells me that I can compile the server with a different >> MAXALIGN, but the install docs don't give any indication how this is >> achieved. Is there a configure or gmake option I can feed, or do I need >> to change a line in one (or more) of the source files? >> >> Or is there a compelling reason (I'm absolutely ignorant here) to do a >> dump and restore instead of the binary copy because MAXALIGN 4 is better >> for performance/security/fill-in-the-blank? >> >> Or is a binary copy move from W to L hopeless even if this particular >> issue isn't? >> >> Thanks >> Sean >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 3: Have you checked our extensive FAQ? >> >> http://www.postgresql.org/docs/faq >> >> !DSPAM:37,46141bf689292106146716! >> >> >> > >
Is there any chance of you setting up a temporary machine on the same network as your Windows one but an identical build as your co-located machine? Then you can transfer your Windows data to Linux using pg_dump/restore, switch your apps over to the Linux machine, then use WAL files to mimic the changes onto your co-location. Once you're new co-lo machine is at the same stage as your temporary one, switch the application over to your co-lo machine and turn the temp and Windows machines off. Failing that perhaps someone with experience of Slony would be able guide you if this is possible with Slony? Andy. Sean Murphy wrote: > We're talking about 12 GB of data... to do the [probably ill-fated] > binary copy in any reasonable amount of time required a portable hard > drive and sneaker-net... > > That's why I'm anxious, probably to the point of stupidity, to avoid a > situation where I'll have to bring the db down long enough to pull a > backup dump onto portable media, drive to the colo, and restore it... > > (I'll do a pre-live test run of whatever procedure I go with, but...) > > Sean > > Andy Shellam wrote: > >> From experience I would say NEVER NEVER try and do a direct copy across >> different platforms (Windows -> Linux.) >> Someone may contradict me, but I think a dump/restore would be the way >> to go. >> >> What sort of size of data are we talking? You'll need to factor in the >> time it takes to dump the data, the time it takes to transfer the dump >> to your new machine, and the time it takes to restore it. >> >> Andy. >> >> Sean Murphy wrote: >> >>> I'm in the process of moving a large database from an in-house Win32 >>> server to a co-located Ubuntu Linux server. The data's in constant use, >>> so I can't really bring the server down for more than a half hour or so, >>> and I'd like to go ahead and use a base backup + WAL restore strategy to >>> sync the servers up before flipping the switch. >>> >>> After copying over my base backup and setting ACL appropriately, when I >>> go to start the server on Linux it fails with a message in the log >>> stating that the cluster (binary copy from the W32 server) is >>> initialized MAXALIGN 8 and the server is compiled MAXALIGN 4. A search >>> of the Docs tells me that I can compile the server with a different >>> MAXALIGN, but the install docs don't give any indication how this is >>> achieved. Is there a configure or gmake option I can feed, or do I need >>> to change a line in one (or more) of the source files? >>> >>> Or is there a compelling reason (I'm absolutely ignorant here) to do a >>> dump and restore instead of the binary copy because MAXALIGN 4 is better >>> for performance/security/fill-in-the-blank? >>> >>> Or is a binary copy move from W to L hopeless even if this particular >>> issue isn't? >>> >>> Thanks >>> Sean >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 3: Have you checked our extensive FAQ? >>> >>> http://www.postgresql.org/docs/faq >>> >>> >>> >>> >>> >>> >> > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > > !DSPAM:37,46141ebe89298265317040! > > >
Sean Murphy wrote:
> We're talking about 12 GB of data... to do the [probably ill-fated]
> binary copy in any reasonable amount of time required a portable hard
> drive and sneaker-net...
>
> That's why I'm anxious, probably to the point of stupidity, to avoid a
> situation where I'll have to bring the db down long enough to pull a
> backup dump onto portable media, drive to the colo, and restore it...
Slony?
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Slony doesn't do LOs... Joshua D. Drake wrote: > Sean Murphy wrote: >> We're talking about 12 GB of data... to do the [probably ill-fated] >> binary copy in any reasonable amount of time required a portable hard >> drive and sneaker-net... >> >> That's why I'm anxious, probably to the point of stupidity, to avoid a >> situation where I'll have to bring the db down long enough to pull a >> backup dump onto portable media, drive to the colo, and restore it... > > Slony? > > Sincerely, > > Joshua D. Drake
Actually the colo machine is running Windows as well (not my call, but there are other workloads on it) but Ubuntu is running under VMWare, so I could install a truly identical copy of the colo "machine" on the same server I'm moving from... Thanks! Andy Shellam wrote: > Is there any chance of you setting up a temporary machine on the same > network as your Windows one but an identical build as your co-located > machine? Then you can transfer your Windows data to Linux using > pg_dump/restore, switch your apps over to the Linux machine, then use > WAL files to mimic the changes onto your co-location. > > Once you're new co-lo machine is at the same stage as your temporary > one, switch the application over to your co-lo machine and turn the temp > and Windows machines off. > > Failing that perhaps someone with experience of Slony would be able > guide you if this is possible with Slony? > > Andy. > > Sean Murphy wrote: >> We're talking about 12 GB of data... to do the [probably ill-fated] >> binary copy in any reasonable amount of time required a portable hard >> drive and sneaker-net... >> >> That's why I'm anxious, probably to the point of stupidity, to avoid a >> situation where I'll have to bring the db down long enough to pull a >> backup dump onto portable media, drive to the colo, and restore it... >> >> (I'll do a pre-live test run of whatever procedure I go with, but...) >> >> Sean >> >> Andy Shellam wrote: >> >>> From experience I would say NEVER NEVER try and do a direct copy across >>> different platforms (Windows -> Linux.) >>> Someone may contradict me, but I think a dump/restore would be the way >>> to go. >>> >>> What sort of size of data are we talking? You'll need to factor in the >>> time it takes to dump the data, the time it takes to transfer the dump >>> to your new machine, and the time it takes to restore it. >>> >>> Andy. >>> >>> Sean Murphy wrote: >>> >>>> I'm in the process of moving a large database from an in-house Win32 >>>> server to a co-located Ubuntu Linux server. The data's in constant use, >>>> so I can't really bring the server down for more than a half hour or >>>> so, >>>> and I'd like to go ahead and use a base backup + WAL restore >>>> strategy to >>>> sync the servers up before flipping the switch. >>>> >>>> After copying over my base backup and setting ACL appropriately, when I >>>> go to start the server on Linux it fails with a message in the log >>>> stating that the cluster (binary copy from the W32 server) is >>>> initialized MAXALIGN 8 and the server is compiled MAXALIGN 4. A search >>>> of the Docs tells me that I can compile the server with a different >>>> MAXALIGN, but the install docs don't give any indication how this is >>>> achieved. Is there a configure or gmake option I can feed, or do I need >>>> to change a line in one (or more) of the source files? >>>> >>>> Or is there a compelling reason (I'm absolutely ignorant here) to do a >>>> dump and restore instead of the binary copy because MAXALIGN 4 is >>>> better >>>> for performance/security/fill-in-the-blank? >>>> >>>> Or is a binary copy move from W to L hopeless even if this particular >>>> issue isn't? >>>> >>>> Thanks >>>> Sean >>>> >>>> ---------------------------(end of >>>> broadcast)--------------------------- >>>> TIP 3: Have you checked our extensive FAQ? >>>> >>>> http://www.postgresql.org/docs/faq >>>> >>>> >>>> >>>> >>>> >>> >> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 9: In versions below 8.0, the planner will ignore your desire to >> choose an index scan if your joining column's datatypes do not >> match >> >> !DSPAM:37,46141ebe89298265317040! >> >> >> > >
Sean Murphy wrote: > search of the Docs tells me that I can compile the server with a > different MAXALIGN, but the install docs don't give any indication > how this is achieved. Is there a configure or gmake option I can > feed, or do I need to change a line in one (or more) of the source > files? Alignment is a property dictated by the compiler, so the official way to change that is to argue with your compiler. On Linux i386, it seems that the option -malign-double will get you the 8 byte alignment that might be compatible with your Windows build. All of this, however, is totally unofficial and highly risky, because an alignment difference might indicate that there are other differences in the binary data layout that are not caught by the existing checks. You will get data corruption if you are wrong. Moreover, a build with a nonstandard alignment will be incompatible with everything else on your system in ways that are hard to define in brief, so interfacing with other libraries or modules will possibly be broken, as will your next PostgreSQL upgrade. -- Peter Eisentraut http://developer.postgresql.org/~petere/