Zdenek Kotala wrote:
> You mentioned data types, but it is not a problem. You can easily extend data
> type attribute about version information and call correct in/out functions.
> Or
> use different Oid for new data type version. There are more possible easy
> solutions for data types. And for
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Another idea is to create backward compatible AM and put them into separate
library. If these AM will work also with old page structure then there should
not be reason for reindexing or index page conversion after upgrade.
I don't
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you "inject" old
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release
to implement upgrade-in-place. There's
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The bpchar_pattern_ops change you mentioned must be this one:
>> A not-immediately-obvious incompatibility is that the sort order within
>> bpchar_pattern_ops indexes changes --- it had been identical to plain
>> strcmp, but is now trailing-blank-ins
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Another idea is to create backward compatible AM and put them into separate
> library. If these AM will work also with old page structure then there should
> not be reason for reindexing or index page conversion after upgrade.
I don't think that'd be re
Zdenek Kotala wrote:
Tom Lane napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the
FSM rewrite. Not sure about DSM yet.
Does it mean, that if you "inject" old data file after catalog upgrade
Heikki Linnakangas napsal(a):
Tom Lane wrote:
I didn't see anything that looked like an immediate change in user table
contents, unless they used the "name" type; but what of relation forks?
Relation forks didn't change anything inside relation files, so no
scanning of relations is required b
Tom Lane napsal(a):
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but AFAICS
nothing that wo
Bruce Momjian napsal(a):
Heikki Linnakangas wrote:
Bruce Momjian wrote:
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
VACUUM?
Having to run a manual command defeats the purpose somewha
Bruce Momjian napsal(a):
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
Keep in a mind that there are more kind of pages. Heap is easy, but each index
AM has own specific :(. Better app
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which w
Gregory Stark wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Relation forks didn't change anything inside relation files, so no scanning of
relations is required because of that. Neither will the FSM rewrite. Not sure
about DSM yet.
And just to confirm -- they don't change the name of t
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I didn't see anything that looked like an immediate change in user table
>> contents, unless they used the "name" type; but what of relation forks?
>
> Relation forks didn't change anything inside relation files, so no scanning of
Tom Lane wrote:
I didn't see anything that looked like an immediate change in user table
contents, unless they used the "name" type; but what of relation forks?
Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will th
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> In fact, I don't think there's any low-level data format changes yet
> between 8.3 and 8.4, so this would be a comparatively easy release to
> implement upgrade-in-place. There's just the catalog changes, but AFAICS
> nothing that would require sc
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > As far as the page not fitting after conversion, what about some user
> > command that will convert an entire table to the new format if page
> > expansion fails.
>
> VACUUM?
>
> Having to run a manual command defeats the purpose somewhat, thou
Bruce Momjian wrote:
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
VACUUM?
Having to run a manual command defeats the purpose somewhat, though.
Especially if you have no way of knowing
Heikki Linnakangas wrote:
> > 4) This patch contains more topics for decision. First is general if
> > this approach is acceptable.
>
> I don't like the invasiveness of this approach. It's pretty invasive
> already, and ISTM you'll need similar switch-case handling of all data
> types that have
On Fri, 5 Sep 2008, Heikki Linnakangas wrote:
All in all, though. I find it a bit hard to see the big picture.
I've been working on trying to see that myself lately, have been dumping
links to all the interesting material at
http://wiki.postgresql.org/wiki/In-place_upgrade if there's any of
Zdenek Kotala wrote:
Heikki Linnakangas napsal(a):
The patch seems to be missing the new htup.c file.
I'm sorry. I attached new version which is synchronized with current
head. I would like to say more comments as well.
1) The patch contains also changes which was discussed during July
commi
22 matches
Mail list logo
