Alvaro Herrera wrote:
> Not sure what is going on; my reading of the code certainly says that
> the data should be there. I'm looking into it.
>
> I also noticed that I didn't actually push the whole of the patch
> yesterday -- I neglected to "git add" the latest changes, the ones that
> fix the
On Wed, Dec 9, 2015 at 4:21 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
>
>> > So firstly you will push those "latest" changes soon?
>>
>> It seems like these changes haven't been pushed yet, and unfortunately
>> that's probably a beta bloc
Robert Haas wrote:
> On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
> > So firstly you will push those "latest" changes soon?
>
> It seems like these changes haven't been pushed yet, and unfortunately
> that's probably a beta blocker.
I'm on this.
--
Álvaro Herrerahttp://w
On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao wrote:
> On Sat, Dec 5, 2015 at 12:56 AM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>
>>> Sorry for not reviewing the patch before you push it...
>>>
>>> In HEAD, I ran very simple test case:
>>>
>>> 1. enable track_commit_timestamp
>>> 2. start th
On Sat, Dec 5, 2015 at 12:56 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> Sorry for not reviewing the patch before you push it...
>>
>> In HEAD, I ran very simple test case:
>>
>> 1. enable track_commit_timestamp
>> 2. start the server
>> 3. run some transactions
>> 4. execute pg_last_commi
Fujii Masao wrote:
> Sorry for not reviewing the patch before you push it...
>
> In HEAD, I ran very simple test case:
>
> 1. enable track_commit_timestamp
> 2. start the server
> 3. run some transactions
> 4. execute pg_last_committed_xact() -- returns non-null values
> 5. shutdown the server w
On Tue, Nov 17, 2015 at 6:43 AM, Alvaro Herrera
wrote:
> I paraphrase Fujii Masao, who wrote:
>
>> 1. Start the master and standby servers with track_commit_timestamp enabled.
>> 2. Disable track_commit_timestamp in the master and restart the master
>> server.
>> 3. Run checkpoint in the master.
Petr Jelinek wrote:
> While this seems good, I'd code it slightly differently. I didn't like the
> addition of new bool when it's not really needed. This brings the question
> if we actually need the BootStrapCommitTs and StartupCommitTs functions
> which really don't do much though.
Thanks, it's
On 2015-11-16 22:43, Alvaro Herrera wrote:
I paraphrase Fujii Masao, who wrote:
1. Start the master and standby servers with track_commit_timestamp enabled.
2. Disable track_commit_timestamp in the master and restart the master server.
3. Run checkpoint in the master.
4. Run restartpoint in the
I paraphrase Fujii Masao, who wrote:
> 1. Start the master and standby servers with track_commit_timestamp enabled.
> 2. Disable track_commit_timestamp in the master and restart the master server.
> 3. Run checkpoint in the master.
> 4. Run restartpoint in the standby after the checkpoint WAL reco
On Thu, Oct 29, 2015 at 5:41 PM, Fujii Masao wrote:
> I found another strange behavior on track_commit_timestamp.
> Here are the steps to reproduce it.
>
> 1. Start the master and standby servers with track_commit_timestamp enabled.
> Since committs is activated in standby, pg_last_committed_x
On Wed, Oct 28, 2015 at 3:07 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>> Robert Haas wrote:
>> > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
>> > > I agree with that sentiment.
>> > >
>> > > Attached patch adds variable to the shmem which is used for module
>> > > activation tra
Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> > > I agree with that sentiment.
> > >
> > > Attached patch adds variable to the shmem which is used for module
> > > activation tracking - set to true in ActiveCommitTs() and false in
> > > Deact
Robert Haas wrote:
> On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> > I agree with that sentiment.
> >
> > Attached patch adds variable to the shmem which is used for module
> > activation tracking - set to true in ActiveCommitTs() and false in
> > DeactivateCommitTs(). All the checks insi
On Sat, Oct 17, 2015 at 5:37 PM, Petr Jelinek wrote:
> I agree with that sentiment.
>
> Attached patch adds variable to the shmem which is used for module
> activation tracking - set to true in ActiveCommitTs() and false in
> DeactivateCommitTs(). All the checks inside the commit_ts code were chan
On 2015-10-02 22:02, Robert Haas wrote:
On Fri, Oct 2, 2015 at 2:59 PM, Alvaro Herrera wrote:
Robert Haas wrote:
The standby can have the feature enabled even though the master has it
disabled? That seems like it can only lead to heartache.
Can you elaborate?
Sort of. Our rule up until n
On Fri, Oct 2, 2015 at 11:58 PM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> What happens if pg_xact_commit_timestamp() is called in standby after
>> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
>> called and all commit_ts files are removed in standby? I tried that cas
On Fri, Oct 2, 2015 at 2:59 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> The standby can have the feature enabled even though the master has it
>> disabled? That seems like it can only lead to heartache.
>
> Can you elaborate?
Sort of. Our rule up until now has always been that the standby
Robert Haas wrote:
> The standby can have the feature enabled even though the master has it
> disabled? That seems like it can only lead to heartache.
Can you elaborate?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Se
On Fri, Oct 2, 2015 at 10:58 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>
>> What happens if pg_xact_commit_timestamp() is called in standby after
>> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
>> called and all commit_ts files are removed in standby? I tried that cas
Fujii Masao wrote:
> What happens if pg_xact_commit_timestamp() is called in standby after
> track_commit_timestamp is disabled in master, DeactivateCommitTs() is
> called and all commit_ts files are removed in standby? I tried that case
> and got the following assertion failure.
Ah. So the stan
On Fri, Oct 2, 2015 at 3:12 AM, Alvaro Herrera wrote:
> Fujii Masao wrote:
>
>> I've not read the patch yet, but the patched server with
>> track_commit_timestamp
>> enabled caused the following PANIC error when I ran pgbench.
>
> Ah, that was a stupid typo: I used || instead of &&. Fixed that.
Fujii Masao wrote:
> I've not read the patch yet, but the patched server with
> track_commit_timestamp
> enabled caused the following PANIC error when I ran pgbench.
Ah, that was a stupid typo: I used || instead of &&. Fixed that.
I also changed DeactivateCommitTs() so that it removes all slru
On Thu, Oct 1, 2015 at 7:48 AM, Alvaro Herrera wrote:
> oonish...@nttdata.co.jp wrote:
>
>> The below error messages were shown in standby server log:
>>
>> FATAL: could not access status of transaction 9009
>> DETAIL: Could not read from file "pg_commit_ts/" at offset 90112:
>> Success.
>>
> Here's a patch.
Thank you!
With this patch, the standby server down disappears in my environment.
Regards,
Takashi Ohnishi
oonish...@nttdata.co.jp
-Original Message-
From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
Sent: Thursday, October 01, 2015 7:48 AM
To: Fujii Mas
oonish...@nttdata.co.jp wrote:
> The below error messages were shown in standby server log:
>
> FATAL: could not access status of transaction 9009
> DETAIL: Could not read from file "pg_commit_ts/" at offset 90112:
> Success.
> CONTEXT: xlog redo Transaction/COMMIT: 2015-09-30 15:52:41.92
On 2015-09-03 15:03, Fujii Masao wrote:
On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas wrote:
There's no existing precedent for a feature that lets the standby be
different from the master *in any way*. So I don't see why we should
start here. I think the reasonable definition is that the GUC
c
On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas wrote:
> On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera
> wrote:
>>> I think it's totally reasonable for the standby to follow the master's
>>> behavior rather than the config file. That should be documented, but
>>> otherwise, no problem. If it wer
On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera wrote:
>> I think it's totally reasonable for the standby to follow the master's
>> behavior rather than the config file. That should be documented, but
>> otherwise, no problem. If it were technologically possible for the
>> standby to follow the c
On 2015-08-05 00:13, Alvaro Herrera wrote:
Robert Haas wrote:
On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
wrote:
The alternative is to turn the feature on automatically if it sees that
the master also has it on, i.e. the value would not be what the config
file says it is. Doing this wou
Adding CC to hackers, since this is clearly not just a docs issue. Also
CCing Petr and Craig since they are the ones that know how this is used
in BDR.
Robert Haas wrote:
> On Tue, Aug 4, 2015 at 12:41 AM, Alvaro Herrera
> wrote:
> > The alternative is to turn the feature on automatically if it
31 matches
Mail list logo
