On Tue, Feb 8, 2011 at 00:30, Shigeru HANADA wrote:
> Fixed version is attached.
I reviewed your latest git version, that is a bit newer than the attached patch.
http://git.postgresql.org/gitweb?p=users/hanada/postgres.git;a=commit;h=0e1a1e1b0e168cb3d8ff4d637747d0ba8f7b8d55
The code still works
On Wed, 2011-02-16 at 11:25 +0900, Fujii Masao wrote:
> On Wed, Feb 16, 2011 at 6:15 AM, Simon Riggs wrote:
> > On Tue, 2011-02-15 at 12:15 -0500, Robert Haas wrote:
> >> Looks pretty good to me, though I haven't tested it. I like some of
> >> the safety valves you put in there, but I don't under
Stephen Frost writes:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> There is only bad keywords in doc - SCALE instead SLICE and a maybe a
>> usage of slicing need a example.
> Err, yeah, a couple of stupid documentation issues, sorry about that.
Applied with assorted cleanup. I left the
On Tue, Feb 15, 2011 at 9:41 PM, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 12:34 AM, Fujii Masao wrote:
>> You suggest that the shared variable Stream tracks the WAL write location,
>> after it's set to the replication starting position? I don't think
>> that the write
>> location needs to be
2011/2/16 Tom Lane :
> Andrew Dunstan writes:
>> On 02/15/2011 08:59 PM, Robert Haas wrote:
>>> Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
>>> cheap future-proofing to me. YMMV.
>
>> If this is the syntax that makes you do things like:
>> FOREACH foo IN ARRAY ARRAY
Andrew Dunstan writes:
> On 02/15/2011 08:59 PM, Robert Haas wrote:
>> Anyhoo, forcing the explicit ARRAY keyword in there seems like pretty
>> cheap future-proofing to me. YMMV.
> If this is the syntax that makes you do things like:
> FOREACH foo IN ARRAY ARRAY[1,2,3]
> I have to say I fin
On Wed, Feb 16, 2011 at 11:30 AM, Robert Haas wrote:
> Committed with minor tweaks to comments and documentation.
Thanks a lot!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On Tue, Feb 15, 2011 at 14:12, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 3:26 PM, marcin mank wrote:
>> how about : we use a single dash as the separator, and if the
>> extension author insists on having a dash in the name, as a punishment
>> he must duplicate the dash, i.e.:
>> uuid--ossp-1.0
On Mon, Feb 14, 2011 at 09:49, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Here's where I think we are with this CommitFest.
>
> Subject: Re: [HACKERS] CommitFest 2011-01 as of 2011-02-04
>
> I'm gonna go out on a limb and hope you meant '2011-02-14' there. :)
>
>> So t
On Wed, Feb 16, 2011 at 2:08 AM, Robert Haas wrote:
> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
>> wrote:
>>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
>>> sends a status update every time the WAL
On 02/15/2011 08:59 PM, Robert Haas wrote:
On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost wrote:
Alright, so, like I said, I really like this feature and would like to
see it included.
Amen to that!
I think the syntax To
On 16/02/11 15:59, Greg Stark wrote:
On Wed, Feb 16, 2011 at 2:43 AM, Mark Kirkwood
wrote:
What's this libbsd then eh? Sure enough it is this guy that defines these
symbols. So it is the way it is being built on the Ubuntu (or Debian)
platform.
Oh, for what it's worth there are several differ
Look at the libeditline-dev packages I think those might be more
modern than the libedit packages.
But I'm not sure myself, I don't really know the history, I just
remember being confused by it once in the past.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Wed, Feb 16, 2011 at 2:43 AM, Mark Kirkwood
wrote:
> What's this libbsd then eh? Sure enough it is this guy that defines these
> symbols. So it is the way it is being built on the Ubuntu (or Debian)
> platform.
Oh, for what it's worth there are several different libedits out there
with various
On 16/02/11 15:05, Mark Kirkwood wrote:
On 16/02/11 14:54, Tom Lane wrote:
It's pretty hard to see how those two things would be related. I think
more likely libedit is providing a function named setproctitle, which
seems like a rather stupid thing for them to have done.
You are correct - it
On Fri, Feb 11, 2011 at 8:35 AM, Stephen Frost wrote:
> Greg,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Greg Smith writes:
>> > Poking around a bit more, I just discovered another possible approach is
>> > to use erand48 instead of rand in pgbench, which is either provided by
>> > the OS or e
On Feb 15, 2011, at 5:18 PM, Tom Lane wrote:
> Currently, ALTER EXTENSION UPDATE throws an error if there's nothing to
> do:
>
> regression=# create extension adminpack ;
> CREATE EXTENSION
> regression=# alter extension adminpack update;
> ERROR: version to install or update to must be differen
On Tue, Feb 15, 2011 at 7:13 AM, Daniel Farina wrote:
> On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao wrote:
>> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina wrote:
>>> Context diff equivalent attached.
>>
>> Thanks for the patch!
>>
>> As I said before, the timeout which this patch provides do
On Sun, Feb 13, 2011 at 10:18 PM, Fujii Masao wrote:
> Thanks for the review!
>
> On Thu, Feb 10, 2011 at 11:25 PM, Magnus Hagander wrote:
>> I see that the docs part of the patch removes the mentioning of
>> reporting servers - is that intentional, or a mistake? Seems that
>> usecase still remai
On Wed, Feb 16, 2011 at 6:15 AM, Simon Riggs wrote:
> On Tue, 2011-02-15 at 12:15 -0500, Robert Haas wrote:
>> Looks pretty good to me, though I haven't tested it. I like some of
>> the safety valves you put in there, but I don't understand this part
>
> Reworked logic covering all feedback, plus
On Wed, Feb 16, 2011 at 02:14, Andrew Dunstan wrote:
>> I've been kind of wondering why you haven't already committed it. If
>> you're confident that the code is in good shape, I don't particularly
>> see any benefit to holding off.
>
> +10. The sooner the better.
Thanks comments. I've applied t
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane wrote:
> > Anyway I'm going to start on this patch next, so last chance for
> > opinions about the syntax ...
>
> Oh, I was looking at this one:
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01
On 16/02/11 14:54, Tom Lane wrote:
It's pretty hard to see how those two things would be related. I think
more likely libedit is providing a function named setproctitle, which
seems like a rather stupid thing for them to have done.
You are correct - it defines setproctitle, good grief.
--
Se
On Tue, Feb 15, 2011 at 7:10 PM, Tom Lane wrote:
> 1. We could just revert the pg_proc.h changes so that these two
> functions are still shown as taking only 2 arguments. Since GIN doesn't
> actually look at the signature claimed in pg_proc, this won't break
> anything functionally. It's pretty
On Tue, Feb 15, 2011 at 8:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost wrote:
>>> Alright, so, like I said, I really like this feature and would like to
>>> see it included.
>
>> Amen to that!
>
>> I think the syntax Tom suggested before was FOREA
Mark Kirkwood writes:
> Since libedit is getting some attention right now, I figured I'd try
> using building with it instead of readline. configuring using:
> ./configure --prefix=/usr/local/pgsql/9.1 --enable-debug
> --enable-cassert --with-libedit-preferred
> I get this linking postgres:
>
Since libedit is getting some attention right now, I figured I'd try
using building with it instead of readline. configuring using:
./configure --prefix=/usr/local/pgsql/9.1 --enable-debug
--enable-cassert --with-libedit-preferred
I get this linking postgres:
postmaster/postmaster.o: In func
Robert Haas writes:
> On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost wrote:
>> Alright, so, like I said, I really like this feature and would like to
>> see it included.
> Amen to that!
> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
> arr rather than just FOREACH thingy IN
Currently, ALTER EXTENSION UPDATE throws an error if there's nothing to
do:
regression=# create extension adminpack ;
CREATE EXTENSION
regression=# alter extension adminpack update;
ERROR: version to install or update to must be different from old version
On reflection it seems like this is over
> How is such a determination made, exactly?
It's Feb 15th, and portions of the patch need a rework according to the
author. I'm with Robert on this one.
--
-- Josh Berkus
PostgreSQL Experts Inc.
I've been experimenting with dump/reload of 9.0 contrib-using databases
into 9.1 and then applying CREATE EXTENSION FROM to update the contrib
modules to extension style. There are some cases that fail :-(. Most
of them are caused by the GIN extractQuery API changes. In particular,
a 9.0 dump in
Tom Lane wrote:
> I wrote:
> > I tried to do a pg_upgrade from 9.0.x to HEAD today. The pg_upgrade run
> > went through without complaint, and I could start the postmaster, but
> > every connection attempt fails with
>
> > psql: FATAL: could not read block 0 in file "base/11964/11683": read onl
On 15/02/11 20:39, Peter Eisentraut wrote:
> On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
>> Because the invocation that actually recurses sets up the scene for
>> failure.
>
> That's what we're observing, but I can't figure out why it is. If you
> can, could you explain it?
>
> It act
Excerpts from Tom Lane's message of mar feb 15 18:05:59 -0300 2011:
> Bruce Momjian writes:
> > Adjust pg_upgrade error message, array freeing, and add error check.
>
> The buildfarm says this patch is broken.
I have just pushed a fix for this. It's probably not the prettiest
thing in the world
--On 15. Februar 2011 18:52:04 +0100 Stefan Kaltenbrunner
wrote:
well I have not actually tested - I was just reading the changelog on
http://www.thrysoee.dk/editline/ which claims UTF8 "support" (whatever
that means) in the current code drop.
I tested it--enable-wc doesn't work as yo
On Tue, Feb 15, 2011 at 4:15 PM, Simon Riggs wrote:
> On Tue, 2011-02-15 at 12:15 -0500, Robert Haas wrote:
>> Looks pretty good to me, though I haven't tested it. I like some of
>> the safety valves you put in there, but I don't understand this part
>
> Reworked logic covering all feedback, plus
Dimitri Fontaine writes:
> Do we want to add such a query in the docs to help pgfoundry authors to
> write their own 'from unpackaged' scripts?
[ scratches head ... ] Why is your version generating so many
unnecessary @extschema@ uses?
regards, tom lane
--
Sent via pgs
On 15 February 2011 21:47, Tom Lane wrote:
> Also, so far as I can see array_cat *is* ||, so I'm not sure what
> discrepancy in behavior you're on about.
You've confused me now. I had a case where I replaced || with , and
surrounded it with array_cat, and the result differed, and now I can't
rec
On 02/15/2011 04:49 PM, Dimitri Fontaine wrote:
Ah well sed makes it simpler to read, but it won't be usable in windows.
You can make perl do the same stuff (and perl has psed anyway), and perl
is required for MSVC builds.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-h
On 15 February 2011 21:46, Cédric Villemain
wrote:
> 2011/2/15 Thom Brown :
>> Hi all,
>>
>> I assumed array_cat would behave similarly to array || array, but it
>> appears not when it comes to NULLs. Shouldn't these have identical
>> functionality? The attached patch makes it so, although it wo
Tom Lane writes:
> Just for the archives' sake: the '@extschema@' business did turn out to
> be important, at least for tsearch2 where it's necessary to distinguish
> the objects it's dealing with from similarly-named objects in
> pg_catalog. So this is what I used to generate the "unpackaged"
>
Thom Brown writes:
> I assumed array_cat would behave similarly to array || array, but it
> appears not when it comes to NULLs. Shouldn't these have identical
> functionality? The attached patch makes it so, although it would
> break existing code.
That patch is the hard way: the right change w
2011/2/15 Thom Brown :
> Hi all,
>
> I assumed array_cat would behave similarly to array || array, but it
> appears not when it comes to NULLs. Shouldn't these have identical
> functionality? The attached patch makes it so, although it would
> break existing code.
There is bugreport and todo ent
Hi all,
I assumed array_cat would behave similarly to array || array, but it
appears not when it comes to NULLs. Shouldn't these have identical
functionality? The attached patch makes it so, although it would
break existing code.
Would such a change have any knock-on effect, or cause inconsiste
Excerpts from Robert Haas's message of mar feb 15 18:15:38 -0300 2011:
> I am thinking that the statute of limitations has expired on this
> patch, and that we should mark it Returned with Feedback and continue
> working on it for 9.2. I know it's a valuable feature, but I think
> we're out of ti
On Feb 15, 2011, at 1:15 PM, Robert Haas wrote:
>> Yeah, that bug is fixed with the attached, though I am rethinking this
>> bit.
>
> I am thinking that the statute of limitations has expired on this
> patch, and that we should mark it Returned with Feedback and continue
> working on it for 9.2.
On Tue, 2011-02-15 at 12:15 -0500, Robert Haas wrote:
> Looks pretty good to me, though I haven't tested it. I like some of
> the safety valves you put in there, but I don't understand this part
Reworked logic covering all feedback, plus tests, plus docs.
Last comments before commit please.
--
On Mon, Feb 14, 2011 at 6:49 PM, Alvaro Herrera
wrote:
> Excerpts from Marti Raudsepp's message of lun feb 14 19:39:25 -0300 2011:
>> On Fri, Feb 11, 2011 at 09:13, Noah Misch wrote:
>> > The patch had a trivial conflict in planner.c, plus plenty of offsets.
>> > I've
>> > attached the rebased
On Tue, Feb 15, 2011 at 3:26 PM, marcin mank wrote:
> On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut wrote:
>> On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
>>> I guess the real question is what's Peter's concrete objection to the
>>> double-dash method?
>>
>> It just looks a bit silly an
Heikki Linnakangas writes:
> On 15.02.2011 21:13, Tom Lane wrote:
>> Hmm. I don't have a problem with adding relkind to the planner's
>> RelOptInfo, but it seems to me that if parse analysis needs to know
>> this, you have put functionality into parse analysis that does not
>> belong there.
> Po
On 15.02.2011 21:00, Robert Haas wrote:
On Tue, Feb 15, 2011 at 1:40 PM, Heikki Linnakangas
wrote:
I'm actually surprised we don't need to distinguish them in more places, but
nevertheless it feels like we should have that info available more
conveniently, and without requiring a catalog looku
On 15.02.2011 21:13, Tom Lane wrote:
Heikki Linnakangas writes:
As the patch stands, we have to do get_rel_relkind() in a couple of
places in parse analysis and the planner to distinguish a foreign table
from a regular one. As the patch stands, there's nothing in
RangeTblEntry (which is what we
On Feb 15, 2011, at 12:32 PM, Tom Lane wrote:
> Aside from the double-dash method, we kicked around using colons and
> pluses as separators (and then forbidding just those characters in
> extension and version names). Any of those would be workable, but it's
> not clear to me that any of them hav
Peter Eisentraut writes:
> On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
>> I guess the real question is what's Peter's concrete objection to the
>> double-dash method?
> It just looks a bit silly and error prone. And other packaging systems
> have been doing without it for decades.
I can
On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut wrote:
> On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
>> I guess the real question is what's Peter's concrete objection to the
>> double-dash method?
>
> It just looks a bit silly and error prone. And other packaging systems
> have been doin
Peter Eisentraut writes:
> On mån, 2011-02-14 at 15:08 -0500, Tom Lane wrote:
>> Umm ... we are not requiring version names to be numbers.
> That's certainly interesting. Why?
There isn't any packaging system anywhere on the planet that requires
them to be purely numeric. By the time you get
On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
> I guess the real question is what's Peter's concrete objection to the
> double-dash method?
It just looks a bit silly and error prone. And other packaging systems
have been doing without it for decades.
--
Sent via pgsql-hackers mailing list
On mån, 2011-02-14 at 15:08 -0500, Tom Lane wrote:
> Umm ... we are not requiring version names to be numbers.
That's certainly interesting. Why?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
> -Original Message-
> From: Robert Haas [mailto:robertmh...@gmail.com]
> Sent: 15 February 2011 16:52
> To: Tom Lane
> Cc: Andrew Dunstan; Kohei Kaigai; Stephen Frost; KaiGai Kohei; PgHacker
> Subject: Re: [HACKERS] sepgsql contrib module
>
> On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane w
On tis, 2011-02-15 at 09:58 +0100, Jan Urbański wrote:
> Because the invocation that actually recurses sets up the scene for
> failure.
That's what we're observing, but I can't figure out why it is. If you
can, could you explain it?
It actually makes sense to me that the arguments should be dele
Heikki Linnakangas writes:
> As the patch stands, we have to do get_rel_relkind() in a couple of
> places in parse analysis and the planner to distinguish a foreign table
> from a regular one. As the patch stands, there's nothing in
> RangeTblEntry (which is what we have in transformLockingClau
On Tue, Feb 15, 2011 at 1:40 PM, Heikki Linnakangas
wrote:
> I'm actually surprised we don't need to distinguish them in more places, but
> nevertheless it feels like we should have that info available more
> conveniently, and without requiring a catalog lookup like get_rel_relkind()
> does. At fi
I wrote:
> Dimitri Fontaine writes:
>> I think you'd be interested into this reworked SQL query. It should be
>> providing exactly the script file you need as an upgrade from unpackaged.
> This seems overly complicated. I have a version of it that I'll publish
> as soon as I've tested it on all
* Andrew Dunstan (and...@dunslane.net) wrote:
> On 02/15/2011 11:13 AM, Stephen Frost wrote:
> >Think I suggested that at one point. I'm all for doing that on a major
> >version change like this one, but I think we already had some concerns
> >about that on this thread (Andrew maybe?).
>
> I coul
On Tue, 2011-02-15 at 12:20 -0500, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 12:15 PM, Robert Haas wrote:
> > On another disk, I think that those warning messages are a bad idea.
> > That could fill up someone's disk really quickly.
>
> On another disk? What the heck am I talking about?
>
>
On Feb 15, 2011, at 9:49 AM, Alexey Klyukin wrote:
>>> After I re-added the closing in plperl.sgml:235 these errors
>>> disappeared, and the
>>> resulting html looks fine too. v10 with just this single change is attached.
>>
>> So is this ready for committer?
>
> Yes.
Awesom, thanks Alexey &
On 02/15/2011 12:37 PM, Greg Stark wrote:
On Tue, Feb 15, 2011 at 6:12 AM, Stefan Kaltenbrunner
wrote:
from what I can see upstream libedit actually has utf8 support for a while
now (as well as some other fixes) but the debian libedit version (and also
the one of other distributions) is way to
Gurjeet Singh writes:
> On Tue, Feb 15, 2011 at 8:24 AM, Heikki Linnakangas <
> heikki.linnakan...@enterprisedb.com> wrote:
>> On 11.02.2011 22:44, Gurjeet Singh wrote:
>>> One one hand get_actual_variable_range() expects that virtual indexes do
>>> not
>>> have an OID assigned, on the other hand
On Sun, Feb 13, 2011 at 7:52 AM, Peter Eisentraut wrote:
> psql -l doesn't process psqlrc. Historically, this was probably not
> useful, hence no one cared. But with the linestyle option it's useful.
> So I propose the attached tweak.
As a violent hater of the new linestyle, +1 from me.
--
Ro
On Feb 15, 2011, at 7:45 PM, David E. Wheeler wrote:
> On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
>
>> After I re-added the closing in plperl.sgml:235 these errors
>> disappeared, and the
>> resulting html looks fine too. v10 with just this single change is attached.
>
> So is this re
On Feb 15, 2011, at 6:39 AM, Alexey Klyukin wrote:
> After I re-added the closing in plperl.sgml:235 these errors
> disappeared, and the
> resulting html looks fine too. v10 with just this single change is attached.
So is this ready for committer?
Best,
David
--
Sent via pgsql-hackers mail
Tom Lane writes:
> Sure I did: \dx+
And I believe I did test that. Sorry for the noise, really. (shame)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On Mon, Feb 14, 2011 at 5:13 PM, Daniel Farina wrote:
> On Mon, Feb 14, 2011 at 12:48 AM, Fujii Masao wrote:
>> On Sat, Feb 12, 2011 at 8:58 AM, Daniel Farina wrote:
>>> Context diff equivalent attached.
>>
>> Thanks for the patch!
>>
>> As I said before, the timeout which this patch provides do
robertmh...@gmail.com (Robert Haas) writes:
> It does, but frankly I don't see much reason to change it, since it's
> been working pretty well on the whole. Andrew was on point when he
> mentioned that it's not obvious what committers get out of working on
> other people's patches. Obviously, the
Dimitri Fontaine writes:
> I realize that you didn't keep the \dx behavior I had, that when given
> an extension name it would list all the objects contained in the
> extension.
Sure I did: \dx+
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
On Tue, Feb 15, 2011 at 12:15 PM, Robert Haas wrote:
> On another disk, I think that those warning messages are a bad idea.
> That could fill up someone's disk really quickly.
On another disk? What the heck am I talking about?
On another point? On another note? Anyway, you get the idea... hop
On Tue, Feb 15, 2011 at 11:37 AM, Dimitri Fontaine
wrote:
> Do we want to get that back in, and in which psql command? It could
> well be that having \dx list extension and \dx name list extension's
> objects wasn't the best design around, and it could be that it's not
> useful enough, but I know
On Tue, Feb 15, 2011 at 11:42 AM, Simon Riggs wrote:
> Patch attached, no docs yet, but the patch is clear.
>
> I'm looking to commit this in next 24 hours barring objections and/or
> test failures.
Looks pretty good to me, though I haven't tested it. I like some of
the safety valves you put in
On 02/15/2011 06:55 AM, Robert Haas wrote:
On Tue, Feb 15, 2011 at 3:31 AM, Itagaki Takahiro
wrote:
On Tue, Feb 15, 2011 at 01:27, Robert Haas wrote:
However, file_fdw is in pretty serious trouble because (1) the copy
API patch that it depends on still isn't committed and (2) it's going
to
On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote:
> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> wrote:
>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also
>> sends a status update every time the WAL is flushed. If the walreceiver is
>> busy receiving and fl
On Tue, Feb 15, 2011 at 1:11 AM, Fujii Masao wrote:
> On Mon, Feb 14, 2011 at 2:08 PM, Fujii Masao wrote:
>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
>> wrote:
>>> I committed the patch with those changes, and some minor comment tweaks and
>>> other kibitzing.
>
> I have another comme
On Mon, Feb 14, 2011 at 12:08 AM, Fujii Masao wrote:
> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas
> wrote:
>> I committed the patch with those changes, and some minor comment tweaks and
>> other kibitzing.
>
> + * 'd' means a standby reply wrapped in a COPY BOTH packet.
> +
Gurjeet Singh writes:
> Also attached is the patch expose_IndexSupportInitialize.patch, that makes
> the static function IndexSupportInitialize() global so that the Index
> Advisor doesn't have to reinvent the wheel to prepare an index structure
> with opfamilies and opclasses.
We are *not* doing
On Tue, 2011-02-15 at 18:49 +0200, Heikki Linnakangas wrote:
> It would be wise to also transmit the epoch in addition to xmin, to
> avoid confusion if the standby is > 2 billion transactions behind.
Yes, good idea, thanks.
That has to be the record for the fastest patch review. ;-)
--
Simon
On 02/15/2011 11:13 AM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Well, I guess the other option is to just add it to the format, full
stop. But as someone pointed out previously, that's not a terribly
scalable solution, but perhaps it could be judged adequate for this
On 15.02.2011 18:52, Robert Haas wrote:
On Tue, Feb 15, 2011 at 11:49 AM, Heikki Linnakangas
wrote:
It would be wise to also transmit the epoch in addition to xmin, to avoid
confusion if the standby is> 2 billion transactions behind.
That case is probably hopelessly broken anyway.
I don't
On Tue, Feb 15, 2011 at 11:49 AM, Heikki Linnakangas
wrote:
> On 15.02.2011 18:42, Simon Riggs wrote:
>>
>> On Sat, 2011-02-12 at 14:11 -0800, Daniel Farina wrote:
>>>
>>> This is another bit of the syncrep patch split out.
>>>
>>> I will revisit the replication timeout one Real Soon, I promise --
On Tue, Feb 15, 2011 at 11:41 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
>>> Robert Haas writes:
Those are good points. My point was just that you can't actually
build that file at the time you RUN the regression tests, because you
On 15.02.2011 18:42, Simon Riggs wrote:
On Sat, 2011-02-12 at 14:11 -0800, Daniel Farina wrote:
This is another bit of the syncrep patch split out.
I will revisit the replication timeout one Real Soon, I promise -- but
I have a couple things to do today that may delay that until the
evening.
h
On Sat, 2011-02-12 at 14:11 -0800, Daniel Farina wrote:
> This is another bit of the syncrep patch split out.
>
> I will revisit the replication timeout one Real Soon, I promise -- but
> I have a couple things to do today that may delay that until the
> evening.
>
> https://github.com/fdr/postgre
Robert Haas writes:
> On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Those are good points. My point was just that you can't actually
>>> build that file at the time you RUN the regression tests, because you
>>> have to build it first, then install it, then run the
Hi,
I realize that you didn't keep the \dx behavior I had, that when given
an extension name it would list all the objects contained in the
extension. Now that's a pretty simple query:
select pg_describe_object(classid, objid, 0)
from pg_depend d
join pg_extension e on d.refclassid =
On Tue, 2011-02-15 at 01:45 -0500, Jaime Casanova wrote:
> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs wrote:
> >
> > Here's the latest patch for sync rep.
> >
>
> I was looking at this code and found something in SyncRepWaitOnQueue
> we declare a timeout variable that is a long and another that
On Tue, Feb 15, 2011 at 11:13 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Well, I guess the other option is to just add it to the format, full
>> stop. But as someone pointed out previously, that's not a terribly
>> scalable solution, but perhaps it could be judged
On 15.02.2011 18:03, Tom Lane wrote:
Robert Haas writes:
On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane wrote:
What risk? And at least we'd be trying to do it cleanly, in a manner
that should work for at least 99% of users. AFAICT, Heikki's proposal
is "break it for everyone, and damn the torpe
* Robert Haas (robertmh...@gmail.com) wrote:
> Well, I guess the other option is to just add it to the format, full
> stop. But as someone pointed out previously, that's not a terribly
> scalable solution, but perhaps it could be judged adequate for this
> particular case.
Think I suggested that
On Tue, Feb 15, 2011 at 11:01 AM, Tom Lane wrote:
> Robert Haas writes:
>> Those are good points. My point was just that you can't actually
>> build that file at the time you RUN the regression tests, because you
>> have to build it first, then install it, then run the regression
>> tests. It c
On Tue, Feb 15, 2011 at 11:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 15, 2011 at 10:53 AM, Tom Lane wrote:
>>> What risk? And at least we'd be trying to do it cleanly, in a manner
>>> that should work for at least 99% of users. AFAICT, Heikki's proposal
>>> is "break it for e
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Given that this has been like this right along, I don't see why it's
> all that urgent to force a half-baked solution into 9.1. I'm also
> concerned that if we do do that, you'll lose motivation to work on
> cleaning it up for 9.2 ;-)
The addition to
On Tue, Feb 15, 2011 at 10:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> Something along these lines would be OK with me (I haven't yet
>> validated every detail), but there were previous objections to adding
>> any new fields to log_line_prefix until we had a flexible CSV format.
>> I think th
1 - 100 of 136 matches
Mail list logo
