Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Hmm, seems that dblink should call truncate_identifier() for the
truncation, to be consistent with truncation of table names etc.
Hmmm, we need the same routine with truncate_identifier(), but we hard
to use the function because
Heikki Linnakangas wrote:
The possibilities are endless... Your proposal above covers a pretty
good set of scenarios, but it's by no means complete. If we try to
solve everything the configuration will need to be written in a
Turing-complete Replication Description Language. We'll have to pick
Hi,
I found some obsolete comments in xlog.c, which are related to
recently-deleted variable fromArchive.
diff --git a/src/backend/access/transam/xlog.c
b/src/backend/access/transam/xlog.c
index c886571..65675b9 100644
--- a/src/backend/access/transam/xlog.c
+++
On 02/06/10 10:22, Greg Smith wrote:
Heikki Linnakangas wrote:
The possibilities are endless... Your proposal above covers a pretty
good set of scenarios, but it's by no means complete. If we try to
solve everything the configuration will need to be written in a
Turing-complete Replication
On 02/06/10 10:39, Fujii Masao wrote:
I found some obsolete comments in xlog.c, which are related to
recently-deleted variable fromArchive.
Thanks, committed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On Wed, 2010-06-02 at 03:22 -0400, Greg Smith wrote:
Heikki Linnakangas wrote:
The possibilities are endless... Your proposal above covers a pretty
good set of scenarios, but it's by no means complete. If we try to
solve everything the configuration will need to be written in a
On 28/05/10 04:00, Josh Berkus wrote:
Consider a table that is
regularly written but append-only. Every time autovacuum kicks in,
we'll go and remove any dead tuples and then mark the pages
PD_ALL_VISIBLE and set the visibility map bits, which will cause
subsequent vacuums to ignore the
On 02/06/10 09:46, Takahiro Itagaki wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
Hmm, seems that dblink should call truncate_identifier() for the
truncation, to be consistent with truncation of table names etc.
Hmmm, we need the same routine with
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masaomasao.fu...@gmail.com wrote:
4) Change it so that checkpoint_segments takes effect in standby mode,
but not during recovery otherwise
I revised the patch to achieve 4). This will enable checkpoint_segments
to
Hello
I thinking about request on custom datetime format. My first idea is:
a) add new datestyle format custom
b) add new GUC variables - custom_date_format, custom_time_format,
custom_timestamp_format
There are some questions:
a) what is good behave when datestyle = custom, but some necessary
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masaomasao.fu...@gmail.com
wrote:
4) Change it so that checkpoint_segments takes effect in standby mode,
but not during
Pavel Stehule pavel.steh...@gmail.com writes:
I thinking about request on custom datetime format. My first idea is:
a) add new datestyle format custom
b) add new GUC variables - custom_date_format, custom_time_format,
custom_timestamp_format
Ick. Why not just put them in one variable.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
It's pretty scary to call a user-defined function at that point in
transaction.
Not so much pretty scary as zero chance of being accepted.
And I do mean zero.
regards, tom lane
--
Sent via pgsql-hackers
2010/6/2 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I thinking about request on custom datetime format. My first idea is:
a) add new datestyle format custom
b) add new GUC variables - custom_date_format, custom_time_format,
custom_timestamp_format
Ick. Why
On Mon, 2010-05-31 at 14:40 -0400, Bruce Momjian wrote:
Uh, we have three days before we package 9.0beta2. It would be good if
we could decide on the max_standby_delay issue soon.
I've heard something from Heikki, not from anyone else. Those comments
amount to lets replace max_standby_delay
Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-05-31 at 14:40 -0400, Bruce Momjian wrote:
Uh, we have three days before we package 9.0beta2. It would be
good if we could decide on the max_standby_delay issue soon.
I've heard something from Heikki, not from anyone else. Those
Simon Riggs si...@2ndquadrant.com writes:
OK, here's v4.
I've been trying to stay out of this thread, but with beta2 approaching
and no resolution in sight, I'm afraid I have to get involved.
This patch seems to me to be going in fundamentally the wrong direction.
It's adding complexity and
* Tom Lane (t...@sss.pgh.pa.us) wrote:
An important property of this design is that all relevant timestamps
are taken on the slave, so clock skew isn't an issue.
I agree that this is important, and I do run NTP on all my servers and
even monitor it using Nagios.
It's still not a cure-all for
Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
It's pretty scary to call a user-defined function at that point in
transaction.
Not so much pretty scary as zero chance of being accepted.
And I do mean zero.
I swear, you guys are such buzzkills some
Tom Lane wrote:
I'm still inclined to apply the part of Simon's patch that adds a
transmit timestamp to each SR send chunk. That would actually be
completely unused by the slave given my proposal above, but I think that
it is an important step to take to future-proof the SR protocol against
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Comments?
I'm not really a huge fan of adding another GUC, to be honest. I'm more
inclined to say we treat 'max_archive_delay' as '0', and turn
max_streaming_delay into what you've described. If we fall back so
Excerpts from Russell Smith's message of mié jun 02 06:38:35 -0400 2010:
Don't you not get a positive enough effect by adjusting the table's
autovacuum_min_freeze_age and autovacuum_max_freeze_age. If you set
those numbers small, it appears to me that you would get very quickly to
a state
On Wed, 2010-06-02 at 13:45 -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Comments?
I'm not really a huge fan of adding another GUC, to be honest. I'm more
inclined to say we treat 'max_archive_delay' as '0', and turn
Alvaro Herrera alvhe...@commandprompt.com writes:
The problem is that vacuum doesn't know that a certain part of the table
is already frozen. It needs to scan it completely anyways. If we had a
frozen map, we could mark pages that are completely frozen and thus do
not need any vacuuming; but
On Wed, Jun 2, 2010 at 2:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-06-02 at 13:45 -0400, Tom Lane wrote:
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Comments?
I'm not really a huge fan of adding another GUC, to be honest. I'm more
On Wed, Jun 2, 2010 at 2:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
The problem is that vacuum doesn't know that a certain part of the table
is already frozen. It needs to scan it completely anyways. If we had a
frozen map, we could mark pages
On Wed, Jun 2, 2010 at 6:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I believe that the motivation for treating archived timestamps as live
is, essentially, to force rapid catchup if a slave falls behind so far
that it's reading from archive instead of SR.
Huh, I think this is the first
On Wed, 2010-06-02 at 13:14 -0400, Tom Lane wrote:
This patch seems to me to be going in fundamentally the wrong direction.
It's adding complexity and overhead (far more than is needed), and it's
failing utterly to resolve the objections that I raised to start with.
Having read your proposal,
d...@csail.mit.edu (Dan Ports) writes:
I'm not clear on why the total rowcount is useful, but perhaps I'm
missing something obvious.
It would make it easy to conclude:
This next transaction did 8328194 updates. Maybe we should do
some kind of checkpoint (e.g. - commit transaction or
On Wed, Jun 2, 2010 at 2:27 PM, Simon Riggs si...@2ndquadrant.com wrote:
Syncing two servers in replication is common practice, as has been
explained here; I'm still surprised people think otherwise. Measuring
the time between two servers is the very purpose of the patch, so the
I wrote:
I'm still inclined to apply the part of Simon's patch that adds a
transmit timestamp to each SR send chunk. That would actually be
completely unused by the slave given my proposal above, but I think that
it is an important step to take to future-proof the SR protocol against
Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010:
We could, but I think we'd be better off just freezing at the time we
mark the page PD_ALL_VISIBLE and then using the visibility map for
both purposes. Keeping around the old xmin values after every tuple
on the page is
Greg Stark gsst...@mit.edu writes:
On Wed, Jun 2, 2010 at 6:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I believe that the motivation for treating archived timestamps as live
is, essentially, to force rapid catchup if a slave falls behind so far
that it's reading from archive instead of SR.
On 02/06/10 21:44, Tom Lane wrote:
In conjunction with that, I think there's a logic bug in XLogSend;
it ought to be changed like so:
/* if we went beyond SendRqstPtr, back off */
if (XLByteLT(SendRqstPtr, endptr))
+ {
endptr = SendRqstPtr;
+
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 02/06/10 21:44, Tom Lane wrote:
In the current coding, the effect of not setting *caughtup here is just
that we uselessly call XLogSend an extra time for each transmission
(because the main loop won't ever delay immediately
Bruce Momjian wrote:
Robert Haas wrote:
On Sat, May 8, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Uh, did we decide that 'wal_keep_segments' was the best name for this
GUC setting? ?I know we shipped beta1 using that name.
I
heikki.linnakan...@enterprisedb.com (Heikki Linnakangas) writes:
On 24/05/10 19:51, Kevin Grittner wrote:
The only thing I'm confused about is what benefit anyone expects to
get from looking at data between commits in some way other than our
current snapshot mechanism. Can someone explain a
On Wed, Jun 2, 2010 at 3:20 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
Robert Haas wrote:
On Sat, May 8, 2010 at 10:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Uh, did we decide that 'wal_keep_segments' was the best name for this
On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote:
The attached patch allows wal_keep_segments = -1 to keep all segements;
this is particularly useful for taking a base backup, where you need all
the WAL files during startup of the standby. I have documented this
usage in the patch as
Tom Lane t...@sss.pgh.pa.us writes:
I wrote:
I'm still inclined to apply the part of Simon's patch that adds a
transmit timestamp to each SR send chunk. That would actually be
completely unused by the slave given my proposal above, but I think that
it is an important step to take to
On 02/06/10 20:14, Tom Lane wrote:
For realistic values of max_standby_delay ...
Hang on right there. What do you consider a realistic value for
max_standby_delay? Because I'm not sure I have a grip on that myself. 5
seconds? 5 minutes? 5 hours? I can see use cases for all of those...
On fre, 2010-05-28 at 20:59 +0300, Peter Eisentraut wrote:
The feature I'm thinking of is what
people might call per-column locale, and the SQL standard defines
that. It would look like this:
CREATE TABLE test (
a varchar COLLATE de,
b varchar COLLATE fr
);
SELECT * FROM test
Dimitri Fontaine dfonta...@hi-media.com writes:
I'm still trying to understand the implications of the proposal, which
sounds good but⦠given just enough load on the slave, wouldn't it be
playing catchup all the time?
Uh, if the slave is overloaded, *any* implementation will be playing
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
The problem with defining max_archive_delay that way is again that you
can fall behind indefinitely.
See my response to Greg Stark --- I don't think this is really an
issue. It's certainly far less of an issue than the current
Tom Lane t...@sss.pgh.pa.us writes:
Uh, if the slave is overloaded, *any* implementation will be playing
catchup all the time. Not sure about your point here.
Well, sorry, I missed the part where the catchup is measured on
walsender side of things. Now that means that a non interrupted flow of
On Mon, May 17, 2010 at 4:33 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, May 15, 2010 at 3:20 AM, Robert Haas robertmh...@gmail.com wrote:
Hmm, OK, I think that makes sense. Would you care to propose a patch?
Yep. Here is the patch.
This patch distinguishes normal shutdown from
On Wed, Jun 2, 2010 at 2:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
I'm still inclined to apply the part of Simon's patch that adds a
transmit timestamp to each SR send chunk. That would actually be
completely unused by the slave given my proposal above, but I think that
it is an
On Wed, Jun 2, 2010 at 3:46 PM, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-05-28 at 20:59 +0300, Peter Eisentraut wrote:
The feature I'm thinking of is what
people might call per-column locale, and the SQL standard defines
that. It would look like this:
CREATE TABLE test (
a
On 02/06/10 23:50, Robert Haas wrote:
First, is it appropriate to set the control file state to
DB_SHUTDOWNED_IN_RECOVERY even when we're in crash recovery (as
opposed to archive recovery/SR)? My vote is no, but Heikki thought it
might be OK.
My logic on that is:
If the database is known to
On Wed, Jun 2, 2010 at 5:39 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 02/06/10 23:50, Robert Haas wrote:
First, is it appropriate to set the control file state to
DB_SHUTDOWNED_IN_RECOVERY even when we're in crash recovery (as
opposed to archive recovery/SR)? My
On Wed, Jun 2, 2010 at 8:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Indeed, but nothing we do can prevent that, if the slave is just plain
slower than the master. You have to assume that the slave is capable of
keeping up in the absence of query-caused delays, or you're hosed.
I was assuming
Greg Stark gsst...@mit.edu writes:
I was assuming the walreceiver only requests more wal in relatively
small chunks and only when replay has caught up and needs more data. I
haven't actually read this code so if that assumption is wrong then
I'm off-base.
It is off-base. The receiver does
Alvaro Herrera wrote:
Excerpts from Robert Haas's message of mi?? jun 02 14:16:33 -0400 2010:
We could, but I think we'd be better off just freezing at the time we
mark the page PD_ALL_VISIBLE and then using the visibility map for
both purposes. Keeping around the old xmin values after
On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne cbbro...@acm.org wrote:
It would make it easy to conclude:
This next transaction did 8328194 updates. Maybe we should do
some kind of checkpoint (e.g. - commit transaction or such) before
working on it.
versus
This transaction we're
Simon Riggs wrote:
On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote:
The attached patch allows wal_keep_segments = -1 to keep all segements;
this is particularly useful for taking a base backup, where you need all
the WAL files during startup of the standby. I have documented this
Robert Haas wrote:
The attached patch allows wal_keep_segments = -1 to keep all segements;
this is particularly useful for taking a base backup, where you need all
the WAL files during startup of the standby. ?I have documented this
usage in the patch as well.
I am thinking of applying
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Greg Stark gsst...@mit.edu writes:
So I think this isn't necessarily such a blue moon event. As I
understand it, all it would take is a single long-running report and a
vacuum or HOT cleanup occurring on the master.
I think this is mostly FUD too.
Simon Riggs wrote:
Deferrable unique constraints seem an interesting feature, though I have
either some questions or some issues, not sure which.
I don't seem to be able to find any way to do an ALTER TABLE that adds
this new capability to an existing table.
I was able to do it:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Well, looking at the callers, most if not all of them seem to actually
pass a palloc'd copy, allocated by text_to_cstring().
Should we throw a NOTICE like vanilla truncate_identifier() does?
I feel it would be better to just
On Jun 3, 2010, at 0:58 , Robert Haas wrote:
But maybe the message isn't right the first time either. After all
the point of having a write-ahead log in the first place is that we
should be able to prevent corruption in the event of an unexpected
shutdown. Maybe the right thing to do is to
On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On Jun 3, 2010, at 0:58 , Robert Haas wrote:
But maybe the message isn't right the first time either. After all
the point of having a write-ahead log in the first place is that we
should be able to prevent corruption in the
Hi all,
Please see attached a patch that finishes the support for currval.
All the structure was in place in GTM but there was still one missing call
in sequence.c when calling the function.
Now it is possible to get current values for sequences in the whole cluster.
Regards,
--
Michael
David Fetter wrote:
On Mon, Mar 22, 2010 at 04:04:16PM -0300, Alvaro Herrera wrote:
David Fetter wrote:
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 9881ff4..9313112 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -7134,7 +7134,7 @@
On Wed, Jun 2, 2010 at 3:10 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié jun 02 14:16:33 -0400 2010:
We could, but I think we'd be better off just freezing at the time we
mark the page PD_ALL_VISIBLE and then using the visibility map for
both
Greg Stark wrote:
On Mon, Mar 22, 2010 at 1:15 PM, Simon Riggs si...@2ndquadrant.com wrote:
* Circles, Boxes and other geometric datatypes defined overlaps to
include touching shapes. So
* inet datatypes don't have a commutative operator on which a unique
index can be built. There is
Robert Haas wrote:
* inet datatypes don't have a commutative operator on which a unique
index can be built. There is no overlaps equivalent, which again is a
shame because that stops them being used with the new feature.
This would be a nice thing to fix, and I was thinking about doing
On Jun 3, 2010, at 3:31 , Robert Haas wrote:
On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug f...@phlo.org wrote:
On Jun 3, 2010, at 0:58 , Robert Haas wrote:
But maybe the message isn't right the first time either. After all
the point of having a write-ahead log in the first place is that we
(2010/06/02 12:02), KaiGai Kohei wrote:
Here's another thought. If we're leaning toward explicit syntax to
designate security views (and I do mean IF, since only one person has
signed on to that, even if it is Tom Lane!), then maybe we should
think about ripping out the logic that causes
On Wed, Jun 2, 2010 at 10:34 PM, Florian Pflug f...@phlo.org wrote:
Oh. Well, if that's the case, then I guess I lean toward applying the
patch as-is. Then there's no need for the caveat and without manual
intervention.
That still leaves the messages awfully ambiguous concerning the cause
Sorry about my previous email,
I sent a patch to the wrong mailing list.
Once again my apologies about that.
Regards,
Michael P.
On Wed, 2010-06-02 at 20:28 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote:
The attached patch allows wal_keep_segments = -1 to keep all segements;
this is particularly useful for taking a base backup, where you need all
the
71 matches
Mail list logo
