Josh Berkus wrote:
Here's a way to trap yourself:
(1) Set up an HS/SR master
(2) pg_start_backup on the master
(3) clone the master to 1 or more slaves
(4) Fast shutdown the master (without pg_stop_backup)
(5) Restart the master
(6) Bring up the slaves
Result: the slaves will come up
Heikki Linnakangas wrote:
Robert Haas wrote:
On Fri, Apr 23, 2010 at 4:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, actually, now that I've looked at the patch I think it's starting
from a fundamentally wrong position anyway. Checkpoint records are a
completely wrong mechanism for
On Tue, Apr 27, 2010 at 4:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, we could throw an error in the standby, when we see a shutdown
checkpoint while we're waiting for an end-backup record. If the database
was shut down before pg_stop_backup(), we know that the
Robert Haas robertmh...@gmail.com writes:
On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
Would it be possible to have internal commands there, as for example
cd is in my shell, or test, or time, or some more ?
That would allow for providing a portable /usr/bin/true command as far
Fujii Masao wrote:
On Tue, Apr 27, 2010 at 4:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, we could throw an error in the standby, when we see a shutdown
checkpoint while we're waiting for an end-backup record. If the database
was shut down before pg_stop_backup(),
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Apr 26, 2010 at 9:26 PM, Bruce Momjian br...@momjian.us wrote:
There was talk of including pg_migrator in Postgres 9.0 in /contrib. ?Do
we still want to do that?
I think you articulated some pretty good reasons previously
On Tue, Apr 27, 2010 at 5:09 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, here's a patch that includes the changes to add new wal_mode GUC
(http://archives.postgresql.org/message-id/4bd581a6.60...@enterprisedb.com),
and implements Tom's design to keep a copy of wal_mode
Fujii Masao wrote:
config.sgml
literalon/literal. It is thought that there is little
measurable difference in performance from using this feature, so
feedback is welcome if any production impacts are noticeable.
It is likely that this parameter will be removed in later releases.
Is this
On Tue, Apr 27, 2010 at 6:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
config.sgml
literalon/literal. It is thought that there is little
measurable difference in performance from using this feature, so
feedback is welcome if any production impacts
I heard pg_get_encoding_from_locale() failed in kor locale.
WARNING: could not determine encoding for locale kor: codeset is CP949
I found the following description in the web:
CP949 is EUC-KR, extended with UHC (Unified Hangul Code).
Fujii Masao wrote:
On Tue, Apr 27, 2010 at 6:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
if (!XLogArchivingActive())
ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg(WAL archiving is not active),
Takahiro Itagaki wrote:
I heard pg_get_encoding_from_locale() failed in kor locale.
WARNING: could not determine encoding for locale kor: codeset is
CP949
I found the following description in the web:
CP949 is EUC-KR, extended with UHC (Unified Hangul Code).
On Tue, Apr 27, 2010 at 5:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yep. I've committed a patch to do that.
Is there no way for the slave to recover from this situation?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Tue, Apr 27, 2010 at 4:07 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, 2010-04-26 at 10:41 +0200, Dimitri Fontaine wrote:
Would it be possible to have internal commands there, as for example
cd is in my shell, or test, or time, or some
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Should we add (or replace) CP949 for EUC-KR?
No. CP949 is not plain EUC-KR, but EUC-KR with some extensions (UHC). At
least on CVS HEAD, we recognize CP949 as an alias for the PostgreSQL
PG_UHC encoding.
That's it! We should
On Tue, Apr 27, 2010 at 7:50 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's OK in pg_start_backup(), but seems NG in pg_stop_backup() since
it waits until some WAL files have been archived by the archiver. No?
Good point, that logic would need to be changed too. Should
On Tue, Apr 27, 2010 at 8:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 27, 2010 at 5:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yep. I've committed a patch to do that.
Is there no way for the slave to recover from this situation?
Probably Yes. You
Bruce Momjian wrote:
I concur; it's about a month too late to propose this.
I am confused why it is late. We add to /contrib even during beta, and
I didn't bring it up earlier because I didn't want to be pushing my own
software. Was someone else supposed to suggest it a month ago?
On Tue, Apr 27, 2010 at 7:24 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Apr 27, 2010 at 7:50 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's OK in pg_start_backup(), but seems NG in pg_stop_backup() since
it waits until some WAL files have been archived by the
On Tue, 2010-04-27 at 12:25 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
On Tue, Apr 27, 2010 at 4:19 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, we could throw an error in the standby, when we see a shutdown
checkpoint while we're waiting for an
Robert Haas robertmh...@gmail.com writes:
Treating the string true as a special case seems like a kludge to
me. Maybe a robust set of internal commands wouldn't be a kludge, but
that's not what's being proposed here. I guess it's just a matter of
opinion.
I don't see how to have internal
On Tue, 2010-04-27 at 15:10 +0200, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
Treating the string true as a special case seems like a kludge to
me. Maybe a robust set of internal commands wouldn't be a kludge, but
that's not what's being proposed here. I guess it's
Thinking about allowing a backup to tell which files have changed in the
database since last backup. This would allow an external utility to copy
away only changed files.
Now there's a few ways of doing this and many will say this is already
possible using file access times.
An explicit
Simon Riggs wrote:
Thinking about allowing a backup to tell which files have changed in the
database since last backup. This would allow an external utility to copy
away only changed files.
Now there's a few ways of doing this and many will say this is already
possible using file access
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, we could throw an error in the standby, when we see a shutdown
checkpoint while we're waiting for an end-backup record. If the database
was shut down before pg_stop_backup(), we know that the backup was
cancelled and the
On Tue, 2010-04-27 at 09:50 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
Thinking about allowing a backup to tell which files have changed in the
database since last backup. This would allow an external utility to copy
away only changed files.
Now there's a few ways of doing this
Simon Riggs si...@2ndquadrant.com wrote:
Thinking about allowing a backup to tell which files have changed
in the database since last backup. This would allow an external
utility to copy away only changed files.
Now there's a few ways of doing this and many will say this is
already
On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
An explicit mechanism where Postgres could authoritatively say
which files have changed would make many feel safer, especially
when other databases also do this.
Why? I must be missing something, because my feeling is that if you
On Apr 27, 2010, at 15:50 , Alvaro Herrera wrote:
Simon Riggs wrote:
Thinking about allowing a backup to tell which files have changed in the
database since last backup. This would allow an external utility to copy
away only changed files.
Now there's a few ways of doing this and many will
On Apr 27, 2010, at 16:08 , Simon Riggs wrote:
On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
Why? I must be missing something, because my feeling is that if you
can't trust your OS to cover something like this, how can you trust
any application *running* under that OS to do it?
On 04/27/2010 09:59 AM, Kevin Grittner wrote:
Under what circumstances would PostgreSQL
modify a file without changing the last modified timestamp or the
file size?
Do all OSes have sub-second precision mtimes? Because otherwise I could
see a scenario such at this:
* File is modified
*
On Apr 27, 2010, at 9:20 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-04-27 at 15:10 +0200, Dimitri Fontaine wrote:
Robert Haas robertmh...@gmail.com writes:
Treating the string true as a special case seems like a kludge to
me. Maybe a robust set of internal commands wouldn't be
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, we could throw an error in the standby, when we see a shutdown
checkpoint while we're waiting for an end-backup record. If the database
was shut down before pg_stop_backup(), we know that the backup was
Robert Haas wrote:
On Tue, Apr 27, 2010 at 5:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yep. I've committed a patch to do that.
Is there no way for the slave to recover from this situation?
No, it will never open up for hot standby, and it will error at the end
of
On Tue, Apr 27, 2010 at 10:32 AM, Michael Tharp
g...@partiallystapled.com wrote:
On 04/27/2010 09:59 AM, Kevin Grittner wrote:
Under what circumstances would PostgreSQL
modify a file without changing the last modified timestamp or the
file size?
Do all OSes have sub-second precision mtimes?
Merlin Moncure mmonc...@gmail.com wrote:
The proposal only seems a win to me if a fair percentage of the
larger files don't change, which strikes me as a relatively low
level case to optimize for.
That's certainly a situation we face, with a relatively slow WAN in
the middle.
Simon Riggs wrote:
If pg_stop_backup() is run it creates the .backup file in the archive.
In the absence of that file, we should be able to work out that
pg_stop_backup() was not run.
It's just as likely that the file is there even though the backup didn't
finish, though.
--
Heikki
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
Isn't the above statement complete nonsense? There's nothing to stop
the DBA from issuing pg_stop_backup() after he restarts the master.
pg_stop_backup() can't be called if there's no backup in progress.
Restart
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Ok, here's a patch that includes the changes to add new wal_mode GUC
(http://archives.postgresql.org/message-id/4bd581a6.60...@enterprisedb.com),
I haven't read this in any detail, but why does it add inclusion of
pg_control.h to
Hi all,
On Tue, 2010-04-27 at 11:07 -0400, Merlin Moncure wrote:
The block level case seems pretty much covered by the hot standby feature.
One use case we would have is to dump only the changes from the last
backup of a single table. This table takes 30% of the DB disk space, it
is in the
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
If pg_stop_backup() is run it creates the .backup file in the archive.
In the absence of that file, we should be able to work out that
pg_stop_backup() was not run.
It's just as likely that the file is there
On Tue, Apr 27, 2010 at 11:13 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Merlin Moncure mmonc...@gmail.com wrote:
The proposal only seems a win to me if a fair percentage of the
larger files don't change, which strikes me as a relatively low
level case to optimize for.
That's
Merlin Moncure mmonc...@gmail.com wrote:
Your archiving requirements are high.
They are set by a Steering Committee composed of the Directory of
State Courts and various District Court Administrators, Judges,
Clerks of Court, and Registers in Probate who rely on this data and
*really* want to
Simon Riggs wrote:
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
If pg_stop_backup() is run it creates the .backup file in the archive.
In the absence of that file, we should be able to work out that
pg_stop_backup() was not run.
It's just as likely that
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Ok, here's a patch that includes the changes to add new wal_mode GUC
(http://archives.postgresql.org/message-id/4bd581a6.60...@enterprisedb.com),
I haven't read this in any detail, but why does it add inclusion of
Simon Riggs si...@2ndquadrant.com writes:
v3 attached
This patch changes KnownAssignedXidsRemove() so that failure to find
the target XID is elog(ERROR) (ie, a PANIC, since this is in the
startup process). However, this comment is still there:
/*
* We can fail to find an xid
On Tue, 2010-04-27 at 13:52 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
v3 attached
This patch changes KnownAssignedXidsRemove() so that failure to find
the target XID is elog(ERROR) (ie, a PANIC, since this is in the
startup process).
Not in all cases. The code is
On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
If pg_stop_backup() is run it creates the .backup file in the archive.
In the absence of that file, we should be able to work out
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
I haven't read this in any detail, but why does it add inclusion of
pg_control.h to xlog.h? I don't see any reason for that in the actual
changes in xlog.h.
I put the enum for wal_mode to pg_control.h, so that
On Tue, Apr 27, 2010 at 10:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-04-27 at 08:59 -0500, Kevin Grittner wrote:
An explicit mechanism where Postgres could authoritatively say
which files have changed would make many feel safer, especially
when other databases also do
Hmm ... there's another point here, which is that the array size creates
a hard maximum on the number of entries, whereas the hash table was a
bit more forgiving. What is the proof that the array won't overflow?
The fact that the equivalent data structure on the master can't hold
more than this
Tom Lane wrote:
How about putting the enum {} declaration in xlog.h, and making the
field in pg_control.h just be declared int?
I tried that at first, but the problem was with pg_controldata.c. In
bin/. I wanted it to print wal_mode in human-readable format, so it
needed the values of the enum
Simon Riggs wrote:
On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
If pg_stop_backup() is run it creates the .backup file in the archive.
In the absence of that file, we should be
Heikki Linnakangas escribió:
Tom Lane wrote:
How about putting the enum {} declaration in xlog.h, and making the
field in pg_control.h just be declared int?
I tried that at first, but the problem was with pg_controldata.c. In
bin/. I wanted it to print wal_mode in human-readable format,
On Tue, 2010-04-27 at 14:53 -0400, Tom Lane wrote:
Hmm ... there's another point here, which is that the array size
creates
a hard maximum on the number of entries, whereas the hash table was a
bit more forgiving. What is the proof that the array won't overflow?
The fact that the equivalent
Takahiro Itagaki wrote:
That's it! We should have added an additional alias to chklocale, too.
Index: src/port/chklocale.c
===
--- src/port/chklocale.c (HEAD)
+++ src/port/chklocale.c (fixed)
@@ -172,6 +172,7 @@
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-04-27 at 13:52 -0400, Tom Lane wrote:
WTF? Either the comment is wrong or this should not be an elog
condition.
That section of code has been rewritten many times. I think it is now
inaccurate and should be removed. I left it there
On Tue, 2010-04-27 at 16:18 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-04-27 at 13:52 -0400, Tom Lane wrote:
WTF? Either the comment is wrong or this should not be an elog
condition.
That section of code has been rewritten many times. I think it is
Isn't the snapshotOldestActiveXid filter in
RecordKnownAssignedTransactionIds completely wrong/useless/bogus?
AFAICS, snapshotOldestActiveXid is only set once at the start of
recovery. This means it will soon be too old to provide any useful
filtering. But what's far worse is that the XID space
On Tue, 2010-04-27 at 17:24 -0400, Tom Lane wrote:
Isn't the snapshotOldestActiveXid filter in
RecordKnownAssignedTransactionIds completely wrong/useless/bogus?
AFAICS, snapshotOldestActiveXid is only set once at the start of
recovery. This means it will soon be too old to provide any
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-04-27 at 17:24 -0400, Tom Lane wrote:
I think we should just lose that test, as well as the variable.
Yes, though it looks like it is still necessary in creating a valid
initial state because otherwise we may have xids in KnownAssigned
Hackers,
It appears that something broke the ability to refer to columns by full
SQL path names in 9.0. That is, references to columns as
schema.table.col will produce a completely bogus error which did not
exist on previous versions.
The following works perfectly well in 8.4:
postgres=#
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, AFAICS the problem with controldata is that it uses postgres_fe.h
instead of postgres.h. It's a bit of a stretch to use the latter, but
maybe that's a better solution? After all, it *is* poking into the
backend internals.
I seem to
Hello,
I've been reading the earlier threads at:
http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
and I'm not sure I have anything that substantially new to add but:
1. I can't see there's an unambiguity
On Tue, 2010-04-27 at 18:08 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-04-27 at 17:24 -0400, Tom Lane wrote:
I think we should just lose that test, as well as the variable.
Yes, though it looks like it is still necessary in creating a valid
initial
Tom Lane escribió:
Alvaro Herrera alvhe...@commandprompt.com writes:
Hmm, AFAICS the problem with controldata is that it uses postgres_fe.h
instead of postgres.h. It's a bit of a stretch to use the latter, but
maybe that's a better solution? After all, it *is* poking into the
backend
Hi,
I just noticed that the road.thepath column in the regression database
is no longer in pg_stats for some reason after ANALYZE, so the example
in section 14.2 in the docs (Statistics Used by the Planner) is now
wrong.
What I'm trying to do is replace that exceedingly wide output with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 25/04/2010 03:02, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Apr 24, 2010 at 8:07 PM, Bruce Momjian br...@momjian.us wrote:
Sounds useful to me, though as a function like suggested in a later
email.
If tool-builders
On Tue, Apr 27, 2010 at 6:45 PM, Kjell Rune Skaaraas kjell...@yahoo.no wrote:
Hello,
I've been reading the earlier threads at:
http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
and I'm not sure I have
On Tue, Apr 27, 2010 at 7:45 PM, Jehan-Guillaume (ioguix) de Rorthais
iog...@free.fr wrote:
I thought Michael was trying to write a tokenizer based on node tree
returned by raw_parser. As it seems Michael is not even sure about what
he's trying to do, I prefer refocus a bit this thread
[...]
Alvaro Herrera alvhe...@commandprompt.com writes:
I just noticed that the road.thepath column in the regression database
is no longer in pg_stats for some reason after ANALYZE, so the example
in section 14.2 in the docs (Statistics Used by the Planner) is now
wrong.
It's an old example :-(
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-04-27 at 18:08 -0400, Tom Lane wrote:
Huh? How is a filter as coarse as an oldest-running-XID filter going
to prevent that? And aren't we initializing from trustworthy data in
ProcArrayApplyRecoveryInfo, anyway?
I still say it's
Josh Berkus j...@agliodbs.com writes:
It appears that something broke the ability to refer to columns by full
SQL path names in 9.0. That is, references to columns as
schema.table.col will produce a completely bogus error which did not
exist on previous versions.
My fault :-(. Seems we have
On Sun, Apr 25, 2010 at 9:07 PM, Robert Haas robertmh...@gmail.com wrote:
4. We could add an additional 32-bit value to RelFileNode to identify
the backend (or a sentinel value when not temp) and create a separate
structure XLogRelFileNode or PermRelFileNode or somesuch for use in
contexts
The functions ShmemInitStruct and ShmemInitHash will return NULL on
certain failure conditions, apparently on the grounds that their caller
can print a more useful error message than they can. A quick survey
shows that about half the callers aren't remembering to check for NULL,
and none of the
On Wed, Apr 28, 2010 at 4:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
On Tue, 2010-04-27 at 20:14 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2010-04-27 at 18:13 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
If
Simon Riggs wrote:
Is this route worthwhile? Or in some way unacceptable?
From an admin perspective, I think block-level differentials would be a
lot more useful, especially if index storage could be safely excluded.
IMO Pg really could use an index bad or missing, rebuild on postmaster
start
Kjell Rune Skaaraas kjell...@yahoo.no wrote:
I've been reading the earlier threads at:
http://archives.postgresql.org/pgsql-hackers/2009-05/thrd7.php#00252
http://archives.postgresql.org/pgsql-hackers/2005-10/thrd4.php#00632
and I'm not sure I have anything that substantially new to add but:
78 matches
Mail list logo
