Robert Haas wrote:
> On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas
> 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.
>
> The test for elog == LOG
Fujii Masao wrote:
> One problem of the patch is that even if the content of error message
> is different from the past, it would be skipped when the location of
> invalid record is the same of the past. For example, if there is a
> partially-filled unbroken WAL file in the standby, the following
>
On Wed, Apr 14, 2010 at 12:49 AM, Heikki Linnakangas
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.
One problem of the patch is that even if the content of
On Tue, Apr 13, 2010 at 11:49 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
>> wrote:
>>> Robert Haas wrote:
>> * If standby_mode is enabled, and neither primary_conninfo nor
>> restore_command are set, the standby would get
Robert Haas wrote:
> On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
> 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 any WAL files you
On Thu, Apr 8, 2010 at 11:00 PM, Robert Haas wrote:
> I think you could shut it down at the first point at which it is
> holding no locks, rather than letting it continue recovering and
> potentially retake some new locks. That would be more consistent with
> the general idea of what a smart shut
On Thu, Apr 8, 2010 at 9:56 AM, Simon Riggs wrote:
> On Thu, 2010-04-08 at 09:40 -0400, Robert Haas wrote:
>> On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs wrote:
>> > On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
>> >
>> >> > I do. I see no reason to do the latter, ever, so should not be a
On Thu, 2010-04-08 at 09:40 -0400, Robert Haas wrote:
> On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs wrote:
> > On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
> >
> >> > I do. I see no reason to do the latter, ever, so should not be added to
> >> > any TODO.
> >>
> >> Well, stopping recovery
On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs wrote:
> On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
>
>> > I do. I see no reason to do the latter, ever, so should not be added to
>> > any TODO.
>>
>> Well, stopping recovery earlier would mean fewer locks, which would
>> mean a better chance
On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote:
> > I do. I see no reason to do the latter, ever, so should not be added to
> > any TODO.
>
> Well, stopping recovery earlier would mean fewer locks, which would
> mean a better chance for the read-only backends to finish their work
> and exit
On Thu, Apr 8, 2010 at 7:37 AM, Simon Riggs wrote:
> On Thu, 2010-04-08 at 06:58 -0400, Robert Haas wrote:
>
>> >> Thanks. Committed.
>> >
>> > Thanks. The following TODO item should be removed?
>> >
>> > "Redefine smart shutdown in standby mode to exist as soon as all
>> > read-only connections
On Thu, 2010-04-08 at 06:58 -0400, Robert Haas wrote:
> >> Thanks. Committed.
> >
> > Thanks. The following TODO item should be removed?
> >
> > "Redefine smart shutdown in standby mode to exist as soon as all
> > read-only connections are gone."
> > http://wiki.postgresql.org/wiki/Todo#Standby_s
On Thu, Apr 8, 2010 at 2:54 AM, Fujii Masao wrote:
> On Thu, Apr 8, 2010 at 10:41 AM, Robert Haas wrote:
>> On Wed, Apr 7, 2010 at 8:17 AM, Simon Riggs wrote:
>>> OK, that looks a lot less risky than I had understood from discussions.
>>> The main thing for me is it doesn't interfere with Startu
On Thu, Apr 8, 2010 at 10:41 AM, Robert Haas wrote:
> On Wed, Apr 7, 2010 at 8:17 AM, Simon Riggs wrote:
>> OK, that looks a lot less risky than I had understood from discussions.
>> The main thing for me is it doesn't interfere with Startup or
>> WalReceiver, so assuming it works I've got no obj
On Tue, Apr 6, 2010 at 4:09 PM, Simon Riggs wrote:
> On Tue, 2010-04-06 at 10:09 +0300, Heikki Linnakangas wrote:
>
>> > * Walsender and dblink are not interruptible on win32. - related
>> > thread
>>
>> I'd actually be happy to just leave it for 9.0, but it seems like
>> consensus has been
On Wed, Apr 7, 2010 at 8:17 AM, Simon Riggs wrote:
> OK, that looks a lot less risky than I had understood from discussions.
> The main thing for me is it doesn't interfere with Startup or
> WalReceiver, so assuming it works I've got no objections. Thanks for
> chasing this down, good addition.
T
On Wed, 2010-04-07 at 07:40 -0400, Robert Haas wrote:
> On Tue, Apr 6, 2010 at 3:14 PM, Simon Riggs wrote:
> > On Tue, 2010-04-06 at 11:06 -0400, Robert Haas wrote:
> >
> >> * Redefine smart shutdown in standby mode?
> >> >>> Drop. Too big a change at this point.
> >> >>
> >> >> We have a
On Tue, Apr 6, 2010 at 3:14 PM, Simon Riggs wrote:
> On Tue, 2010-04-06 at 11:06 -0400, Robert Haas wrote:
>
>> * Redefine smart shutdown in standby mode?
>> >>> Drop. Too big a change at this point.
>> >>
>> >> We have a working patch for this - I want to commit it. I don't think
>> >>
On Tue, 2010-04-06 at 10:09 +0300, Heikki Linnakangas wrote:
> > * Walsender and dblink are not interruptible on win32. - related thread
>
> I'd actually be happy to just leave it for 9.0, but it seems like
> consensus has been reached on how to fix it, and Fujii is working on a
> patch, so
On Tue, 2010-04-06 at 11:06 -0400, Robert Haas wrote:
> * Redefine smart shutdown in standby mode?
> >>> Drop. Too big a change at this point.
> >>
> >> We have a working patch for this - I want to commit it. I don't think
> >> it's a big change, and the current behavior is extremely pat
On Tue, 2010-04-06 at 20:27 +0200, Erik Rijkers wrote:
> Was the issue eventually found/solved?
We think so, but the event was not conclusively traceable.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
On Tue, April 6, 2010 19:29, Heikki Linnakangas wrote:
[...]
>
> I've added the ones that should be addressed in the future to the TODO
> list. I added a new subsection for standby server and streaming
> replication related items:
> http://wiki.postgresql.org/wiki/Todo#Standby_server_mode
>
I repo
Tom Lane wrote:
> Heikki Linnakangas 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.
>
> By "drop" do you mean "move
Fujii Masao writes:
> On Tue, Apr 6, 2010 at 4:09 PM, Heikki Linnakangas
> wrote:
>>> * Fix things so that any such variables inherited from the server
>>> environment are intentionally *NOT* used for making SR connections.
>>
>> Drop. Besides, we have the same problem with dblink, and I do
Heikki Linnakangas 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.
By "drop" do you mean "move to TODO"? At least some
On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
>> 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
Robert Haas wrote:
> On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
> 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 in the primary.
>> Not only to a
I wrote my previous email before reading this.
On Tue, Apr 6, 2010 at 3:09 AM, Heikki Linnakangas
wrote:
> 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 pa
On Tue, Apr 6, 2010 at 4:09 PM, Heikki Linnakangas
wrote:
> 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. And
> of course try to
29 matches
Mail list logo