On Wed, Aug 13, 2014 at 12:41:24PM +0900, Fujii Masao wrote:
On Mon, Aug 11, 2014 at 8:27 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Aug 11, 2014 at 4:46 PM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
On 2011-10-04 20:52:59 +0900, Fujii Masao wrote:
***
On Mon, Aug 11, 2014 at 8:27 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Aug 11, 2014 at 4:46 PM, Andres Freund and...@2ndquadrant.com 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
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,
On Mon, Aug 11, 2014 at 4:46 PM, Andres Freund and...@2ndquadrant.com 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
On Mon, Dec 12, 2011 at 12:17 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith g...@2ndquadrant.com 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.
On Sat, Dec 10, 2011 at 12:29 PM, Greg Smith g...@2ndquadrant.com 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.
On Sat, Dec 10, 2011 at 7:29 AM, Greg Smith g...@2ndquadrant.com 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
On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas robertmh...@gmail.com 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
On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas robertmh...@gmail.com 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
On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas robertmh...@gmail.com wrote:
It also strikes me that anything
that is based on augmenting the
On Mon, Dec 12, 2011 at 9:51 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Dec 12, 2011 at 2:47 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Dec 12, 2011 at 9:24 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Dec 12, 2011 at 1:45 PM, Robert Haas robertmh...@gmail.com wrote:
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 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
On Thu, Oct 13, 2011 at 14:25, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 4, 2011 at 9:15 AM, Simon Riggs si...@2ndquadrant.com 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,
On Tue, Oct 4, 2011 at 9:15 AM, Simon Riggs si...@2ndquadrant.com 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
On Mon, Oct 3, 2011 at 6:31 PM, Fujii Masao masao.fu...@gmail.com 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
On Tue, Oct 4, 2011 at 5:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas robertmh...@gmail.com wrote:
Sorry, but I still don't really think it's fair to say that you've
On Tue, Oct 4, 2011 at 1:05 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Oct 4, 2011 at 5:33 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Oct 2, 2011 at 8:19 PM, Robert Haas robertmh...@gmail.com 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
On Fri, Sep 30, 2011 at 4:18 PM, Simon Riggs si...@2ndquadrant.com 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
On Sun, Oct 2, 2011 at 8:21 AM, Simon Riggs si...@2ndquadrant.com 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
On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas robertmh...@gmail.com 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.
On Mon, Oct 3, 2011 at 4:25 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Oct 3, 2011 at 8:07 PM, Robert Haas robertmh...@gmail.com 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
On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
If the feature could not be done another way, easily, I might agree.
I
On Thu, Sep 15, 2011 at 4:52 AM, Fujii Masao masao.fu...@gmail.com 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
On Sun, Oct 2, 2011 at 12:10 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 30, 2011 at 4:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs si...@2ndquadrant.com wrote:
Robert Haas robertmh...@gmail.com 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
On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp 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
On Fri, Sep 30, 2011 at 3:18 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp 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
On Fri, Sep 30, 2011 at 8:11 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 30, 2011 at 3:18 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp wrote:
Ok, I send this patch to comitters.
I repeat my
On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs si...@2ndquadrant.com 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.
On Fri, Sep 30, 2011 at 8:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Sep 30, 2011 at 3:22 PM, Simon Riggs si...@2ndquadrant.com 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
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 entries by
On Thu, Sep 29, 2011 at 5:20 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp 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.
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 masao.fu...@gmail.com wrote
in
On Thu, Sep 15, 2011 at 4:52 AM, Fujii Masao masao.fu...@gmail.com 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
On Wed, Sep 14, 2011 at 6:21 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp 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
37 matches
Mail list logo
