On Wed, May 5, 2010 at 9:32 PM, Robert Haas wrote:
> On Wed, May 5, 2010 at 11:50 PM, Bruce Momjian wrote:
>> If someone wants to suggest that HS is useless if max_standby_delay
>> supports only boolean values, I am ready to suggest we remove HS as well
>> and head to 9.0 because that would sugge
On Wed, 2010-05-05 at 17:56 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > I am mostly unavailable for next few days. (Repairing bikeshed.)
>
> Hey, you're supposed to do the bikeshedding on-list! ;-)
That was just a joke, I'm mostly unavailable for other reasons.
--
Simon Riggs
Robert Haas wrote:
> On Wed, May 5, 2010 at 11:50 PM, Bruce Momjian wrote:
>> The code will not be thrown away; we will bring it back for 9.1.
>
> If that's the case, then taking it out makes no sense.
I doubt we're going to bring back the same code, because it still has
the same issues. But we
Robert Haas wrote:
> On Wed, May 5, 2010 at 11:52 PM, Bruce Momjian wrote:
>> I am afraid the current setting is tempting for users to enable, but
>> will be so unpredictable that it will tarnish the repuation of HS and
>> Postgres. We don't want to be thinking in 9 months, "Wow, we shouldn't
>>
On 2010-05-06 06:41, Alvaro Herrera wrote:
Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010:
Q: I read you pdf, why isn't statistics copied over? It seems to be the last
part missing from doing an upgrade in a few minutes.
Seems fraught with peril, and a bit poi
On Wed, May 5, 2010 at 11:52 PM, Bruce Momjian wrote:
> I am afraid the current setting is tempting for users to enable, but
> will be so unpredictable that it will tarnish the repuation of HS and
> Postgres. We don't want to be thinking in 9 months, "Wow, we shouldn't
> have shipped that feature
Excerpts from Jesper Krogh's message of jue may 06 00:32:09 -0400 2010:
> Q: I read you pdf, why isn't statistics copied over? It seems to be the last
> part missing from doing an upgrade in a few minutes.
Seems fraught with peril, and a bit pointless. What's so bad about having to
run ANALYZE a
On Wed, May 5, 2010 at 11:50 PM, Bruce Momjian wrote:
> If someone wants to suggest that HS is useless if max_standby_delay
> supports only boolean values, I am ready to suggest we remove HS as well
> and head to 9.0 because that would suggest that HS itself is going to be
> useless.
I think HS i
On 2010-05-06 01:45, Bruce Momjian wrote:
Jesper Krogh wrote:
On 2010-05-03 23:09, Bruce Momjian wrote:
Robert Haas wrote:
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
wrote:
Now you tell me how awful this idea really is :)
I'm not sure I can
Greg Smith wrote:
> Bruce Momjian wrote:
> > We are not very good at _removing_ functionality/GUCs, and based on the
> > discussion so far, I think there is a very slim chance we would get it
> > right for 9.0, which is why I suggested converting it to a boolean and
> > revisiting this for 9.1.
> >
Robert Haas wrote:
> If you had a genuinely better idea for how this should work, I would
> be the first to endorse it, but it's becoming clear that you don't,
> which makes me also skeptical of your contention that we will be
> better off with no knob at all. I find that position not very
> plaus
Greg Smith wrote:
> Heikki Linnakangas wrote:
> > Let's rip out the concept of a delay altogether, and make it a boolean.
> > If you really want your query to finish, set it to -1 (using the current
> > max_standby_delay nomenclature). If recovery is important to you, set it
> > to 0.
> >
>
> S
On Wed, May 5, 2010 at 9:36 PM, Tom Lane wrote:
> Greg Smith writes:
>> Heikki Linnakangas wrote:
>>> Let's rip out the concept of a delay altogether, and make it a boolean.
>
>> So the only user options would be "allow long-running queries to block
>> WAL application forever" and "always cancel
Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> >> I think it will be confusing if we change the name, so I vote to not
> >> change the name.
>
> > Actually, I would vote yes to change the name.
>
> I lean that way too. If there were no hi
Greg Stark wrote:
On Thu, May 6, 2010 at 2:36 AM, Tom Lane wrote:
One reason I believe this isn't so critical as all that is that it only
matters for cases where the operation on the master took an exclusive
lock.
Uhm, or a vacuum ran. Or a HOT page cleanup occurred, or a btree page
s
"Joshua D. Drake" writes:
> On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
>> I think it will be confusing if we change the name, so I vote to not
>> change the name.
> Actually, I would vote yes to change the name.
I lean that way too. If there were no history involved, we'd certainly
p
On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> On Wed, May 5, 2010 at 7:44 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >>
> >> So what was the conclusion here? Is pg_migrator going to be in contrib
> >> for beta2 or 3, after cleaning it up?
> >
> > Thanks for asking. :-) I can
"Ioseph Kim" wrote:
> CP51949 is EUC-KR correct.
> >{PG_EUC_KR, "CP51949"}, /* or 20949 ? */
Thank you for the information. I removed "or 20949 ?" from the line.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Bruce Momjian wrote:
We are not very good at _removing_ functionality/GUCs, and based on the
discussion so far, I think there is a very slim chance we would get it
right for 9.0, which is why I suggested converting it to a boolean and
revisiting this for 9.1.
There's some feedback you can on
On Thu, May 6, 2010 at 2:36 AM, Tom Lane wrote:
> One reason I believe this isn't so critical as all that is that it only
> matters for cases where the operation on the master took an exclusive
> lock.
Uhm, or a vacuum ran. Or a HOT page cleanup occurred, or a btree page
split deleted old tuples.
Greg Smith writes:
> Heikki Linnakangas wrote:
>> Let's rip out the concept of a delay altogether, and make it a boolean.
> So the only user options would be "allow long-running queries to block
> WAL application forever" and "always cancel queries on conflict?
Got it in one.
Obviously, this i
Heikki Linnakangas wrote:
Let's rip out the concept of a delay altogether, and make it a boolean.
If you really want your query to finish, set it to -1 (using the current
max_standby_delay nomenclature). If recovery is important to you, set it
to 0.
So the only user options would be "allow l
Kenneth Marshall writes:
> I am working on adapting a regular PQexec() call to use binary
> transmission of the parameters. One of the parameters is an
> array of BIGINT. Looking in include/utils/array.h, it appears
> that construct_array() will do exactly what I need to get an
> array to pass in
Dear PostgreSQL development community,
I am working on adapting a regular PQexec() call to use binary
transmission of the parameters. One of the parameters is an
array of BIGINT. Looking in include/utils/array.h, it appears
that construct_array() will do exactly what I need to get an
array to pass
Bruce Momjian writes:
> Robert Haas wrote:
>> The existing behavior is probably not optimal, but I'm not seeing what
>> benefit we get out of neutering it.
> We get to design it right, or maybe not need it at all in 9.1.
Yeah. The good thing about a boolean is that it covers the two
noncontrove
Robert Haas wrote:
> >> If you have the monitoring in place to sensibly monitor the delay
> >> between primary and standby, and you want a limit on that, you can put
> >> together a script to flip the switch in postgresql.conf if the standby
> >> falls too much behind.
> >>
> >> It would be nice to
On Wed, May 5, 2010 at 7:44 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>>
>> So what was the conclusion here? Is pg_migrator going to be in contrib
>> for beta2 or 3, after cleaning it up?
>
> Thanks for asking. :-) I can add pg_migrator to contrib by the end of
> next week, so it will be
On Wed, May 5, 2010 at 7:18 PM, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> Tom Lane wrote:
>> > Comments?
>>
>> There's currently three ways to set max_standby_delay:
>>
>> max_standby_delay = -1 # Query wins
>> max_standby_delay = 0 # Recovery wins
>> max_standby_delay > X # Query
Kevin Grittner wrote:
> Simon Riggs wrote:
>
> I've refrained from comment on max_standby_delay because I have
> neither read the patch nor am likely to be an early adopter of HS;
> however, as a potential eventual user I have to say that the
> semantics for this GUC proposed by Simon seem sane
Jesper Krogh wrote:
> On 2010-05-03 23:09, Bruce Momjian wrote:
> > Robert Haas wrote:
> >
> >> On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine
> >> wrote:
> >>
> >>> Now you tell me how awful this idea really is :)
> >>>
> >> I'm not sure I can count that high. :-)
> >>
Alvaro Herrera wrote:
>
> So what was the conclusion here? Is pg_migrator going to be in contrib
> for beta2 or 3, after cleaning it up?
Thanks for asking. :-) I can add pg_migrator to contrib by the end of
next week, so it will be in beta2. I will remove 8.4 as a migration
target, which will
On 06/05/10 09:48, Mark Kirkwood wrote:
Ok - your bug is fixed in 8.3.10. This should make its way to your
Ubuntu apt repository soon (provided 8.10 is still getting updates
that is...).
Unfortunately it looks like you may not get this version - see:
http://ubuntuguide.org/wiki/Ubuntu:I
Over at
http://archives.postgresql.org/pgsql-general/2010-05/msg00091.php
we have a complaint about "make check" failing when the install is
intended to overwrite existing libraries (in particular, replacing
8.4 with 9.0 libpq). I've done some off-list investigation and
found that this appears to
Heikki Linnakangas wrote:
> Tom Lane wrote:
> > Comments?
>
> There's currently three ways to set max_standby_delay:
>
> max_standby_delay = -1# Query wins
> max_standby_delay = 0 # Recovery wins
> max_standby_delay > X # Query wins until lag > X.
>
> As Tom points out, the 3rd option ha
Heikki, all,
> There's currently three ways to set max_standby_delay:
>
> max_standby_delay = -1# Query wins
> max_standby_delay = 0 # Recovery wins
> max_standby_delay > X # Query wins until lag > X.
>
> As Tom points out, the 3rd option has all sorts of problems. I very much
> like the
On 05/05/10 22:13, Srinivas Naik wrote:
Hi Mark,
I took the output of the Postgresql. Please find the output:
Package: postgresql-8.3
State: installed
Automatically installed: no
Version: 8.3.9-0ubuntu8.10
Ok - your bug is fixed in 8.3.10. This should make its way to your
Ubuntu apt reposi
Simon Riggs wrote:
I've refrained from comment on max_standby_delay because I have
neither read the patch nor am likely to be an early adopter of HS;
however, as a potential eventual user I have to say that the
semantics for this GUC proposed by Simon seem sane and useful to me.
Certainly the d
On Wed, 2010-05-05 at 06:23 -0400, Robert Haas wrote:
> On Wed, May 5, 2010 at 3:16 AM, Simon Riggs wrote:
> > Expect at least 3 commits from me over next few days.
>
> I think you need to rethink the way that you decide when it's time to
> commit things. There is certainly no consensus on any o
On Wed, 2010-05-05 at 16:46 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > The attached patch redefines "standby delay" to be the amount of time
> > elapsed from point of receipt to point of application. The "point of
> > receipt" is reset every chunk of data when streaming, or every fil
On Wed, 2010-05-05 at 16:58 +0300, Heikki Linnakangas wrote:
> Let's have a setting similar to
> statement_timeout, that specifies how long a statement is allowed to
> run until it becomes subject to killing if it conflicts with recovery
> (actually, it would have to be a per-transaction setting, a
On 2010-05-03 23:09, Bruce Momjian wrote:
Robert Haas wrote:
On Sun, May 2, 2010 at 3:45 PM, Dimitri Fontaine wrote:
Now you tell me how awful this idea really is :)
I'm not sure I can count that high. :-)
While I can't improve on Robert's reply, I can supply a PDF a
Hello
attached patch contains to_string and to_array functions. These
functions are equivalent of array_to_string and string_to_array
function with maybe more correct NULL handling.
postgres=# select to_array('1,2,3,4,,6',',');
to_array
--
{1,2,3,4,NULL,6}
(1 row)
postgres=
So what was the conclusion here? Is pg_migrator going to be in contrib
for beta2 or 3, after cleaning it up?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Wed, May 5, 2010 at 12:30 PM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> Does my proposal (upthread) to limit this by quantity of WAL rather
>> than time have any legs, or is that impractical and/or otherwise poor?
>
> That would certainly be easier to implement sanely than a time-based
The core team has agreed that the data-corruption bug fixed here
http://archives.postgresql.org/pgsql-committers/2010-05/msg00016.php
is serious enough to justify a prompt update release. Although that
bug only affects 8.4 and HEAD, we have some other significant bug fixes
pending in the older bac
Robert Haas wrote:
> Does my proposal (upthread) to limit this by quantity of WAL rather
> than time have any legs, or is that impractical and/or otherwise poor?
That would certainly be easier to implement sanely than a time-based
quantity. One problem is that we don't know how much unapplied WAL
On Wed, May 5, 2010 at 9:58 AM, Heikki Linnakangas
wrote:
> Tom Lane wrote:
>> Comments?
>
> There's currently three ways to set max_standby_delay:
>
> max_standby_delay = -1 # Query wins
> max_standby_delay = 0 # Recovery wins
> max_standby_delay > X # Query wins until lag > X.
>
> As Tom po
Heikki Linnakangas writes:
> To accomplish what you're trying to accomplish, you would need to label
> each received WAL record with the timestamp when it was received, and
> compare the reception timestamp of the record you're applying against
> current timestamp.
Yeah, this is why I thought tha
Simon Riggs wrote:
> I am mostly unavailable for next few days. (Repairing bikeshed.)
Hey, you're supposed to do the bikeshedding on-list! ;-)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Heikki Linnakangas writes:
> Tom Lane wrote:
>> Comments?
>
> There's currently three ways to set max_standby_delay:
>
> max_standby_delay = -1# Query wins
> max_standby_delay = 0 # Recovery wins
> max_standby_delay > X # Query wins until lag > X.
>
> As Tom points out, the 3rd option has
Hi,
I saw this behavior with latest GIT head:
create table xlarge(val numeric(19,0));
insert into xlarge values(generate_series(1,5));
The above generate series will return an int8 which will then be
casted to numeric (via int8_to_numericvar) before being inserted into
the table. I observed that
Tom Lane wrote:
> Comments?
There's currently three ways to set max_standby_delay:
max_standby_delay = -1 # Query wins
max_standby_delay = 0 # Recovery wins
max_standby_delay > X # Query wins until lag > X.
As Tom points out, the 3rd option has all sorts of problems. I very much
like the be
Simon Riggs wrote:
> The attached patch redefines "standby delay" to be the amount of time
> elapsed from point of receipt to point of application. The "point of
> receipt" is reset every chunk of data when streaming, or every file when
> reading file by file. In all cases this new time is later th
Alex Hunsaker wrote:
On Mon, May 3, 2010 at 14:04, Andrew Dunstan wrote:
[ Awesome work getting buildfarm support for git ]
Note, this is running from my test git repo, not the community's repo.
BTW +1 for gitting (heh, git puns are fun) a good git repo published.
Ive giv
On Wed, May 5, 2010 at 3:16 AM, Simon Riggs wrote:
> Expect at least 3 commits from me over next few days.
I think you need to rethink the way that you decide when it's time to
commit things. There is certainly no consensus on any of the things
you are proposing to commit, nor have they been ade
Hi Mark,
I took the output of the Postgresql. Please find the output:
Package: postgresql-8.3
State: installed
Automatically installed: no
Version: 8.3.9-0ubuntu8.10
Priority: optional
Section: misc
Maintainer: Martin Pitt
Uncompressed Size: 14.2M
Depends: libc6 (>= 2.4), libcomerr2 (>= 1.01),
On Tue, 2010-05-04 at 23:06 -0400, Bruce Momjian wrote:
> Should I be concerned that we are redesigning HS features at this stage
> in the release?
We knew we had to have one final discussion on HS snapshots. This is it.
Tom has raised valid issues, all of which already known. If we can
address
57 matches
Mail list logo
