2010/2/13 Tom Lane :
> Hitoshi Harada writes:
>> [ more_frame_options patch ]
>
> Committed after rather extensive revisions.
Thanks a lot.
> I'm not terribly happy with the changes you made in WinGetFuncArgInPartition
> and WinGetFuncArgInFrame to force the window function mark to not go
> past
On Fri, Feb 12, 2010 at 19:14, Robert Haas wrote:
> Sounds like it would considerably simplify
> the patch, too.
I overstated that. The way its done now we could just change the
decelerations to 'my' and drop an if block. Id be in favor of more or
less keeping the internals as implemented in th
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan wrote:
>r
>
> Alex Hunsaker wrote:
>>
>> Yes it could allow people who
>> can set the plperl.*_init functions to muck with the safe.
>
> It's quite easy to subvert Safe.pm today, sadly. ...
If anything that sounds like an argument for it =)
> But th
On Fri, Feb 12, 2010 at 10:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane wrote:
>>> Robert Haas writes:
This is a bit ugly, but one idea that occurs to me is to change
amopstrategy from int16 to int32. Internally, we'll treat the low 16
>>>
Robert Haas writes:
> On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> This is a bit ugly, but one idea that occurs to me is to change
>>> amopstrategy from int16 to int32. Internally, we'll treat the low 16
>>> bits as the strategy number and the high 16 bits as the
On Fri, Feb 12, 2010 at 10:10 PM, Tom Lane wrote:
> Robert Haas writes:
>> OK, here's another idea. Let's just add a new column to pg_amop
>> called amoporderstrategy. If an operator can only be used for one
>> purpose or the other, we'll set the other value to -1.
>
> ... problem for unique in
Robert Haas writes:
> OK, here's another idea. Let's just add a new column to pg_amop
> called amoporderstrategy. If an operator can only be used for one
> purpose or the other, we'll set the other value to -1.
... problem for unique index, no?
regards, tom lane
--
Se
On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane wrote:
> Robert Haas writes:
>>> Well, if you were willing to change pg_amop so that the key was
>>> (amopfamily, amoplefttype, amoprighttype, amopcategory) rather than
>>> just (amopfamily, amoplefttype, amoprighttype), the issue of what to
>>> do if an
Robert Haas writes:
>> Well, if you were willing to change pg_amop so that the key was
>> (amopfamily, amoplefttype, amoprighttype, amopcategory) rather than
>> just (amopfamily, amoplefttype, amoprighttype), the issue of what to
>> do if an operator can be in more than one category becomes moot.
On Fri, Feb 12, 2010 at 9:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman wrote:
>>> Revised patch is attached (4th edition).
>
>> This looks generally sane to me, though it seems entirely imaginable
>> that it might break something, somewhere, for
Robert Haas writes:
> On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman wrote:
>> Revised patch is attached (4th edition).
> This looks generally sane to me, though it seems entirely imaginable
> that it might break something, somewhere, for somebody... in which
> case I suppose we'll adjust as nee
Robert Haas writes:
> On Fri, Feb 12, 2010 at 8:06 PM, Tom Lane wrote:
>> We could possibly put in some hack to disallow OLD/NEW references in
>> the WITH queries, but that got past my threshold of ugliness, so
>> I'm not going to commit it without further discussion.
> On the face of it it's no
On Fri, Feb 12, 2010 at 9:10 PM, Robert Haas wrote:
> On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane wrote:
>> Maybe a more general idea would be to invent "categories" of opclass
>> members, where the only existing category is "index search qualifier",
>> and these new knngist thingies are another, a
On Fri, Feb 12, 2010 at 3:42 PM, Andrew Dunstan wrote:
> I'm a bit inclined to commit the piece of this patch that concerns the
> warnings pragma, and leave the rest for the next release,
Based on the subsequent discussion on this thread, +1 for this
approach. Allowing use warnings sounds good;
On Fri, Feb 12, 2010 at 8:06 PM, Tom Lane wrote:
> Marko Tiikkaja writes:
>>> Here's the patch. It's the same as the stuff in writeable CTE patches,
>>> but I added regression tests.
>
>> Whoops. The reference section in docs still had some traces of writeable
>> CTEs. Updated patch attached.
On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane wrote:
> Maybe a more general idea would be to invent "categories" of opclass
> members, where the only existing category is "index search qualifier",
> and these new knngist thingies are another, and maybe plus and minus for
> window function ranges are a
On Fri, Feb 12, 2010 at 17:57, Andrew Dunstan wrote:
> Another objection is that discussion on this facility has been pretty scant.
> I think that's putting it mildly.
Well I can certainly attest to that seeing as how I spotted it purely
by review...
--
Sent via pgsql-hackers mailing list (pgsq
>Andrew McNamara writes:
The solution is to write the query in an unambiguous way:
SELECT $1::date + 1;
>
>> You are missing the point: this is not about what types the SQL execution
>> sees. It is about making sure the correct recv function is applied to
>> the binary parameter data.
>
Marko Tiikkaja writes:
>> Here's the patch. It's the same as the stuff in writeable CTE patches,
>> but I added regression tests.
> Whoops. The reference section in docs still had some traces of writeable
> CTEs. Updated patch attached.
I spent some time playing with this but concluded that i
Alex Hunsaker wrote:
Yes it could allow people who
can set the plperl.*_init functions to muck with the safe. As an
admin I could also do that by setting plperl.on_init and overloading
subs in the Safe namespace or switching out Safe.pm.
It's quite easy to subvert Safe.pm today, sadly.
Robert Haas writes:
> Tom remarked in another email that he wasn't too happy with the
> opclass changes. They seem kind of grotty to me, too, but I don't
> immediately have a better idea. My fear is that there may be places
> in the code that rely on opclass operators only ever returning bool,
>
On Fri, Feb 12, 2010 at 02:30:37PM -0700, Alex Hunsaker wrote:
> On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan wrote:
> > Alex Hunsaker wrote:
>
> > and leave the rest for the next release, unless you can
> > convince me real fast that we're not opening a back door here. If we're
> > going to
Robert Haas wrote:
> On Thu, Feb 11, 2010 at 5:47 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >> > Jaime Casanova wrote:
> >> >> i like this with or without the (), but maybe we are breaking client
> >> >> apps if change that
> >>
> >> > Ah, so you like FUNCTION.
> >
On Fri, Feb 12, 2010 at 11:10:15PM +, Tim Bunce wrote:
> I've appended the POD documentation and attached the (rough but working)
> test script.
Oops. Here's the test script.
Tim.
create or replace function test_call() returns text language plperlu as $func$
use lib "/Users/timbo/pg/Postgre
There was some discussion a few weeks ago about inter-stored-procedure
calling from PL/Perl.
I thought I'd post the documentation (and tests) for a module I'm
working on to simplify calling SQL functions from PL/Perl.
Here are some real-world examples (not the best code, but genuine
use-cases):
Jeff Davis writes:
> On Fri, 2010-02-12 at 16:59 -0500, Tom Lane wrote:
>> AFAICT there isn't any actual use case for this because you can't
>> reference the WITH clause from the body of VALUES:
> with tmp2 as (select a + 1 as b from tmp)
> values((select b from tmp2));
Ah, sneaky. Never
On Fri, 2010-02-12 at 10:38 +0100, Federico Di Gregorio wrote:
> On 12/02/2010 01:00, Jeff Davis wrote:
> > * I tried installing psycopg2-2.0.13 and the build system apparently
> > doesn't support python3.1, so I assume that psycopg2 doesn't support
> > python3 at all.
>
> python3 was almost compl
On Fri, 2010-02-12 at 16:59 -0500, Tom Lane wrote:
> Came across something interesting while looking at Marko Tiikkaja's
> cut-down WITH patch. I see that our grammar allows a WITH clause in
> front of VALUES, and analyze.c makes some effort to process it, but
> AFAICT there isn't any actual use c
And a patch for the code implementing this
*** doc/src/sgml/func.sgml.org Tue Feb 2 12:53:59 2010
--- doc/src/sgml/func.sgml Fri Feb 12 21:49:01 2010
***
*** 1,4
!
Functions and Operators
--- 1,4
!
Functions and Operators
***
*** 821,827
Came across something interesting while looking at Marko Tiikkaja's
cut-down WITH patch. I see that our grammar allows a WITH clause in
front of VALUES, and analyze.c makes some effort to process it, but
AFAICT there isn't any actual use case for this because you can't
reference the WITH clause fr
And here is the patch.
*** doc/src/sgml/func.sgml.org Tue Feb 2 12:53:59 2010
--- doc/src/sgml/func.sgml Fri Feb 12 21:49:01 2010
***
*** 1,4
!
Functions and Operators
--- 1,4
!
Functions and Operators
***
*** 821,827
Hi all,
I've combined the review suggestions of Jan Urbański, Scott Bailey, and
others.
This was a lot harder, then I had foreseen; and I took my time to do it
the right way (hope you agree!).
BTW. really appreciate your efforts, so far, to enlighten me on nuub
errors/mistakes in the previous v
On Fri, Feb 12, 2010 at 13:42, Andrew Dunstan wrote:
>
>
> Alex Hunsaker wrote:
in plc_safe_ok.pl
+use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
...the *_init gucs to be able to stick things into
@ShareIntoSafe and friends?
>
> I'm not sure it's fine wit
On Fri, Feb 12, 2010 at 3:44 PM, Oleg Bartunov wrote:
> We tried to find compromise for 9.0 (Tom suggests contrib module), but all
> variants are ugly and bring incompatibility in future. If there are no
> hackers
> willing/capable to review our patches, then, please, help us how to save
> neigh
On Fri, Feb 12, 2010 at 3:44 PM, Oleg Bartunov wrote:
> This is not fair,Robert. Everything was discussed in -hackers.I assume
> reviewer
> should follow discussion at least, he is a member of our community. Mailing
> list archive was/is/will our the best knowledge base.
Dude, there's no fair or
On Fri, 12 Feb 2010, Robert Haas wrote:
2010/2/11 Oleg Bartunov :
> On Thu, 11 Feb 2010, Robert Haas wrote:
>
>> On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov wrote:
version I saw hadn't any documentation whatever. =A0It's not committab=
le
on documentation grounds alone, even i
Alex Hunsaker wrote:
in plc_safe_ok.pl
+use vars qw($PLContainer $SafeClass @EvalInSafe @ShareIntoSafe);
Is there some reason not to use my here? The only reason I can think
of is you want the *_init gucs to be able to stick things into
@ShareIntoSafe and friends? And if so should we documen
On Fri, Feb 12, 2010 at 1:55 PM, Boszormenyi Zoltan wrote:
> Okay, new patch is attached. Please read the docs changes, and comment.
I like it. I'll mark it as Ready for Committer.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
I wrote:
> [off-list to avoid distracting from the 9.0 wrap-up effort]
Arg. I really didn't mean that to go to the list. :-(
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[off-list to avoid distracting from the 9.0 wrap-up effort]
Markus Wanner wrote:
> Quoting "Kevin Grittner" :
>> I strongly encourage you to set that up on git.postgresql.org.
>
> I'm about to provide git repositories for Postgres-R anyway, so
> I've setup two projects on git.postgres-r.org:
>
Heikki Linnakangas writes:
> Robert Haas wrote:
>> Furthermore, if you're wanting to use pg_standby, you might be
>> forgiven for thinking that you should set standby_mode = on; but in
>> fact that's exactly the wrong thing to do.
>
> Yeah, I think that's the main weakness of the name "standby_mod
On 12/02/10 15:37, Fujii Masao wrote:
On Sat, Feb 13, 2010 at 12:28 AM, Robert Haas wrote:
Well, let's come up with something else then.
continuous_recovery ?
One problem with the otherwise entirely wonderful HS/SR pairing is the
whole business of the config parameters. They feel too botto
Christopher Browne wrote:
> There are no notable compiler complaints about
> src/backend/slony_funcs.c, so the mismatch must be at a subtler level
> than that of an up-front API change for something.
>
> I suppose a next step might be to kick off gdb against the backend when
> processing this.
Y
Robert Haas írta:
> On Fri, Feb 12, 2010 at 1:22 PM, Boszormenyi Zoltan wrote:
>
>> Robert Haas írta:
>>
>>> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan
>>> wrote:
>>>
>>>
I added a small change to protocol.sgml for the
"CommandComplete" message describing the c
On Fri, Feb 12, 2010 at 1:22 PM, Boszormenyi Zoltan wrote:
> Robert Haas írta:
>> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan
>> wrote:
>>
>>> I added a small change to protocol.sgml for the
>>> "CommandComplete" message describing the change.
>>> Is it enough?
>>>
>>
>> Ah, I didn't ev
Something has evidently changed of late (not quite sure when) which
causes the Slony-I log triggers to break when working against PostreSQL
HEAD.
A more-or-less simplest case is demonstrated thus:
ch...@dba2:/mnt/PostgreSQL/dbs> psql slonyregress1
Line style is ascii.
psql (8.5devel)
Type "help"
Robert Haas írta:
> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan wrote:
>
>> I added a small change to protocol.sgml for the
>> "CommandComplete" message describing the change.
>> Is it enough?
>>
>
> Ah, I didn't even see that that section needed to be updated. Good
> catch. I'd
On Fri, 2010-02-12 at 10:22 -0800, Josh Berkus wrote:
> Heikki,
>
> Crossing this thread over to pgsql-docs, where I think it actually belongs.
>
> In addition to the changes you've proposed, one thing our docs could
> really use is a single reference page which we could go to for all of
> the .c
Heikki,
Crossing this thread over to pgsql-docs, where I think it actually belongs.
In addition to the changes you've proposed, one thing our docs could
really use is a single reference page which we could go to for all of
the .conf files. Right now, you need to rely on postgresql.org doc
search
Robert Haas írta:
> On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan wrote:
>
>> I added a small change to protocol.sgml for the
>> "CommandComplete" message describing the change.
>> Is it enough?
>>
>
> Ah, I didn't even see that that section needed to be updated. Good
> catch. I'd
2010/2/11 Oleg Bartunov :
> On Thu, 11 Feb 2010, Robert Haas wrote:
>
>> On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov wrote:
version I saw hadn't any documentation whatever. It's not committable
on documentation grounds alone, even if everybody was satisfied about
the code.
On 2/12/10 1:14 AM, Heikki Linnakangas wrote:
> It's pretty clear that we should have a single place that documents all
> the recovery.conf options. I suggest that we move the "24.3.3.1 Recovery
> Settings" section after "High Availability, Load Balancing, and
> Replication", and add the new strea
so I from by like having the server doing the cleanup because it down by
necessarily have the while picture. it down nt know of it is the only
replica reading these log files our if the site policy is to keep them for
disaster recovery purposes.
I like having this as an return val command though.
Hitoshi Harada writes:
> [ more_frame_options patch ]
Committed after rather extensive revisions.
I removed the RANGE value PRECEDING/FOLLOWING support as per discussion,
which was probably a good thing anyway from an incremental-development
standpoint; it made it easier to see what was going on
On Fri, Feb 12, 2010 at 10:48 AM, Boszormenyi Zoltan wrote:
> I added a small change to protocol.sgml for the
> "CommandComplete" message describing the change.
> Is it enough?
Ah, I didn't even see that that section needed to be updated. Good
catch. I'd suggest the following wording:
For a SE
Simon Riggs writes:
> Attached patch implements pg_standby for use as an
> archive_cleanup_command, reusing existing code with new -a option.
>
> Happy to add the archive_cleanup_command into main server as well, if
> you like. Won't take long.
Would it be possible to have the server do the clean
Marko Kreen escreveu:
> 3) Support all 3 parameters (keepidle, keepintvl, keepcnt)
> and ignore parameters not supported by OS.
>
+1. AFAIR, we already do that for the backend.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Alvaro Herrera writes:
> Tom Lane escribió:
>> Yeah, I don't immediately see anything that would justify going to
>> that level of effort. Adding +/- as support functions for btree
>> seems like the thing to do.
> Would it work to use a fake access method instead?
Then you'd have to duplicate a
Fujii Masao wrote:
> On Fri, Feb 12, 2010 at 10:10 PM, Heikki Linnakangas
> wrote:
>>> So I suggest that you have a new action that gets called after every
>>> checkpoint to clear down the archive. It will remove all files from the
>>> archive prior to %r. We can implement that as a sequence of un
On 2/11/10, Tollef Fog Heen wrote:
> | I disagree. I have clients who have problems with leftover client
> connections
> | due to server host failures. They do not write apps in C. For a non-default
> | change to be effective we would need to have all the client drivers, eg
> JDBC,
> | psyco
Tom Lane escribió:
> Dimitri Fontaine writes:
> > Searching the archives ain't helping me refresh those memories. So it
> > seems the case for an extended opclass infrastructure, or a new side
> > one, is between thin an non-existent yet?
>
> Yeah, I don't immediately see anything that would just
On Wed, Feb 10, 2010 at 9:27 PM, Andres Freund wrote:
> On Monday 08 February 2010 05:53:23 Robert Haas wrote:
>> On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
>>
>> wrote:
>> > Andres Freund escribió:
>> >> I personally think the fsync on the directory should be added to the
>> >> stable branc
Robert Haas írta:
> On Mon, Feb 8, 2010 at 5:53 AM, Boszormenyi Zoltan wrote:
>
>> New patch is attached with the discussed changes.
>>
>
> This looks OK to me now, but it lacks docs.
>
> I'll set it to Waiting on Author.
>
> ...Robert
>
I added a small change to protocol.sgml for the
On Fri, Feb 12, 2010 at 10:10 PM, Heikki Linnakangas
wrote:
>> So I suggest that you have a new action that gets called after every
>> checkpoint to clear down the archive. It will remove all files from the
>> archive prior to %r. We can implement that as a sequence of unlink()s
>> from within the
On Sat, Feb 13, 2010 at 12:28 AM, Robert Haas wrote:
> Well, let's come up with something else then.
continuous_recovery ?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On tor, 2010-02-11 at 14:13 +0100, Bart Samwel wrote:
> I've been working on a patch to add hostname support to pg_hba.conf.
> It's not ready for public display yet, but I would just like to run a
> couple of issues / discussion points past everybody.
It might be good to review Apache's hostname-b
On Fri, Feb 12, 2010 at 10:27 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> Furthermore, if you're wanting to use pg_standby, you might be
>> forgiven for thinking that you should set standby_mode = on; but in
>> fact that's exactly the wrong thing to do.
>
> Yeah, I think that's the main
Robert Haas wrote:
> Furthermore, if you're wanting to use pg_standby, you might be
> forgiven for thinking that you should set standby_mode = on; but in
> fact that's exactly the wrong thing to do.
Yeah, I think that's the main weakness of the name "standby_mode". It's
pretty descriptive otherwis
On Fri, Feb 12, 2010 at 8:56 AM, Andrew Dunstan wrote:
> There is documentation in Tim's patch I am working on right now. I don't
> think anything else is needed.
Cool.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Fri, Feb 12, 2010 at 5:40 AM, Tim Bunce wrote:
> What happens to patches marked 'ready for committer' after the
> commitfest ends?
We talk about it and figure out what to do. It'll be some combination
of (1) last-minute commits, (2) postponing things to 9.1, and (3)
rejecting things we don't
On Fri, Feb 12, 2010 at 9:55 AM, Heikki Linnakangas
wrote:
> That doesn't accurately describe what the standby_mode setting does. It
> doesn't imply streaming replication. It means that the server doesn't
> end recovery when it reaches end of WAL, but keeps trying.
I think I'm going to add my nam
Simon Riggs wrote:
> * "entering standby mode" isn't a more informative message. Two people
> have already said on-list that "standby mode" name might need to be
> changed.
Well, I'm all ears for better suggestions.
> More informative, for me, would be something like "entering
> streaming replica
Heikki Linnakangas writes:
> Joachim Wieland wrote:
>> If no primary_conninfo variable is set explicitly in the configuration
>> file, check the environment variables. If the environment variable is
>> not set, don't try to establish a connection.
> The environment variables in question are the l
On Fri, 2010-02-12 at 09:49 +, Heikki Linnakangas wrote:
> Log Message:
> ---
> Reduce the chatter to the log when starting a standby server. Don't
> echo all the recovery.conf options. Don't emit the "initializing
> recovery connections" message, which doesn't mean anything to a user.
On Fri, 2010-02-12 at 12:54 +, Simon Riggs wrote:
> So I suggest that you have a new action that gets called after every
> checkpoint to clear down the archive. It will remove all files from the
> archive prior to %r. We can implement that as a sequence of unlink()s
> from within the server, o
Dimitri Fontaine writes:
> Searching the archives ain't helping me refresh those memories. So it
> seems the case for an extended opclass infrastructure, or a new side
> one, is between thin an non-existent yet?
Yeah, I don't immediately see anything that would justify going to
that level of effo
Andrew McNamara writes:
>>> The solution is to write the query in an unambiguous way:
>>> SELECT $1::date + 1;
> You are missing the point: this is not about what types the SQL execution
> sees. It is about making sure the correct recv function is applied to
> the binary parameter data.
Indeed,
Robert Haas wrote:
The discussion on this seems to have died off. Andrew, do you have
something you're planning to commit for this? I think we're kind of
down to the level of bikeshedding here...
There is documentation in Tim's patch I am working on right now. I don't
think anything e
Tim Bunce wrote:
That updated patch is in the commitfest
https://commitfest.postgresql.org/action/patch_view?id=271
>From talking to Andrew via IM I understand he's very busy, and also that
he'll be traveling on Sunday and Monday.
I certainly hope he can commit this patch today (along with th
Simon Riggs wrote:
> In 8.4 it is pg_standby that was responsible for clearing down the
> archive, which is why I suggested using pg_standby for that again. I
> agree that will not work. The important thing is not pg_standby but that
> we have a valid mechanism for clearing down the archive.
Good
On Fri, 2010-02-12 at 14:38 +0900, Fujii Masao wrote:
> On Thu, Feb 11, 2010 at 11:22 PM, Heikki Linnakangas
> wrote:
> > Simon Riggs wrote:
> >> Might it not be simpler to add a parameter onto pg_standby?
> >> We send %s to tell pg_standby the standby_mode of the server which is
> >> calling it s
On Fri, Feb 12, 2010 at 4:04 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
>> wrote:
>>> Fujii Masao wrote:
But if we fail in restoring the archived WAL file, "standby_mode = on"
*always* tries to start streaming replication.
>
On Fri, Feb 12, 2010 at 12:22:28AM -0500, Robert Haas wrote:
> On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan wrote:
> > Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>
> >>> %_SHARED has been around for several years now, and if there are genuine
> >>> security concerns about it ISTM they would
On Fri, Feb 12, 2010 at 7:15 PM, Heikki Linnakangas
wrote:
> That's actually a bit questionable, always has been even in pg_standby.
> It adds a constant 1 s delay to the recovery each WAL file, which
> effectively rate-limits the WAL recovery to 16MB per second. I think we
> should rather add a w
Fujii Masao wrote:
> We might need to add the following code of pg_standby into the core,
> to prefer it for many cases.
>
>> #ifdef WIN32
>>
>> /*
>> * Windows 'cp' sets the final file size before the
>> copy is
>> * complete, and
On Fri, Feb 12, 2010 at 6:40 PM, Peter Geoghegan
wrote:
>> keepalive doesn't work,
>> then it would have to wait for a long time until it detects
>> the outage.
>
> I'm not really sure what you mean. In this scenario, would it take as
> long as it would have taken had keepalives not been used?
Pl
Heikki Linnakangas writes:
> There's yet another mode that would be useful with hot standby: start up
> the standby, but don't poll the archive and don't try to connect to the
> master. Kind of 'paused' mode. Simon had functions to do that and more
> in the original hot standby patch.
And having
On Fri, Feb 12, 2010 at 6:14 PM, Heikki Linnakangas
wrote:
> So the new layout would be:
>
> III. Server Administration
>
> ...
> 21. Managing Databases
> 22. Localization
> 23. Routine Database Maintenance Tasks
> 24. Backup and Restore
> 25. High Availability, Load Balancing, a
Ok, I committed a patch to reduce the chatter a bit:
Fujii Masao wrote:
> On Fri, Feb 5, 2010 at 3:58 AM, Heikki Linnakangas
> wrote:
>>> LOG: starting archive recovery
>
> This is reported even if restore_command is not given and the WAL files are
> never restored from the archive. We should g
> wrote:
>> Why hasn't libpq had keepalives for years?
>
> I guess that it's because keepalive doesn't work as expected
> in some cases. For example, if the network outage happens
> before a client sends some packets, keepalive doesn't work,
> then it would have to wait for a long time until it de
On 12/02/2010 01:00, Jeff Davis wrote:
> * I tried installing psycopg2-2.0.13 and the build system apparently
> doesn't support python3.1, so I assume that psycopg2 doesn't support
> python3 at all.
python3 was almost completely supported some months ago but then I had
to fix some bugs and almost
Joachim Wieland wrote:
> On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
> wrote:
>> Agreed. I've changed it now so that if primary_conninfo is not set, it
>> doesn't try to establish a streaming connection. If you want to get the
>> connection information from environment variables, you can u
One glaring issue with the current documentation layout is that the
documentation for the various options in recovery.conf is split in two
places. The old options, restore_command, recovery_target_* and so forth
are in section "24.3.3.1 Recovery Settings", while the new streaming
replication relate
On Fri, Feb 12, 2010 at 8:59 AM, Heikki Linnakangas
wrote:
> Agreed. I've changed it now so that if primary_conninfo is not set, it
> doesn't try to establish a streaming connection. If you want to get the
> connection information from environment variables, you can use
> primary_conninfo=''.
Why
Hi,
A bit offtopic, but...
For who do not read Planet PostgreSQL: I am no longer working for
Command Prompt as of today:
http://people.planetpostgresql.org/devrim/index.php?/archives/33-Bye-bye-Command-Prompt..html
http://people.planetpostgresql.org/devrim/index.php?/archives/34-F.A.Q.-about-lat
On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas
wrote:
> Agreed. I've changed it now so that if primary_conninfo is not set, it
> doesn't try to establish a streaming connection. If you want to get the
> connection information from environment variables, you can use
> primary_conninfo=''.
OK,
Tom Lane writes:
>> I think there's the associativity property of operators that we might
>> want to have someday, in order for the planner to know some more about
>> joins on A = B then on B = C, or replace with < if you will.
>
> We already do know about that, at least in the case of =. The rea
On Fri, Feb 12, 2010 at 02:31, Mark Mielke wrote:
> But once there, it seems clear that packing hostnames or netmasks onto one
> line is just ugly and hard to manage. I'd like to see this extended to any
> of the many ways to allow hostnames to be specified one per line. For
> example:
>
> set t
98 matches
Mail list logo
