On Thu, Jun 3, 2010 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
On Jun 3, 2010, at 19:00 , Tom Lane wrote:
Maybe we should just get rid of the hint.
FYI, Robert Haas suggested the same in the thread that lead to this patch
being applied. The arguments
Dave Page wrote:
On Thu, Jun 3, 2010 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
On Jun 3, 2010, at 19:00 , Tom Lane wrote:
Maybe we should just get rid of the hint.
FYI, Robert Haas suggested the same in the thread that lead to this patch
Bruce Momjian br...@momjian.us writes:
Dave Page wrote:
Shouldn't we have bumped the catversion? The installers can't tell
that beta1 clusters won't work with beta2 :-(
That is an interesting point. Tom bumped the pg_control version, but
not the catalog version.
Right, because the catalog
On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Dave Page wrote:
Shouldn't we have bumped the catversion? The installers can't tell
that beta1 clusters won't work with beta2 :-(
That is an interesting point. Tom bumped the pg_control
On Fri, Jun 4, 2010 at 11:06 AM, Dave Page dp...@pgadmin.org wrote:
On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Dave Page wrote:
Shouldn't we have bumped the catversion? The installers can't tell
that beta1 clusters won't work with
Dave Page dp...@pgadmin.org writes:
On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, because the catalog contents didn't change. Seems to me you'd
better teach the installers to look at PG_CONTROL_VERSION too.
Hmm, is there anything else that might need to be
Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, because the catalog contents didn't change. ?Seems to me you'd
better teach the installers to look at PG_CONTROL_VERSION too.
Hmm, is there anything else that
Robert Haas robertmh...@gmail.com writes:
It would be nice to have all of these documented somewhere along with
the criteria for bumping each one.
Go for it. I think you have all the raw data in this thread.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Fri, Jun 4, 2010 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, because the catalog contents didn't change. Seems to me you'd
better teach the installers to look at
Dave Page dp...@pgadmin.org writes:
On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
XLOG_PAGE_MAGIC --- bump on incompatible change in WAL contents
How can I get that from an existing data directory? I don't see it in
pg_controldata output (unless it has a non-obvious
On Fri, Jun 4, 2010 at 7:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Fri, Jun 4, 2010 at 4:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
XLOG_PAGE_MAGIC --- bump on incompatible change in WAL contents
How can I get that from an existing data directory? I don't
Because that's the consequences of fooling with pg_control.
I committed the PG_CONTROL_VERSION bump that was missing from
the patch Robert committed last night, but I wonder whether
we shouldn't revert the whole thing instead. It's not apparent
to me that what it bought is worth forcing beta
On 03/06/10 17:54, Tom Lane wrote:
Because that's the consequences of fooling with pg_control.
I committed the PG_CONTROL_VERSION bump that was missing from
the patch Robert committed last night, but I wonder whether
we shouldn't revert the whole thing instead. It's not apparent
to me that what
On Thu, Jun 3, 2010 at 11:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 03/06/10 17:54, Tom Lane wrote:
Because that's the consequences of fooling with pg_control.
I committed the PG_CONTROL_VERSION bump that was missing from
the patch Robert committed last night,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
If we moved the new DB_SHUTDOWNED_IN_RECOVERY as the last item in the
enum, we would stay backwards-compatible.
I don't think that's a terribly workable idea; the enum is laid out so
that inequality tests are sensible, and I'm not
On 03/06/10 19:16, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
If we moved the new DB_SHUTDOWNED_IN_RECOVERY as the last item in the
enum, we would stay backwards-compatible.
I don't think that's a terribly workable idea; the enum is laid out so
that
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 03/06/10 19:16, Tom Lane wrote:
What exactly was the reason for this patch? Could it be held over till
9.1?
Before the patch, when you shut down a standby server, you get this
message in the log on the next startup:
LOG:
On Jun 3, 2010, at 19:00 , Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 03/06/10 19:16, Tom Lane wrote:
What exactly was the reason for this patch? Could it be held over till
9.1?
Before the patch, when you shut down a standby server, you get this
Florian Pflug f...@phlo.org writes:
On Jun 3, 2010, at 19:00 , Tom Lane wrote:
Maybe we should just get rid of the hint.
FYI, Robert Haas suggested the same in the thread that lead to this patch
being applied. The arguments against doing that is that a real crash during
recovery *is*
19 matches
Mail list logo
