On Wed, Aug 13, 2014 at 12:41:24PM +0900, Fujii Masao wrote:
> On Mon, Aug 11, 2014 at 8:27 PM, Fujii Masao wrote:
> > On Mon, Aug 11, 2014 at 4:46 PM, Andres Freund
> > wrote:
> >> Hi,
> >>
> >> On 2011-10-04 20:52:59 +0900, Fujii Masao wrote:
> >>> *** a/src/backend/access/transam/xact.c
> >>>
On Mon, Aug 11, 2014 at 8:27 PM, Fujii Masao wrote:
> On Mon, Aug 11, 2014 at 4:46 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2011-10-04 20:52:59 +0900, Fujii Masao wrote:
>>> *** a/src/backend/access/transam/xact.c
>>> --- b/src/backend/access/transam/xact.c
>>> ***
>>> *** 1066,1071 *
On Mon, Aug 11, 2014 at 4:46 PM, Andres Freund wrote:
> Hi,
>
> On 2011-10-04 20:52:59 +0900, Fujii Masao wrote:
>> *** a/src/backend/access/transam/xact.c
>> --- b/src/backend/access/transam/xact.c
>> ***
>> *** 1066,1071 RecordTransactionCommit(void)
>> --- 1066,1074
>>
>>
Hi,
On 2011-10-04 20:52:59 +0900, Fujii Masao wrote:
> *** a/src/backend/access/transam/xact.c
> --- b/src/backend/access/transam/xact.c
> ***
> *** 1066,1071 RecordTransactionCommit(void)
> --- 1066,1074
>
> (void) XLogInsert(RM_XACT_ID, XLOG_XACT_CO
On Mon, Dec 12, 2011 at 12:17 PM, Simon Riggs wrote:
> On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith wrote:
>
>> "We can send regular special messages from WALSender to WALReceiver that do
>> not form part of the WAL stream, so we don't bulk
>> up WAL archives. (i.e. don't use "w" messages)."
>>
>
On 12/12/2011 08:45 AM, Robert Haas wrote:
But I'm skeptical that anything that we only update once per
checkpoint cycle will help much in
calculating an accurate lag value.
I'm sure there is no upper bound on how much WAL lag you can build up
between commit/abort records either; they can be
On Mon, Dec 12, 2011 at 9:51 AM, Simon Riggs wrote:
> On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas wrote:
>> On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs wrote:
>>> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
It also strikes me that anything
that is based on augmenting the wal
On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas wrote:
> On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs wrote:
>> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
>>> It also strikes me that anything
>>> that is based on augmenting the walsender/walreceiver protocol leaves
>>> anyone who is using
On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs wrote:
> On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
>> It also strikes me that anything
>> that is based on augmenting the walsender/walreceiver protocol leaves
>> anyone who is using WAL shipping out in the cold. I'm not clear from
>> the co
On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas wrote:
> It also strikes me that anything
> that is based on augmenting the walsender/walreceiver protocol leaves
> anyone who is using WAL shipping out in the cold. I'm not clear from
> the comments you or Simon have made how important you think that
On Sat, Dec 10, 2011 at 7:29 AM, Greg Smith wrote:
> -It adds overhead at every commit, even for people who aren't using it.
> Probably not enough to matter, but it's yet another thing going through the
> often maligned as too heavy pgstat system, often.
The bit about the pgstat system being too
On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith wrote:
> "We can send regular special messages from WALSender to WALReceiver that do
> not form part of the WAL stream, so we don't bulk
> up WAL archives. (i.e. don't use "w" messages)."
>
> Here's my understanding of how this would work.
Let me expl
On 10/02/2011 07:10 AM, Robert Haas wrote:
Your proposals involve sending additional information from the master to
the slave, but the slave already knows both its WAL position and the
timestamp of the transaction it has most recently replayed, because
the startup process on the slave tracks that
On Thu, Oct 13, 2011 at 14:25, Robert Haas wrote:
> On Tue, Oct 4, 2011 at 9:15 AM, Simon Riggs wrote:
>>> Simon, could you? If your proposal turns out to be better than mine, I'd be
>>> happy to agree to drop my patch and adopt yours.
>>
>> Yes, will do.
>
> Simon,
>
> I believe that we are stil
On Tue, Oct 4, 2011 at 9:15 AM, Simon Riggs wrote:
>> Simon, could you? If your proposal turns out to be better than mine, I'd be
>> happy to agree to drop my patch and adopt yours.
>
> Yes, will do.
Simon,
I believe that we are still waiting for this.
Thanks,
--
Robert Haas
EnterpriseDB: htt
On Tue, Oct 4, 2011 at 1:05 PM, Fujii Masao wrote:
> On Tue, Oct 4, 2011 at 5:33 AM, Robert Haas wrote:
>> On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs wrote:
>>> On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas wrote:
>>>
Sorry, but I still don't really think it's fair to say that you've
p
On Tue, Oct 4, 2011 at 5:33 AM, Robert Haas wrote:
> On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs wrote:
>> On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas wrote:
>>
>>> Sorry, but I still don't really think it's fair to say that you've
>>> proposed a solution to this problem. Or if you have, neithe
On Mon, Oct 3, 2011 at 6:31 PM, Fujii Masao wrote:
>> Also, in pg_last_xact_insert_timestamp, the errhint() seems a little
>> strange - this is not exactly a WAL *control* function, is it?
>
> Not only "control" but also "WAL" might be confusing. What about
> "transaction information functions"?
On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs wrote:
> On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas wrote:
>
>> Sorry, but I still don't really think it's fair to say that you've
>> proposed a solution to this problem. Or if you have, neither I nor
>> Fujii Masao understand that proposal well enoug
On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas wrote:
> Sorry, but I still don't really think it's fair to say that you've
> proposed a solution to this problem. Or if you have, neither I nor
> Fujii Masao understand that proposal well enough to decide whether we
> like it.
Arguing between trenche
On Sun, Oct 2, 2011 at 8:21 AM, Simon Riggs wrote:
> The problem is to find the replication delay, even when the system is quiet.
>
> What I have proposed finds the replication delay more accurately even
> than looking at the last commit, since often there are writes but no
> commits.
>
> If we fo
On Fri, Sep 30, 2011 at 4:18 PM, Simon Riggs wrote:
> If we want to measure times, we can easily send regular messages into
> WAL to provide this function. Using checkpoint records would seem
> frequent enough to me. We don't always send checkpoint records but we
> can send an info message instead
On Sun, Oct 2, 2011 at 8:19 PM, Robert Haas wrote:
> It occurs to me that pgstat_report_xact_end_timestamp doesn't really
> need to follow the protocol of bumping the change count before and
> after bumping the timestamp. We elsewhere assume that four-byte reads
> and writes are atomic, so there'
Robert Haas writes:
> It occurs to me that pgstat_report_xact_end_timestamp doesn't really
> need to follow the protocol of bumping the change count before and
> after bumping the timestamp. We elsewhere assume that four-byte reads
> and writes are atomic, so there's no harm in assuming the same
On Sun, Oct 2, 2011 at 12:10 PM, Robert Haas wrote:
> On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs wrote:
>> On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas wrote:
>>> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs wrote:
If the feature could not be done another way, easily, I might agree.
>>>
On Thu, Sep 15, 2011 at 4:52 AM, Fujii Masao wrote:
> Okay, I've changed the patch in that way.
It occurs to me that pgstat_report_xact_end_timestamp doesn't really
need to follow the protocol of bumping the change count before and
after bumping the timestamp. We elsewhere assume that four-byte
On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs wrote:
> On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas wrote:
>> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs wrote:
>>> If the feature could not be done another way, easily, I might agree.
>>
>> I don't see that you've offered a reasonable alternative
On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas wrote:
> On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs wrote:
>> If the feature could not be done another way, easily, I might agree.
>
> I don't see that you've offered a reasonable alternative. The
> alternative proposals that you proposed don't appe
On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs wrote:
> If the feature could not be done another way, easily, I might agree.
I don't see that you've offered a reasonable alternative. The
alternative proposals that you proposed don't appear to me to be
solving the same problem. AIUI, the requested
On Fri, Sep 30, 2011 at 8:11 PM, Robert Haas wrote:
> On Fri, Sep 30, 2011 at 3:18 AM, Simon Riggs wrote:
>> On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI
>> wrote:
>>
>>> Ok, I send this patch to comitters.
>>
>> I repeat my objection to this patch. I'm very sorry I haven't been
>> around
On Fri, Sep 30, 2011 at 3:18 AM, Simon Riggs wrote:
> On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI
> wrote:
>
>> Ok, I send this patch to comitters.
>
> I repeat my objection to this patch. I'm very sorry I haven't been
> around much in last few weeks to keep up a dialogue about this and to
On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI
wrote:
> Ok, I send this patch to comitters.
I repeat my objection to this patch. I'm very sorry I haven't been
around much in last few weeks to keep up a dialogue about this and to
make it clear how wrong I think this is.
Adding something onto
Hello,
I understand that it has been at least practically no problem.
Ok, I send this patch to comitters.
Thanks for your dealing with nuisance questions.
At Thu, 29 Sep 2011 21:21:32 +0900, Fujii Masao wrote
in
> >> > Nevertheless this is ok for all OSs, I don't know whether
> >> > initial
On Thu, Sep 29, 2011 at 5:20 PM, Kyotaro HORIGUCHI
wrote:
> Sorry for late to re-review.
Thanks!
>> > Nevertheless this is ok for all OSs, I don't know whether
>> > initializing TimestampTz(double, int64 is ok) field with 8 bytes
>> > zeros is OK or not, for all platforms. (It is ok for
>> > IEE
Sorry for late to re-review.
One question is remaind,
> > Q1: The shmem entry for timestamp is not initialized on
> > allocating. Is this OK? (I don't know that for OSs other than
> > Linux) And zeroing double field is OK for all OSs?
>
> CreateSharedBackendStatus() initializes that shmem entr
On Thu, Sep 15, 2011 at 4:52 AM, Fujii Masao wrote:
> Thanks for the review!
Koyotaro Horiguchi -
Are you going to re-review the latest version of this patch?
Thanks,
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Wed, Sep 14, 2011 at 6:21 PM, Kyotaro HORIGUCHI
wrote:
> Hi, This is a review for pg_last_xact_insert_timestamp patch.
> (https://commitfest.postgresql.org/action/patch_view?id=634)
Thanks for the review!
> Q1: The shmem entry for timestamp is not initialized on
> allocating. Is this OK? (I d
Hi, This is a review for pg_last_xact_insert_timestamp patch.
(https://commitfest.postgresql.org/action/patch_view?id=634)
Summary
There's one question and two comments.
Q1: The shmem entry for timestamp is not initialized on
allocating. Is this OK? (I don't know that for OS
38 matches
Mail list logo
