On 13.06.2011 22:33, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 13.06.2011 21:31, Tom Lane wrote:
So far as I can tell, that breaks pg_upgrade (if there are any open
prepared transactions) for no redeeming social benefit.
Surely pg_upgrade can't work
Heikki Linnakangas wrote:
Ok, I've renumbered the existing RMs back the way they were.
Don't we also need something like the attached?
-Kevin
ssi-twophase-c.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 14.06.2011 15:14, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Ok, I've renumbered the existing RMs back the way they were.
Don't we also need something like the attached?
Yes. I just committed a fix for that after noticing that the buildfarm
didn't like it. Sorry..
--
Heikki
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
No, pg_upgrade should not be unilaterally refusing that.
Uh, isn't there some physical files in pg_twophase/ that stick around to
keep prepared transactions --- if so, pg_upgrade does not copy them from
the old
Bruce Momjian wrote:
This argument seems a tad peculiar, since the *entire* *point* of
pg_upgrade is to push physical files from one installation into another
even though compatibility isn't guaranteed. It is the program's duty to
understand enough to know whether it can transport the
So I finally started actually reading the SSI changes, and I am a tad
distressed by this:
diff --git a/src/include/access/twophase_rmgr.h
b/src/include/access/twophase_rmgr.h
index a541d0f..1c7d8bb 100644
--- a/src/include/access/twophase_rmgr.h
+++ b/src/include/access/twophase_rmgr.h
@@ -23,8
Tom Lane t...@sss.pgh.pa.us wrote:
What was the rationale for changing the assignments of existing
2PC IDs? So far as I can tell, that breaks pg_upgrade (if there
are any open prepared transactions) for no redeeming social
benefit. Is there a reason why TWOPHASE_RM_PREDICATELOCK_ID has
to
On 13.06.2011 21:31, Tom Lane wrote:
So I finally started actually reading the SSI changes, and I am a tad
distressed by this:
diff --git a/src/include/access/twophase_rmgr.h
b/src/include/access/twophase_rmgr.h
index a541d0f..1c7d8bb 100644
--- a/src/include/access/twophase_rmgr.h
+++
On Mon, Jun 13, 2011 at 10:22:19PM +0300, Heikki Linnakangas wrote:
As far as I can tell it was for purely cosmetic reasons, to have lock
and predicate lock lines together.
Yes, that is the only reason.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
Sent
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 13.06.2011 21:31, Tom Lane wrote:
So far as I can tell, that breaks pg_upgrade (if there are any open
prepared transactions) for no redeeming social benefit.
Surely pg_upgrade can't work anyway if there's any open prepared
On Mon, Jun 13, 2011 at 03:33:24PM -0400, Tom Lane wrote:
We can either change that now, or undo the
unnecessary change in existing RM IDs. I vote for the latter.
Sounds good to me. I'd offer a patch, but it'd probably take you longer
to apply than to make the change yourself.
Dan
--
Dan R.
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 13.06.2011 21:31, Tom Lane wrote:
So far as I can tell, that breaks pg_upgrade (if there are any open
prepared transactions) for no redeeming social benefit.
Surely pg_upgrade can't work anyway if there's
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
No, pg_upgrade should not be unilaterally refusing that.
Uh, isn't there some physical files in pg_twophase/ that stick around to
keep prepared transactions --- if so, pg_upgrade does not copy them from
the old cluster to the new one. I
13 matches
Mail list logo
