easily and quickly. Please do so.
That's a plural form. What's the other thing you're referring to?
Not because I say so, but because everybody else will soon notice that
you could have and did not.
Bollocks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via
Dimitri Fontaine wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Well, it would still be useful, as it would shorten the delay. But yeah,
there's a delay in asynchronous replication anyway, so we decided to
keep it simple and just poll. It's not ideal and definitely needs
Simon Riggs wrote:
On Tue, 2010-04-06 at 12:38 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I was also surprised to note
Robert Haas wrote:
On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Add the GUC parameter to specify the maximum number of log file
segments held in pg_xlog directory to send to the standby server. Which is
useful to avoid disk full
is a bit confusing for pg_xlogfile_name(). pg_xlogfile_name()
is hardly a WAL control function like pg_start/stop_backup() are. How
about pg_xlogfile_name() cannot be executed during recovery.?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing
in recovery.conf.sample as mentioned above.
I committed the LOG-STREAMING REPLICATION PARAMETERS - STANDBY
SERVER PARAMETERS rename. Simon added the RECOVERY TARGET PARAMETERS
heading already, and he wants to keep the Hot Standby section.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Simon Riggs wrote:
On Tue, 2010-04-06 at 16:07 +0900, Fujii Masao wrote:
On Tue, Apr 6, 2010 at 3:47 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
To follow up on the discussion here:
http://archives.postgresql.org/pgsql-docs/2010-02/msg00039.php
It seems like a big
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
I triaged the list of open items on the Streaming Replication wiki page.
I propose that we drop the ones I've marked as Drop below, and move the
remaining items to the main Open Items page for better visibility
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 11:48 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 8:02 PM, Fujii Masao masao.fu...@gmail.com wrote:
Should we throw an error in pg_xlogfile_name() if called during
recovery? It's
for the review! And, sorry for the delay.
On Thu, Jan 21, 2010 at 11:10 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I don't think we should do the check XLogWrite(). There's really no
reason to kill the standby connections before the next checkpoint, when
the old WAL files
(moving to pgsql-hackers)
Simon Riggs wrote:
On Wed, 2010-04-07 at 06:12 +, Heikki Linnakangas wrote:
Log Message:
---
Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset() during
recovery. We might want to relax this in the future, but ThisTimeLineID
isn't currently
Fujii Masao wrote:
On Wed, Apr 7, 2010 at 1:48 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, here's what I came up with.
Looks OK to me.
Committed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql
Fujii Masao wrote:
On Wed, Apr 7, 2010 at 7:23 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This commit is a stop-gap solution until we figure out what exactly to
do about that. Masao-san wrote a patch that included the TLI in the
string returned by pg_last_xlog_receive
the first checkpoint record.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
explicitly doesn't use pgpipe() on Windows,
though, but calls CreatePipe(). I don't see any explanation why.
I'm going to see what happens if I remove all the #ifdef WIN32 blocks in
syslogger, and let it use pgpipe() and select() instead of the extra thread.
Thoughts?
--
Heikki Linnakangas
record, not
delaying it until we've read the first record after it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
*** a/src/backend/access/transam/twophase.c
--- b/src/backend/access/transam/twophase.c
***
*** 1719,1724 PrescanPreparedTransactions
Simon Riggs wrote:
OK, that seems better. I'm happy with that instead.
Have you tested this? Is it ready to commit?
Only very briefly. I think the code is ready, but please review and test
to see I didn't miss anything.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
I'm going to see what happens if I remove all the #ifdef WIN32 blocks in
syslogger, and let it use pgpipe() and select() instead of the extra
thread.
Sounds reasonable. Let's see how big the changes are on HEAD. I'm not
sure it's worth
the view up-to-date
automatically, it becomes much more useful.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
2010/4/10 Andrew Dunstan and...@dunslane.net:
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can be further divided into many steps, you can begin by supporting
automatic updates only on very simple views with e.g
Robert Haas wrote:
On Sun, Apr 11, 2010 at 10:26 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
2010/4/10 Andrew Dunstan and...@dunslane.net:
Heikki Linnakangas wrote:
1. Keep the materialized view up-to-date when the base tables change.
This can
to after calling
XLogArchiveCheckDone()
in RemoveOldXlogFiles()?
Good point. It's particularly important considering that if a segment
hasn't been archived yet, it's not available to the standby from the
archive either. I changed that.
--
Heikki Linnakangas
EnterpriseDB http
the primary. Connecting to the primary and issuing a manual
CHECKPOINT helps.
That's not the order of shutdowns you described, though...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
() - hash_seq_search(). That explains the
difference in performance.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs wrote:
On Thu, 2010-04-08 at 19:02 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
OK, that seems better. I'm happy with that instead.
Have you tested this? Is it ready to commit?
Only very briefly. I think the code is ready, but please review and test
to see I didn't miss
Robert Haas wrote:
On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
* If standby_mode is enabled, and neither primary_conninfo nor
restore_command are set, the standby would get stuck.
It's not really stuck, it will replay
Robert Haas wrote:
On Mon, Apr 12, 2010 at 6:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Why is standby_keep_segments used even if max_wal_senders is zero?
In that case, ISTM we don't need to keep any WAL files in pg_xlog
for the standby.
True. I don't think we
.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas wrote:
I could reproduce this on my laptop, standby is about 20% slower. I ran
oprofile, and what stands out as the difference between the master and
standby is that on standby about 20% of the CPU time is spent in
hash_seq_search(). The callpath is GetSnapshotDat
the same result with bulk insert or update.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, hence the requested WAL segment
00010032 has already been removed error. It shouldn't
remove the segment before it's successfully archived, though, and your
logs show that the standby can't find that file in the archive either.
Is archiving set up properly?
--
Heikki Linnakangas
: connection not authorized for host [local], user foo,
database postgres
HINT: Make sure that you have a matching accept line in pg_hba.conf
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
greps to find all the references.
Well, it's consistent with checkpoint_segments/CheckPointSegments. There
is no consistent style on naming the global variables behind GUCs. If
you feel like changing it though, I won't object.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Erik Rijkers wrote:
Btw, typo alert: documentation 18.5.4, subhead 'standby_keep_segments',
says: 'replciation' for 'replication'.
http://developer.postgresql.org/pgdocs/postgres/runtime-config-wal.html#RUNTIME-CONFIG-REPLICATION
Thanks, fixed.
--
Heikki Linnakangas
EnterpriseDB
Simon Riggs wrote:
On Tue, 2010-04-13 at 21:09 +0300, Heikki Linnakangas wrote:
A quick fix would be to check if there's any entries in the hash table
before scanning it. That would eliminate the overhead when there's no
in-progress transactions in the master. But as soon as there's even one
to live with the issue since it's
a very corner case.
Yeah, we can live with that. The user is not generally interested in
what exactly is wrong with the record. It just indicates that it has the
end of valid WAL in the standby.
Applied.
--
Heikki Linnakangas
EnterpriseDB http
Robert Haas wrote:
On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
We have the emode_for_corrupt_record() function that's used in all the
errors that indicate a corrupt WAL record, that's a perfect place to
hook this into. See attached patch
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
I'm going to see what happens if I remove all the #ifdef WIN32 blocks in
syslogger, and let it use pgpipe() and select() instead of the extra
thread.
Sounds reasonable. Let's see how big the changes are on HEAD. I'm
Simon Riggs wrote:
On Fri, 2010-04-16 at 11:29 +0300, Heikki Linnakangas wrote:
How does the attached patch look like? It's probably similar to what you
had in mind.
It looks like a second version of what I'm working on and about to
publish. I'll take that as a compliment!
My patch
Simon Riggs wrote:
On Mon, 2010-04-19 at 10:36 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
Log Message:
---
Tune GetSnapshotData() during Hot Standby by avoiding loop
through normal backends. Makes code clearer also, since we
avoid various Assert()s. Performance of snapshots
takenDuringRecovery is true even though the snapshot was taken
just after recovery finished. AFAICS all of the other current uses of
takenDuringRecovery work fine with that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
be fiddling with this at this stage in the
release cycle.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
, and in shared mode when
reading it.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(TransactionIdFollows(new, tail)).
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
this, is to send the client an redirect
message. When client connect to 127.0.0.10, instead of accepting the
connection, it can reply to client telling it to reconnect to one of the
server on 127.0.0.11-14.
One common way to do that is to set up one DNS entry for those 4 IP
addresses.
--
Heikki
Robert Haas wrote:
On Wed, Apr 21, 2010 at 9:37 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-21 at 15:27 +0300, Heikki Linnakangas wrote:
Given the discussion about the cyclic nature of XIDs, it would be good
to add an assertion that when a new XID is added to the array
seen them anyway, so ISTM that we should treat
InvalidTransactionId return value as we don't need to kill anyone.
Why does btree_xlog_delete_get_latestRemovedXid() keep the
num_unused/num_dead/num_redirect counts, it doesn't actually do anything
with them.
--
Heikki Linnakangas
EnterpriseDB
CET 15763 start=2010-03-13 23:54:59 CET LOG:
terminating any other active
server processes
Maybe I'll try now to setup a similar instance without postbio, to see if the
crash still occurs.
hth,
Erik Rijkers
--
Heikki Linnakangas
EnterpriseDB http
Simon Riggs wrote:
On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote:
btree_redo:
/*
* Note that if all heap tuples were LP_DEAD then we will be
* returning InvalidTransactionId here. This seems very unlikely
* in practice.
*/
If none of the removed heap
Simon Riggs wrote:
On Thu, 2010-04-22 at 11:28 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-04-22 at 10:24 +0300, Heikki Linnakangas wrote:
btree_redo:
/*
* Note that if all heap tuples were LP_DEAD then we will be
* returning InvalidTransactionId here
Simon Riggs wrote:
On Thu, 2010-04-22 at 11:56 +0300, Heikki Linnakangas wrote:
If none of the removed heap tuples were present anymore, we currently
return InvalidTransactionId, which kills/waits out all read-only
queries. But if none of the tuples were present anymore, the read-only
would just set wal_mode='archive' or
wal_mode='standby' instead, depending on what you want to do with the WAL.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Robert Haas wrote:
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I quite liked Robert's proposal to add an explicit GUC to control what
extra information is logged
(http://archives.postgresql.org/pgsql-hackers/2010-04/msg00509.php
Robert Haas wrote:
On Fri, Apr 23, 2010 at 7:12 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
On Fri, Apr 23, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I quite liked Robert's proposal to add an explicit GUC
argument for having it do what you propose.
It's worth noting that RAISE without parameters was added to mimic the
corresponding RAISE command on Oracle, and on Oracle Piyush's test case
works as he says.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql
it.
The recovery_connections GUC does that. If you enable it, the extra
information required for hot standby is written to the WAL, otherwise
it's not.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
. It is ignored on the master, to
allow the same configuration file to be used on master and standby.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
when run against a standby server? They all have to set up a bunch of
objects before they run queries, so you just get a lot of errors
complaining that you can't do X in standby mode, followed by errors
about missing objects. That doesn't sound very useful.
--
Heikki Linnakangas
EnterpriseDB
that are somehow mutually
exclusive.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index eb5765a..6c6a504 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -689,8 +689,7 @@ archive_command = 'test ! -f
project manager hat
I notice that Heikki's patch doesn't include doing the above. Should
we? If so, who's going to do it?
I'll give it a shot.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
for will never arrive.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
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
wal_mode is expected to be WAL_MODE_ARCHIVE in that case.
No, it doesn't prevent archive recovery. It only prevents hot standby if
wal_mode was not 'hot_standby' in the master. I think you missed the
XLogRequestRecoveryConnections condition above.
--
Heikki Linnakangas
EnterpriseDB http
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),
errhint
difference between the two,
because PG_EUC_KR is supported as a server-encoding while PG_UHC is not.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
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
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
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
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
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
from somewhere. I tried to #include
access/xlog.h in pg_controlinfo.c, but got a bunch of errors.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
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
corresponding codepages for them, right?
{PG_LATIN6, ISO-8859-10},
{PG_LATIN7, ISO-8859-13},
{PG_LATIN8, ISO-8859-14},
{PG_LATIN10, ISO-8859-16},
{PG_SHIFT_JIS_2004, SJIS_2004},
Yeah, I guess so. I can't find Windows codepages for these either, by
google.
--
Heikki Linnakangas
? The
patch replaces the unlogged-operation WAL record with a record
containing current parameter values, and it changes pg_control. I'm
guessing both.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index eb5765a
-assigned-xids
hash - sorted-array patch.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs wrote:
On Wed, 2010-04-28 at 10:43 +0300, Heikki Linnakangas wrote:
* renamed wal_mode to wal_level
I'm wondering whether this should be a list rather than an enum? If we
add something in the future that adds more info to WAL but doesn't fit
the one-dimensional model
Fujii Masao wrote:
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, did that. Here's an updated patch:
+During recovery, specifies whether or not you can connect and run
+queries to enable xref linkend=hot-standby
Robert Haas wrote:
On Wed, Apr 28, 2010 at 6:52 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-28 at 19:40 +0900, Fujii Masao wrote:
On Wed, Apr 28, 2010 at 4:43 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This doesn't contain any changes to pg_start_backup
released version, so we could still change it back to the original
scheme (0xD063).
0x9002 sounds like it means the 9.0 release, which might be a good
versioning scheme as well. If want to continue with that scheme, it
should be documented in the comments.
--
Heikki Linnakangas
EnterpriseDB
. pg_stop_backup().
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
with the existing CREATE OR REPLACE commands.
And can be extended in the future to alter the existing object instead
of throwing an error.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
.
Actually, that's a good idea. But how will you handle tables?
What do you mean?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by
one whenever the format changes, at least as long as it has been been in
xlog_internal.h. It started at 0xD05B in 2005, and was incremented
Ok, I've finally committed the patch, using wal_level as the name of the
GUC.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
to filesystems.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Well, it would be nice to allow using pg_start_backup() on the primary
when streaming replication is enabled, even if archiving isn't.
Otherwise the only way to get the base backup for the standby is to shut
down
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Well, it would be nice to allow using pg_start_backup() on the primary
when streaming replication is enabled, even if archiving isn't.
Otherwise the only way to get the base backup
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Tom Lane wrote:
If you aren't archiving then there's no guarantee that you'll still have
a continuous WAL series starting from the start of the backup.
I wasn't really thinking of this use case, but you could set
Robert Haas wrote:
On Wed, Apr 28, 2010 at 12:07 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
On Wed, Apr 28, 2010 at 11:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't believe you are fairly stating
the standby,
complaining that it can't find the WAL segment it needs in the primary
anymore. Not silent corruption.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Fujii Masao wrote:
On Thu, Apr 29, 2010 at 1:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, I've finally committed the patch, using wal_level as the name of the
GUC.
!if (InArchiveRecovery XLogRequestRecoveryConnections)
!{
!if (ControlFile
:
NOTICE: pg_stop_backup complete, all required WAL segments have been
archived
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
*** a/src/backend/access/transam/xlog.c
--- b/src/backend/access/transam/xlog.c
***
*** 8200,8217 pg_start_backup(PG_FUNCTION_ARGS
Simon Riggs wrote:
On Thu, 2010-04-29 at 10:55 +0300, Heikki Linnakangas wrote:
Should we change the default to recovery_connections=off ? It is a quite
big change in default behavior over previous releases that hot standby
is enabled by default, so maybe that would be the right thing to do
. When you just want
hot standby to be on or off, it's weird to control that from the master.
Action at a distance.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
a reporting server, and hot standby can't start,
the server is not functioning properly. I would like to get an error in
that case.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Simon Riggs wrote:
On Thu, 2010-04-29 at 13:46 +0300, Heikki Linnakangas wrote:
warm standby for high availability - no
offloading taking filesystem-level backups from master - no
These can be explicitly turned off.
You're presuming there is benefit in turning recovery_connections = off
'on'
by default, and that has been useful to get more testing during the
development cycle, but it's not clear that's a good default for
real-life usage.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Robert Haas wrote:
On Thu, Apr 29, 2010 at 7:19 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Robert Haas wrote:
I kind of agree with Simon on this one, except I would probably choose
to have just on and off and make on work like his auto.
In other words
that the standby was configured with recovery_connections='on', and
failed to start for those six months because hot standby could not be
enabled, and no-one noticed?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
901 - 1000 of 6533 matches
Mail list logo
