tracking commit timestamps
Hi,
There has been some interest in keeping track of timestamp of
transaction commits. This patch implements that.
There are some seemingly curious choices here. First, this module can
be disabled, and in fact it's turned off by default. At startup, we
verify whether it's enabled, and create the necessary SLRU segments if
so. And if the server is started with this disabled, we set the oldest
value we know about to avoid trying to read the commit TS of
transactions of which we didn't keep record. The ability to turn this
off is there to avoid imposing the overhead on systems that don't need
this feature.
Another thing of note is that we allow for some extra data alongside the
timestamp proper. This might be useful for a replication system that
wants to keep track of the origin node ID of a committed transaction,
for example. Exactly what will we do with the bit space we have is
unclear, so I have kept it generic and called it "commit extra data".
This offers the chance for outside modules to set the commit TS of a
transaction; there is support for WAL-logging such values. But the core
user of the feature (RecordTransactionCommit) doesn't use it, because
xact.c's WAL logging itself is enough. For systems that are replicating
transactions from remote nodes, it is useful.
We also keep track of the latest committed transaction. This is
supposed to be useful to calculate replication lag.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
committs.patchtext/x-diff; charset=us-asciiDownload+1063-25
On Wed, Oct 23, 2013 at 3:46 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Hi,
There has been some interest in keeping track of timestamp of
transaction commits. This patch implements that.
Some of the use cases, I could think of are
1. Is it for usecases such that if user want to read all data of table
where transaction commit_ts <= '2012-04-04 09:30:00'?
2. for replication systems, may be the middleware can use it to replay
transactions in some remote system.
3. Is there any use of this feature in logical-rep/change data extraction?
There are some seemingly curious choices here. First, this module can
be disabled, and in fact it's turned off by default. At startup, we
verify whether it's enabled, and create the necessary SLRU segments if
so. And if the server is started with this disabled, we set the oldest
value we know about to avoid trying to read the commit TS of
transactions of which we didn't keep record. The ability to turn this
off is there to avoid imposing the overhead on systems that don't need
this feature.Another thing of note is that we allow for some extra data alongside the
timestamp proper. This might be useful for a replication system that
wants to keep track of the origin node ID of a committed transaction,
for example. Exactly what will we do with the bit space we have is
unclear, so I have kept it generic and called it "commit extra data".
"commit extra data" can be LSN of commit log record, but I think it
will also depend on how someone wants to use this feature.
To suggest for storing LSN, I had referred information at below page
which describes about similar information for each transaction.
http://technet.microsoft.com/en-us/library/cc645959.aspx
This offers the chance for outside modules to set the commit TS of a
transaction; there is support for WAL-logging such values. But the core
user of the feature (RecordTransactionCommit) doesn't use it, because
xact.c's WAL logging itself is enough.
I have one question for the case when commits is set from
RecordTransactionCommit().
*** 1118,1123 **** RecordTransactionCommit(void)
--- 1119,1132 ----
} /*
+ * We don't need to log the commit timestamp separately since the commit
+ * record logged above has all the necessary action to set the timestamp
+ * again.
+ */
+ TransactionTreeSetCommitTimestamp(xid, nchildren, children,
+ xactStopTimestamp, 0, false);
+Here for CLOG, we are doing Xlogflush before writing to Clog page, but
Committs writes timestamp before XlogFlush().
Won't that create problem for synchronous commit as Checkpoint can
takecare of flushing Xlog for relation pages before flush of page,
but for Clog/Committs RecordTransactionCommit() should take care of doing it.
With Regards,
Amit Kapila.
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
On Tue, Oct 22, 2013 at 5:16 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Hi,
There has been some interest in keeping track of timestamp of
transaction commits. This patch implements that.
Hi,
Sorry for the delay on the review.
First, because of the recent fixes the patch doesn't apply cleanly
anymore but the changes seems to be easy.
=== performance ===
i expected a regression on performance with the module turned on
because of the new XLOG records and wrote of files in pg_committs but
the performance drop is excessive.
Master 437.835674 tps
Patch, guc off 436.4340982 tps
Patch, guc on 0.370524 tps
This is in a pgbench's db initialized with scale=50 and run with
"pgbench -c 64 -j 16 -n -T 300" 5 times (values above are the average
of runs)
postgresql changes:
shared_buffers = 1GB
full_page_writes = off
checkpoint_segments = 30
checkpoint_timeout = 15min
random_page_cost = 2.0
== functionality ==
I started the server with the module off, then after some work turned
the module on and restarted the server and run a few benchs then
turned it off again and restart the server and get a message like:
"""
LOG: database system was not properly shut down; automatic recovery in progress
LOG: record with zero length at 0/3112AE58
LOG: redo is not required
FATAL: cannot make new WAL entries during recovery
LOG: startup process (PID 24876) exited with exit code 1
LOG: aborting startup due to startup process failure
"""
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación
Phone: +593 4 5107566 Cell: +593 987171157
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-12-02 02:39:55 -0500, Jaime Casanova wrote:
=== performance ===
i expected a regression on performance with the module turned on
because of the new XLOG records and wrote of files in pg_committs but
the performance drop is excessive.
Master 437.835674 tps
Patch, guc off 436.4340982 tps
Patch, guc on 0.370524 tps
There clearly is something wrong. The additional amount of xlog records
should be nearly unnoticeable because committs piggybacks on commit
records.
I started the server with the module off, then after some work turned
the module on and restarted the server and run a few benchs then
turned it off again and restart the server and get a message like:"""
LOG: database system was not properly shut down; automatic recovery in progress
LOG: record with zero length at 0/3112AE58
LOG: redo is not required
FATAL: cannot make new WAL entries during recovery
LOG: startup process (PID 24876) exited with exit code 1
LOG: aborting startup due to startup process failure
"""
Alvaro: That's because of the location you call StartupCommitts - a)
it's called at the beginning of recovery if HS is enabled b) it's called
before StartupXLOG() does LocalSetXLogInsertAllowed().
So I think you need to split StartupCommitts into StartupCommitts() and
TrimCommitts() where only the latter does the trimming if committs is
disabled.
I also wonder if track_commit_timestamp should be tracked by the the
XLOG_PARAMETER_CHANGE stuff? So it's not disabled on the standby when
it's enabled on the primary?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 10/23/2013 01:16 AM, Alvaro Herrera wrote:
There has been some interest in keeping track of timestamp of
transaction commits. This patch implements that.There are some seemingly curious choices here. First, this module can
be disabled, and in fact it's turned off by default. At startup, we
verify whether it's enabled, and create the necessary SLRU segments if
so. And if the server is started with this disabled, we set the oldest
value we know about to avoid trying to read the commit TS of
transactions of which we didn't keep record. The ability to turn this
off is there to avoid imposing the overhead on systems that don't need
this feature.Another thing of note is that we allow for some extra data alongside the
timestamp proper. This might be useful for a replication system that
wants to keep track of the origin node ID of a committed transaction,
for example. Exactly what will we do with the bit space we have is
unclear, so I have kept it generic and called it "commit extra data".This offers the chance for outside modules to set the commit TS of a
transaction; there is support for WAL-logging such values. But the core
user of the feature (RecordTransactionCommit) doesn't use it, because
xact.c's WAL logging itself is enough. For systems that are replicating
transactions from remote nodes, it is useful.We also keep track of the latest committed transaction. This is
supposed to be useful to calculate replication lag.
Generally speaking, I'm not in favor of adding dead code, even if it
might be useful to someone in the future. For one, it's going to get
zero testing. Once someone comes up with an actual use case, let's add
that stuff at that point. Otherwise there's a good chance that we build
something that's almost but not quite useful.
Speaking of the functionality this does offer, it seems pretty limited.
A commit timestamp is nice, but it isn't very interesting on its own.
You really also want to know what the transaction did, who ran it, etc.
ISTM some kind of a auditing or log-parsing system that could tell you
all that would be much more useful, but this patch doesn't get us any
closer to that.
Does this handle XID wraparound correctly? SLRU has a maximum of 64k
segments with 32 SLRU pages each. With 12 bytes per each commit entry,
that's not enough to hold the timestamp and "commit extra data" of the
whole 2^31 XID range: (8192 * 32 * 65536) / 12 = 1431655765. And that's
with the default page size, with smaller pages you run into the limit
quicker.
It would be nice to teach SLRU machinery how to deal with more than 64k
segments. SSI code in twophase.c ran into the same limit, and all you
get is a warning there.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013-12-10 11:56:45 +0200, Heikki Linnakangas wrote:
Speaking of the functionality this does offer, it seems pretty limited. A
commit timestamp is nice, but it isn't very interesting on its own. You
really also want to know what the transaction did, who ran it, etc. ISTM
some kind of a auditing or log-parsing system that could tell you all that
would be much more useful, but this patch doesn't get us any closer to
that.
It's useful for last-update-wins for async multimaster. Currently
several userspace solutions try to approximate it by inserting a
timestamps into a column when a row is inserted or updated, but that is
quite limiting because either the number is out of date wrt. the commit
and/or it will differ between the rows.
I don't see how you could get an accurate timestamp in a significantly
different way?
Does this handle XID wraparound correctly? SLRU has a maximum of 64k
segments with 32 SLRU pages each. With 12 bytes per each commit entry,
that's not enough to hold the timestamp and "commit extra data" of the whole
2^31 XID range: (8192 * 32 * 65536) / 12 = 1431655765. And that's with the
default page size, with smaller pages you run into the limit quicker.It would be nice to teach SLRU machinery how to deal with more than 64k
segments. SSI code in twophase.c ran into the same limit, and all you get is
a warning there.
Yea, 9.3 is already running afoul of that, because of the changed size
for the multixact member pages. Came up just yesterday in the course of
#8673.
(gdb) p/x (1L<<32)/(MULTIXACT_MEMBERS_PER_PAGE * SLRU_PAGES_PER_SEGMENT)
$10 = 0x14078
Is this limitation actually documented anywhere? And is there anything
that needs to be changed but SlruScanDirectory()?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 10, 2013 at 4:56 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
Generally speaking, I'm not in favor of adding dead code, even if it might
be useful to someone in the future. For one, it's going to get zero testing.
Once someone comes up with an actual use case, let's add that stuff at that
point. Otherwise there's a good chance that we build something that's almost
but not quite useful.
Fair.
Speaking of the functionality this does offer, it seems pretty limited. A
commit timestamp is nice, but it isn't very interesting on its own. You
really also want to know what the transaction did, who ran it, etc. ISTM
some kind of a auditing or log-parsing system that could tell you all that
would be much more useful, but this patch doesn't get us any closer to that.
For what it's worth, I think that this has been requested numerous
times over the years by numerous developers of replication solutions.
My main question (apart from whether or not it may have bugs) is
whether it makes a noticeable performance difference. If it does,
that sucks. If it does not, maybe we ought to enable it by default.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
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 escribi�:
On Tue, Dec 10, 2013 at 4:56 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
Speaking of the functionality this does offer, it seems pretty limited. A
commit timestamp is nice, but it isn't very interesting on its own. You
really also want to know what the transaction did, who ran it, etc. ISTM
some kind of a auditing or log-parsing system that could tell you all that
would be much more useful, but this patch doesn't get us any closer to that.For what it's worth, I think that this has been requested numerous
times over the years by numerous developers of replication solutions.
My main question (apart from whether or not it may have bugs) is
whether it makes a noticeable performance difference. If it does,
that sucks. If it does not, maybe we ought to enable it by default.
I expect it will have some performance impact -- this is why we made it
disable-able in the first place, and why I went to the trouble of
ensuring it can be turned on after initdb. Normal pg_clog entries are 2
bits per transaction, whereas the commit timestamp stuff adds 12 *bytes*
per transaction. Not something to be taken lightly, hence it's off by
default. Presumably people who is using one of those replication
systems is okay with taking some (reasonable) performance hit.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 10, 2013 at 4:04 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Robert Haas escribió:
On Tue, Dec 10, 2013 at 4:56 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:Speaking of the functionality this does offer, it seems pretty limited. A
commit timestamp is nice, but it isn't very interesting on its own. You
really also want to know what the transaction did, who ran it, etc. ISTM
some kind of a auditing or log-parsing system that could tell you all that
would be much more useful, but this patch doesn't get us any closer to that.For what it's worth, I think that this has been requested numerous
times over the years by numerous developers of replication solutions.
My main question (apart from whether or not it may have bugs) is
whether it makes a noticeable performance difference. If it does,
that sucks. If it does not, maybe we ought to enable it by default.I expect it will have some performance impact -- this is why we made it
disable-able in the first place, and why I went to the trouble of
ensuring it can be turned on after initdb. Normal pg_clog entries are 2
bits per transaction, whereas the commit timestamp stuff adds 12 *bytes*
per transaction. Not something to be taken lightly, hence it's off by
default. Presumably people who is using one of those replication
systems is okay with taking some (reasonable) performance hit.
Well, writing 12 extra bytes (why not 8?) on each commit is not
intrinsically that expensive. The (poor) design of SLRU might make it
expensive, though, because since it has no fsync absorption queue, so
sometimes you end up waiting for an fsync, and doing that 48x more
often will indeed have some cost. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
I worked bit on this patch to make it closer to committable state.
There are several bugs fixed, including ones mentioned by Jamie (writing
WAL during recovery).
Also support for pg_resetxlog/pg_upgrade has been implemented by Andres.
I added simple regression test and regression contrib module to cover
both off and on settings.
The SLRU issue Heikki mentioned should be also gone mainly thanks to
638cf09e7 (I did test it too).
One notable thing missing is documentation for the three SQL level
interfaces provided, I plan to add that soon.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
committs-v5.patchtext/x-diff; name=committs-v5.patchDownload+1254-18
On 09/09/14 19:05, Petr Jelinek wrote:
Hi,
I worked bit on this patch to make it closer to committable state.
There are several bugs fixed, including ones mentioned by Jamie (writing
WAL during recovery).Also support for pg_resetxlog/pg_upgrade has been implemented by Andres.
I added simple regression test and regression contrib module to cover
both off and on settings.The SLRU issue Heikki mentioned should be also gone mainly thanks to
638cf09e7 (I did test it too).
Here is updated version that works with current HEAD for the October
committfest.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
committs-v6.patchtext/x-diff; name=committs-v6.patchDownload+1320-19
On 13 October 2014 10:05, Petr Jelinek <petr@2ndquadrant.com> wrote:
I worked bit on this patch to make it closer to committable state.
Here is updated version that works with current HEAD for the October
committfest.
I've reviewed this and it looks good to me. Clean, follows existing
code neatly, documented and tested.
Please could you document a few things
* ExtendCommitTS() works only because commit_ts_enabled can only be
set at server start.
We need that documented so somebody doesn't make it more easily
enabled and break something.
(Could we make it enabled at next checkpoint or similar?)
* The SLRU tracks timestamps of both xids and subxids. We need to
document that it does this because Subtrans SLRU is not persistent. If
we made Subtrans persistent we might need to store only the top level
xid's commitTS, but that's very useful for typical use cases and
wouldn't save much time at commit.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Oct 28, 2014 at 9:25 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 13 October 2014 10:05, Petr Jelinek <petr@2ndquadrant.com> wrote:
I worked bit on this patch to make it closer to committable state.
Here is updated version that works with current HEAD for the October
committfest.I've reviewed this and it looks good to me. Clean, follows existing
code neatly, documented and tested.Please could you document a few things
* ExtendCommitTS() works only because commit_ts_enabled can only be
set at server start.
We need that documented so somebody doesn't make it more easily
enabled and break something.
(Could we make it enabled at next checkpoint or similar?)* The SLRU tracks timestamps of both xids and subxids. We need to
document that it does this because Subtrans SLRU is not persistent. If
we made Subtrans persistent we might need to store only the top level
xid's commitTS, but that's very useful for typical use cases and
wouldn't save much time at commit.
Hm. What is the performance impact of this feature using the latest version
of this patch? I imagine that the penalty of the additional operations this
feature introduces is not zero, particularly for loads with lots of short
transactions.
--
Michael
On 2014-10-31 14:55:11 +0900, Michael Paquier wrote:
On Tue, Oct 28, 2014 at 9:25 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 13 October 2014 10:05, Petr Jelinek <petr@2ndquadrant.com> wrote:
I worked bit on this patch to make it closer to committable state.
Here is updated version that works with current HEAD for the October
committfest.I've reviewed this and it looks good to me. Clean, follows existing
code neatly, documented and tested.Please could you document a few things
* ExtendCommitTS() works only because commit_ts_enabled can only be
set at server start.
We need that documented so somebody doesn't make it more easily
enabled and break something.
(Could we make it enabled at next checkpoint or similar?)* The SLRU tracks timestamps of both xids and subxids. We need to
document that it does this because Subtrans SLRU is not persistent. If
we made Subtrans persistent we might need to store only the top level
xid's commitTS, but that's very useful for typical use cases and
wouldn't save much time at commit.Hm. What is the performance impact of this feature using the latest version
of this patch?
I haven't measured it recently, but it wasn't large, but measureable.
I imagine that the penalty of the additional operations this
feature introduces is not zero, particularly for loads with lots of short
transactions.
Which is why you can disable it...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 10, 2013 at 2:48 PM, Robert Haas <robertmhaas@gmail.com> wrote:
Speaking of the functionality this does offer, it seems pretty limited. A
commit timestamp is nice, but it isn't very interesting on its own. You
really also want to know what the transaction did, who ran it, etc. ISTM
some kind of a auditing or log-parsing system that could tell you all that
would be much more useful, but this patch doesn't get us any closer to that.For what it's worth, I think that this has been requested numerous
times over the years by numerous developers of replication solutions.
My main question (apart from whether or not it may have bugs) is
whether it makes a noticeable performance difference. If it does,
that sucks. If it does not, maybe we ought to enable it by default.
+1
It's also requested now and then in the context of auditing and
forensic analysis of application problems. But I also agree that the
tolerance for performance overhead is got to be quite low. If a GUC
is introduced to manage the tradeoff, it should be defaulted to 'on'.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Merlin Moncure <mmoncure@gmail.com> writes:
It's also requested now and then in the context of auditing and
forensic analysis of application problems. But I also agree that the
tolerance for performance overhead is got to be quite low. If a GUC
is introduced to manage the tradeoff, it should be defaulted to 'on'.
Alvaro's original submission specified that the feature defaults to "off".
Since there's no use-case for it unless you've installed some third-party
code (eg an external replication solution), I think that should stay true.
The feature's overhead might be small, but it is most certainly not zero,
and people shouldn't be paying for it unless they need it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 31/10/14 15:07, Tom Lane wrote:
Merlin Moncure <mmoncure@gmail.com> writes:
It's also requested now and then in the context of auditing and
forensic analysis of application problems. But I also agree that the
tolerance for performance overhead is got to be quite low. If a GUC
is introduced to manage the tradeoff, it should be defaulted to 'on'.Alvaro's original submission specified that the feature defaults to "off".
Since there's no use-case for it unless you've installed some third-party
code (eg an external replication solution), I think that should stay true.
The feature's overhead might be small, but it is most certainly not zero,
and people shouldn't be paying for it unless they need it.
Agreed, that's why it stayed 'off' in my version too.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 28/10/14 13:25, Simon Riggs wrote:
On 13 October 2014 10:05, Petr Jelinek <petr@2ndquadrant.com> wrote:
I worked bit on this patch to make it closer to committable state.
Here is updated version that works with current HEAD for the October
committfest.I've reviewed this and it looks good to me. Clean, follows existing
code neatly, documented and tested.
Thanks for looking at this.
Please could you document a few things
* ExtendCommitTS() works only because commit_ts_enabled can only be
set at server start.
We need that documented so somebody doesn't make it more easily
enabled and break something.
(Could we make it enabled at next checkpoint or similar?)
Maybe we could, but that means some kind of two step enabling facility
and I don't want to write that as part of the initial patch since that
will need separate discussion (i.e. do we want to have new GUC flag for
this, or hack solution just for committs?). So maybe later in a
follow-up patch.
* The SLRU tracks timestamps of both xids and subxids. We need to
document that it does this because Subtrans SLRU is not persistent. If
we made Subtrans persistent we might need to store only the top level
xid's commitTS, but that's very useful for typical use cases and
wouldn't save much time at commit.
Attached version with the above comments near the relevant code.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
committs-v7.patchtext/x-diff; name=committs-v7.patchDownload+1329-19
On 31 October 2014 15:46, Petr Jelinek <petr@2ndquadrant.com> wrote:
Attached version with the above comments near the relevant code.
Looks cooked and ready to serve. Who's gonna commit this? Alvaro, or
do you want me to?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Nov 1, 2014 at 1:15 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On 31 October 2014 15:46, Petr Jelinek <petr@2ndquadrant.com> wrote:
Attached version with the above comments near the relevant code.
Looks cooked and ready to serve. Who's gonna commit this? Alvaro, or
do you want me to?
Could you hold on a bit? I'd like to have a look at it more deeply and by
looking at quickly at the code there are a couple of things that could be
improved.
Regards,
--
Michael
