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
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, Jun 2, 2010 at 10:34 PM, Florian Pflug 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 (data
(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 caus
On Jun 3, 2010, at 3:31 , Robert Haas wrote:
> On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug 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
>>> sh
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
Greg Stark wrote:
> On Mon, Mar 22, 2010 at 1:15 PM, Simon Riggs 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 no "ove
On Wed, Jun 2, 2010 at 3:10 PM, 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
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
> > > @@ -7
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 Paquie
On Wed, Jun 2, 2010 at 9:07 PM, Florian Pflug 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 event of
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 t
Heikki Linnakangas 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 call truncate_identifier() tha
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:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Greg Stark 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. How oft
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
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 document
On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne 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 thin
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
Greg Stark 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 not "request"
On Wed, Jun 2, 2010 at 8:14 PM, Tom Lane 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 the walreceiver o
On Wed, Jun 2, 2010 at 5:39 PM, Heikki Linnakangas
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 vote is no, but Heikki though
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 b
On Wed, Jun 2, 2010 at 3:46 PM, Peter Eisentraut 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 v
On Wed, Jun 2, 2010 at 2:44 PM, Tom Lane 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 important ste
On Mon, May 17, 2010 at 4:33 AM, Fujii Masao wrote:
> On Sat, May 15, 2010 at 3:20 AM, Robert Haas 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 unexpected exit, while the
> server is
Tom Lane 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
queries quicker
Heikki Linnakangas 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 situation
that query grace periods go
Dimitri Fontaine 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
catchup all the time. No
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 *
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...
Wha
Tom Lane 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 future-proof the
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
On Wed, Jun 2, 2010 at 3:20 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Robert Haas wrote:
>> > On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote:
>> > > Bruce Momjian writes:
>> > >> Uh, did we decide that 'wal_keep_segments' was the best name for this
>> > >> GUC setting? ?I know we shipp
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 expla
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Sat, May 8, 2010 at 10:40 PM, Tom Lane wrote:
> > > Bruce Momjian 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 thought min_wal_segme
Heikki Linnakangas 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 after a
>> transmission). But wi
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;
+ *
Greg Stark writes:
> On Wed, Jun 2, 2010 at 6:14 PM, Tom Lane 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 fir
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 i
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
> pos
On Wed, Jun 2, 2010 at 2:27 PM, Simon Riggs 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
> synchronisation is not a design
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 s
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 proposa
On Wed, Jun 2, 2010 at 6:14 PM, Tom Lane 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 mention of this that I
On Wed, Jun 2, 2010 at 2:05 PM, Tom Lane wrote:
> Alvaro Herrera 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
On Wed, Jun 2, 2010 at 2:03 PM, Simon Riggs wrote:
> On Wed, 2010-06-02 at 13:45 -0400, Tom Lane wrote:
>> Stephen Frost 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 tre
Alvaro Herrera 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 we don't (I don't re
On Wed, 2010-06-02 at 13:45 -0400, Tom Lane wrote:
> Stephen Frost 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_d
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
Stephen Frost 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 far
> that w
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
po
Tom Lane wrote:
Heikki Linnakangas 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 days. I was suggesting a
model
* 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
Simon Riggs 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 overhead (far more than
Simon Riggs 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
> comments amount to
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
2010/6/2 Tom Lane :
> Pavel Stehule 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 var
Heikki Linnakangas 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 mailing list (pgsql-hackers@pos
Pavel Stehule 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.
datestyle = 'cu
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
wrote:
> On 02/06/10 06:23, Fujii Masao wrote:
>>
>> On Mon, May 31, 2010 at 7:17 PM, Fujii Masao
>> wrote:
>>>
>>> 4) Change it so that checkpoint_segments takes effect in standby mode,
>>> but not during recovery otherwise
>>
>> I revised the p
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 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao 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 trigger a restartpoint
On 02/06/10 09:46, Takahiro Itagaki wrote:
Heikki Linnakangas 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 b
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 ignor
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 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 (pgsql-hackers@postgresq
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 Descr
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
+++ b/src/backend/access/transam/xl
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
70 matches
Mail list logo
