Heikki Linnakangas wrote:
> Ok, committed.
I see that at least three BuildFarm critters don't have UINT64_MAX
defined. Not sure why coypu is running out of connections.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan wrote:
> Here is a patch against the latest revision of file_fdw to exercise this
> API. It includes some regression tests, and I think apart from one or two
> small details plus a requirement for documentation, is complete.
The patch contains a few fi
I needed something to test the FDW API patch with, and didn't want to
get involved in the COPY API changes, and also wanted to have something
that needs real connection management and can push down quals. So I
updated the postgresql_fdw patch to work with the latest FDW patch.
Here. It's a bit
On Mon, Feb 7, 2011 at 20:38, Thom Brown wrote:
> Yes, of course, int8 functions are separate. I attach an updated
> patch, although I still think there's a better way of doing this.
Thanks. Please add the patch to the *current* commitfest
because it's a bugfix.
https://commitfest.postgresql.org
Tom Lane writes:
> I see no
> argument whatsoever why we should lock down extensions and only extensions
> against this risk.
Spelled this way I can only agree :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mai
On 08.02.2011 10:43, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Ok, committed.
I see that at least three BuildFarm critters don't have UINT64_MAX
defined.
I guess we'll have to just #define it ourselves. Or could we just pick
another magic value, do we actually rely on InvalidSerComm
On 02/08/2011 03:49 AM, Itagaki Takahiro wrote:
On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan wrote:
Here is a patch against the latest revision of file_fdw to exercise this
API. It includes some regression tests, and I think apart from one or two
small details plus a requirement for documenta
On Tue, 8 Feb 2011 17:49:09 +0900
Itagaki Takahiro wrote:
> On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan wrote:
> > Here is a patch against the latest revision of file_fdw to exercise this
> > API. It includes some regression tests, and I think apart from one or two
> > small details plus a requ
Stephen Frost!
I have modified the code to use ADD_STARTUP_OPTION instead of writing code
again.
And tried the patch on Windows and Linux and it works for me.
On Sun, Feb 6, 2011 at 10:19 AM, Stephen Frost wrote:
> Ibrar,
>
> * Ibrar Ahmed (ibrar.ah...@gmail.com) wrote:
> > I have reviewed
On 8 February 2011 09:22, Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 20:38, Thom Brown wrote:
>> Yes, of course, int8 functions are separate. I attach an updated
>> patch, although I still think there's a better way of doing this.
>
> Thanks. Please add the patch to the *current* commitfes
Tom Lane writes:
> Attached is an updated patch that incorporates all of the review I've
And that looks great, thanks. I've only had time to read the patch,
will play with it later on today, hopefully.
I've spotted a comment that I think you missed updating. The schema
given in the control f
_lookup.patch is attached for review purpose.
This patch includes changes for this fix.
Regards,
--
Shigeru Hanada
avoid_catalog_lookup.patch
Description: Binary data
20110208-foreign_scan.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
* Robert Haas (robertmh...@gmail.com) wrote:
> - Range Types. This is a large patch which was submitted for the
> first time to the last CommitFest of the cycle, and the first version
> that had no open TODO items was posted yesterday, three-quarters of
> the way through that last CommitFest. Som
Kevin Grittner wrote:
> Heikki Linnakangas wrote:
>
> > Ok, committed.
>
> I see that at least three BuildFarm critters don't have UINT64_MAX
> defined. Not sure why coypu is running out of connections.
Yes, I am seeing that failures here too on my BSD machine.
--
Bruce Momjian
On Tue, Feb 8, 2011 at 2:05 AM, Jaime Casanova wrote:
>> Finally, this is a nice feature iif we have a way to know what named restore
>> points are available. DBAs need to take note of this list (that is not good)
>> and the lazy ones will have a hard time to recover the right name (possibly
>> wi
> Heikki Linnakangas wrote:
> On 08.02.2011 10:43, Kevin Grittner wrote:
>
>> I see that at least three BuildFarm critters don't have UINT64_MAX
>> defined.
>
> I guess we'll have to just #define it ourselves. Or could we just
> pick another magic value, do we actually rely on
> InvalidSerCommi
On Tue, Feb 8, 2011 at 2:23 AM, Nick Rudnick wrote:
> (my last two posts seemingly did not reach the HACKERS forum, so please let
> me resend the last one ;-) )
They got here - I think just no one had any further comment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
On Tue, Feb 8, 2011 at 4:42 AM, Shigeru HANADA
wrote:
> On Tue, 8 Feb 2011 17:49:09 +0900
> Itagaki Takahiro wrote:
>
>> On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan wrote:
>> > Here is a patch against the latest revision of file_fdw to exercise this
>> > API. It includes some regression tests,
On Tue, 2011-02-08 at 08:05 -0500, Robert Haas wrote:
> On Tue, Feb 8, 2011 at 2:05 AM, Jaime Casanova wrote:
> >> Finally, this is a nice feature iif we have a way to know what named
> >> restore
> >> points are available. DBAs need to take note of this list (that is not
> >> good)
> >> and the
On Fri, 2011-02-04 at 21:15 -0500, Jaime Casanova wrote:
> >
> > + else if (recoveryTarget == RECOVERY_TARGET_NAME)
> > + snprintf(buffer, sizeof(buffer),
> > +"%s%u\t%s\t%s named restore point %
> s\n",
> > +(srcfd
On 02/03/2011 01:20 PM, Andrew Dunstan wrote:
- Every existing plperl function that takes arrays is going to get
slower due to the overhead of parsing the string and allocating the
array and all its elements.
Well, per my understanding of Alex changes, the string parsing is
not invoked
unl
2011/2/8 Steve Singer :
> On 11-02-07 10:37 PM, Robert Haas wrote:
>
>> - The PL/python extravaganza. I'm not really clear where we stand
>> with this. There are a lot of patches here.
>>
>
> Some of the patches have been committed a few others are ready (or almost
> ready) for a committer. The
On 08/02/11 15:44, Hitoshi Harada wrote:
> 2011/2/8 Steve Singer :
>> On 11-02-07 10:37 PM, Robert Haas wrote:
>>
>>> - The PL/python extravaganza. I'm not really clear where we stand
>>> with this. There are a lot of patches here.
>>>
>>
>> Some of the patches have been committed a few others ar
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
> On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker wrote:
>> On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin
>> wrote:
>>> I've looked at the patch and added a test for arrays exceeding or equal
>>> maximum dimensions to check, whether the recursive f
Dimitri Fontaine writes:
> I've spotted a comment that I think you missed updating. The schema
> given in the control file is now created in all cases rather than only
> when the extension is not relocatable, right?
Hm, no, that logic is the same as before no?
> I also note that the attached ve
On Mon, Feb 7, 2011 at 11:52 PM, Noah Misch wrote:
> On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
>> So
>> can we just get rid of should_be_detoasted, and have exec_eval_datum()
>> or its callers instead test:
>>
>> !var->isnull && var->datatype->typbyval && var->datatype->typlen =
On Tue, Feb 08, 2011 at 08:00:42AM +0100, Pavel Stehule wrote:
> 2011/2/8 Noah Misch :
> > On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
> >> So
> >> can we just get rid of should_be_detoasted, and have exec_eval_datum()
> >> or its callers instead test:
> >>
> >> !var->isnull && var
On Sat, 2011-01-15 at 07:31 +0900, Fujii Masao wrote:
> I propose the patch which reduces the amount of data loss
> on the standby.
Committed. Well spotted.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via
On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas wrote:
> On 08.02.2011 10:43, Kevin Grittner wrote:
> > I see that at least three BuildFarm critters don't have UINT64_MAX
> > defined.
>
> I guess we'll have to just #define it ourselves. Or could we just pick
> another magic value, do
On fre, 2011-02-04 at 10:47 -0500, Tom Lane wrote:
> The reason that we use quotes in CREATE DATABASE is that encoding
> names aren't assumed to be valid SQL identifiers. If this patch isn't
> following the CREATE DATABASE precedent, it's the patch that's wrong,
> not CREATE DATABASE.
Since encod
2011/2/8 Noah Misch :
> On Tue, Feb 08, 2011 at 08:00:42AM +0100, Pavel Stehule wrote:
>> 2011/2/8 Noah Misch :
>> > On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
>> >> So
>> >> can we just get rid of should_be_detoasted, and have exec_eval_datum()
>> >> or its callers instead test:
Dan Ports wrote:
> On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas
wrote:
>> On 08.02.2011 10:43, Kevin Grittner wrote:
>>> I see that at least three BuildFarm critters don't have
>>> UINT64_MAX defined.
>>
>> I guess we'll have to just #define it ourselves. Or could we just
>> pick
Peter Eisentraut writes:
> On fre, 2011-02-04 at 10:47 -0500, Tom Lane wrote:
>> The reason that we use quotes in CREATE DATABASE is that encoding
>> names aren't assumed to be valid SQL identifiers. If this patch isn't
>> following the CREATE DATABASE precedent, it's the patch that's wrong,
>> n
2011/2/8 Robert Haas :
> On Mon, Feb 7, 2011 at 11:52 PM, Noah Misch wrote:
>> On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
>>> So
>>> can we just get rid of should_be_detoasted, and have exec_eval_datum()
>>> or its callers instead test:
>>>
>>> !var->isnull && var->datatype->typb
I wrote:
> The multiplier of 10 PredXactList structures per connection is
> kind of arbitrary. It affects the point at which information is
> pushed to the lossy summary, so any number from 2 up will work
> correctly; it's a matter of performance and false positive rate.
> We might want to put
On 08.02.2011 17:50, Kevin Grittner wrote:
Attached is something which will work. Whether people prefer this
or a definition of UINT64_MAX in some header file (if it's missing)
doesn't matter much to me.
At any rate, if someone commits this one-liner, three critters
should go back to green.
T
On Mon, Feb 7, 2011 at 5:16 PM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 11:50 -0800, Josh Berkus wrote:
>> >> I just spoke to my manager at EnterpriseDB and he cleared my schedule
>> >> for the next two days to work on this. So I'll go hack on this now.
>> >> I haven't read the patch yet so I
sfr...@snowman.net (Stephen Frost) writes:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> - Range Types. This is a large patch which was submitted for the
>> first time to the last CommitFest of the cycle, and the first version
>> that had no open TODO items was posted yesterday, three-quarters
On 11-02-08 10:07 AM, Jan Urbański wrote:
* custom SPI exceptions - I'd really like this one to go in, because it
allows writing UPSERT-kind functions in PL/Python very easily, and it's
just a handful of lines of code
I will try to do a review of this one (probably tomorrow night) since
I'
On Mon, 2011-02-07 at 20:32 +0200, Peter Eisentraut wrote:
> Have you considered a grammar approach like for arrays, so that you
> would write something like
>
> CREATE TABLE ... (
> foo RANGE OF int
> );
>
> instead of explicitly creating a range type for every scalar type in
> existence? I
Tom Lane writes:
> Dimitri Fontaine writes:
>> I've spotted a comment that I think you missed updating. The schema
>> given in the control file is now created in all cases rather than only
>> when the extension is not relocatable, right?
>
> Hm, no, that logic is the same as before no?
Well I
2011/2/9 Tom Lane :
> Peter Eisentraut writes:
>> On fre, 2011-02-04 at 10:47 -0500, Tom Lane wrote:
>>> The reason that we use quotes in CREATE DATABASE is that encoding
>>> names aren't assumed to be valid SQL identifiers. If this patch isn't
>>> following the CREATE DATABASE precedent, it's th
On Tue, Feb 08, 2011 at 10:24:03AM -0500, Robert Haas wrote:
> Well, Pavel's subsequent reply suggested that he didn't test exactly
> this thing, so maybe there's hope.
No hope on that basis, no.
> Or maybe not. If Tom thought one branch inside exec_eval_datum() was
> going to be too expensive,
It just occurred to me that the extensions patch thoroughly breaks
pg_upgrade, because pg_upgrade imagines that it can control the specific
OIDs assigned to certain SQL objects such as data types. That is of
course not gonna happen for objects within an extension. In fact, since
part of the point
On Tue, Feb 8, 2011 at 10:40 AM, Chris Browne wrote:
> sfr...@snowman.net (Stephen Frost) writes:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>> - Range Types. This is a large patch which was submitted for the
>>> first time to the last CommitFest of the cycle, and the first version
>>> that
Tom Lane writes:
> In any case that would ratchet the priority of ALTER EXTENSION UPGRADE
> back up to a must-have-for-9.1, since pg_upgrade would then leave you
> with a non-upgraded extension.
>
> Now what?
What would be the problem with pg_upgrade acting the same as a
dump&reload cycle as far
Dimitri Fontaine writes:
> Tom Lane writes:
>> Hm, no, that logic is the same as before no?
> Well I had
> if (!control->relocatable && control->schema != NULL)
> And you have
> + else if (control->schema != NULL)
Yeah, I deleted that relocatable test because it's redundan
On Mon, 2011-02-07 at 18:23 +0100, Dimitri Fontaine wrote:
> I would think
>
> CREATE TYPE foo AS RANGE (bar) USING (btree_ops);
>
> The USING clause is optional, because you generally have a default btree
> opclass for the datatype.
There are other options, like "CANONICAL", so where do those
Em 08-02-2011 11:05, Simon Riggs escreveu:
On Fri, 2011-02-04 at 21:15 -0500, Jaime Casanova wrote:
+ else if (recoveryTarget == RECOVERY_TARGET_NAME)
+ snprintf(buffer, sizeof(buffer),
+"%s%u\t%s\t%s named restore point %
s\n",
+
On Tue, 2011-02-08 at 14:07 -0300, Euler Taveira de Oliveira wrote:
> > Not sure I understand the comment "only make sense when we're dealing
> > with transaction or time." Why?
> >
> Because named restore point is a noop xlog record; besides, transaction and
> time involves xlog records that co
2011/2/8 Noah Misch :
> On Tue, Feb 08, 2011 at 10:24:03AM -0500, Robert Haas wrote:
>> Well, Pavel's subsequent reply suggested that he didn't test exactly
>> this thing, so maybe there's hope.
>
> No hope on that basis, no.
>
>> Or maybe not. If Tom thought one branch inside exec_eval_datum() wa
Em 08-02-2011 04:57, Greg Smith escreveu:
We recenty got some on-list griping that pg_standby doesn't handle
archive files that are compressed, either. Given how the job I'm working
on this week is going, I'll probably have to add that feature next.
That's actually an easier source code hack than
Dimitri Fontaine writes:
> Tom Lane writes:
>> Now what?
> What would be the problem with pg_upgrade acting the same as a
> dump&reload cycle as far as extensions are concerned?
Um, how about "it doesn't work"?
The reason that data type OIDs have to be preserved, for example, is
that they migh
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin wrote:
>
> On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
>> So here is a v6
>>
>> Comments?
>
> Thanks, looks great to me. It passes all the tests on my OS X system. I wonder
> what's the purpose of the amagic_call in get_perl_array_ref, instea
On Tue, Feb 8, 2011 at 11:53 AM, Tom Lane wrote:
> It just occurred to me that the extensions patch thoroughly breaks
> pg_upgrade, because pg_upgrade imagines that it can control the specific
> OIDs assigned to certain SQL objects such as data types. That is of
> course not gonna happen for obje
On Feb 8, 2011, at 9:36 AM, Robert Haas wrote:
> I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
> UPGRADE is pretty much a must-have for a useful feature regardless of
> this issue. I had previously thought that we might be able to limp
> along with half a feature for one re
On Tue, Feb 8, 2011 at 11:38 AM, Noah Misch wrote:
> It's not as if this patch raised complex questions that folks need more time
> to
> digest. For a patch this small and simple, we minimally owe Pavel a direct
> answer about its rejection.
Well, I don't see how we can give a totally straightf
On Mon, Feb 07, 2011 at 10:37:06PM -0500, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 3:57 PM, Chris Browne wrote:
> > It sure looks to me like there are going to be a bunch of items that,
> > based on the recognized policies, need to get deferred to 9.2, and the
> > prospects for Sync Rep getting
On Tue, Feb 8, 2011 at 12:57 PM, David E. Wheeler wrote:
> On Feb 8, 2011, at 9:36 AM, Robert Haas wrote:
>
>> I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
>> UPGRADE is pretty much a must-have for a useful feature regardless of
>> this issue. I had previously thought that
Robert Haas writes:
> I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
> UPGRADE is pretty much a must-have for a useful feature regardless of
> this issue. I had previously thought that we might be able to limp
> along with half a feature for one release - if you're not actua
On Feb 8, 2011, at 10:03 AM, Robert Haas wrote:
> No, this is not doable, or at least not in a way that provides any
> benefit over just dropping and reinstalling. The problem is that it
> is going to fall down all over the place if other objects are
> depending on objects provided by the extensi
"David E. Wheeler" writes:
> On Feb 8, 2011, at 10:03 AM, Robert Haas wrote:
>> No, this is not doable, or at least not in a way that provides any
>> benefit over just dropping and reinstalling. The problem is that it
>> is going to fall down all over the place if other objects are
>> depending o
On Feb 8, 2011, at 10:24 AM, Tom Lane wrote:
>> Ah, right, of course. I don't suppose CREATE OR REPLACE would work, either,
>> in some cases at least?
>
> But figuring out just what commands to issue is pretty nearly AI-complete.
> The whole point of ALTER EXTENSION UPGRADE is to have a human do
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker wrote:
> On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin wrote:
>> Thanks, looks great to me. It passes all the tests on my OS X system. I
>> wonder
>> what's the purpose of the amagic_call in get_perl_array_ref, instead of
>> calling newRV_noinc on the t
On Tue, Feb 08, 2011 at 10:14:44AM -0600, Kevin Grittner wrote:
> I do have some concern that if this defaults to too low a number,
> those who try SSI without bumping it and restarting the postmaster
> will not like the performance under load very much. SSI performance
> would not be affected by
attached
-Kevin
*** a/doc/src/sgml/mvcc.sgml
--- b/doc/src/sgml/mvcc.sgml
***
*** 670,676 ERROR: could not serialize access due to read/write
dependencies among transact
permanent database writes within Serializable transactions on the
master will ensure that all
On tis, 2011-02-08 at 00:16 -0500, Steve Singer wrote:
> On 11-02-07 10:37 PM, Robert Haas wrote:
>
> > - The PL/python extravaganza. I'm not really clear where we stand
> > with this. There are a lot of patches here.
> >
>
> Some of the patches have been committed a few others are ready (or
>
On tis, 2011-02-08 at 10:53 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On fre, 2011-02-04 at 10:47 -0500, Tom Lane wrote:
> >> The reason that we use quotes in CREATE DATABASE is that encoding
> >> names aren't assumed to be valid SQL identifiers. If this patch isn't
> >> following the
On Tue, Feb 08, 2011 at 09:25:29PM +0900, Itagaki Takahiro wrote:
> Here is a revised patch, that including jagged csv support.
> A new exported function is named as NextCopyFromRawFields.
Seems a bit incongruous to handle the OID column in that function. That part
fits with the other per-column
Hi!
The PostgreSQL Infrastructure Team will be performing scheduled
maintenance on the server that is hosting gitmaster.postgresql.org the
coming sunday, Feb 13th. While we expect this to only cause a very
short downtime for the service, one can never be entirely sure with
remote maintenance.. For
On Mon, Feb 7, 2011 at 1:20 PM, Robert Haas wrote:
> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs wrote:
>> Here's the latest patch for sync rep.
>
> Here is a rebased version of this patch which applies to head of the
> master branch. I haven't tested it yet beyond making sure that it
> compile
On 08.02.2011 18:14, Kevin Grittner wrote:
I wrote:
The multiplier of 10 PredXactList structures per connection is
kind of arbitrary. It affects the point at which information is
pushed to the lossy summary, so any number from 2 up will work
correctly; it's a matter of performance and false po
On Mon, 2011-02-07 at 22:37 -0500, Robert Haas wrote:
> - Range Types. This is a large patch which was submitted for the
> first time to the last CommitFest of the cycle, and the first version
> that had no open TODO items was posted yesterday, three-quarters of
> the way through that last CommitF
On Tue, Feb 8, 2011 at 1:02 PM, David Fetter wrote:
> Given how things worked, i.e. that people were not clear that 9.1
> development had actually started, etc., I am again proposing that we
> have one more CF starting March 15 to get this all cleaned up. Yes, I
> know that wasn't the plan, but I
On Tue, 2011-02-08 at 06:57 -0500, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
> > - Range Types. This is a large patch which was submitted for the
> > first time to the last CommitFest of the cycle, and the first version
> > that had no open TODO items was posted yesterday
* Jeff Davis (pg...@j-davis.com) wrote:
> I appreciate the sentiment, but in addition to some cleanup, any patch
> like this at least requires some discussion. It's a language change
> we'll be supporting for a long time.
My feeling was that we have had at least some of that discussion this
past f
On Tue, Feb 08, 2011 at 02:04:04PM -0500, Robert Haas wrote:
> On Tue, Feb 8, 2011 at 1:02 PM, David Fetter wrote:
> > Given how things worked, i.e. that people were not clear that 9.1
> > development had actually started, etc., I am again proposing that we
> > have one more CF starting March 15 t
On Tue, 2011-02-08 at 11:56 -0500, Robert Haas wrote:
> It's a 5400 line patch that wasn't completed until the middle of the
> current CommitFest. Nobody has ever submitted a major feature patch
> of that size that got done in a single CommitFest, to my recollection,
> or even half that size.
My
Heikki Linnakangas wrote:
> Taking RWConflictPool into account in PredicateLockShmemSize() fixes
the
> underestimate, but makes the overestimate correspondingly larger.
I've
> never compared the actual and estimated shmem sizes of other parts of
> the backend, so I'm not sure how large discre
On Tue, Feb 8, 2011 at 2:02 PM, Jeff Davis wrote:
> On Mon, 2011-02-07 at 22:37 -0500, Robert Haas wrote:
>> - Range Types. This is a large patch which was submitted for the
>> first time to the last CommitFest of the cycle, and the first version
>> that had no open TODO items was posted yesterda
On lör, 2011-02-05 at 12:26 +0100, Nick Rudnick wrote:
> o extensions of PostgreSQL to support such a kind of usage have to
> be expected to be expected to be rejected from integration to the code
> base core -- i.e., if they are done, students have to be told «you
> can't expect this to become a
On Tue, Feb 8, 2011 at 19:53, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 1:20 PM, Robert Haas wrote:
>> On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs wrote:
>>> Here's the latest patch for sync rep.
>>
>> Here is a rebased version of this patch which applies to head of the
>> master branch. I h
On Sun, February 6, 2011 07:41, Jeff Davis wrote:
> New patch. All known TODO items are closed, although I should do a
> cleanup pass over the code and docs.
>
> Fixed in this patch:
>
> * Many documentation improvements
> * Added INT8RANGE
> * Renamed PERIOD[TZ] -> TS[TZ]RANGE
> * Renamed
On 08.02.2011 20:40, Kevin Grittner wrote:
attached
Fixed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 8, 2011 at 2:13 PM, David Fetter wrote:
>> I agree that we have some problems in that area - particularly with
>> writeable CTEs - but prolonging the schedule isn't going to fix that
>> problem.
>
> What is?
I think the best solution would probably be to find corporate sponsors
for mo
On Tue, Feb 8, 2011 at 2:34 PM, Magnus Hagander wrote:
> I would usually not worry about the bandwidth, really, I'd be more
> worried about potentially increasing latency somewhere.
The time to read and write the socket doesn't seem like it should be
significant, unless the network buffers fill u
On Tue, 2011-02-08 at 14:07 -0300, Euler Taveira de Oliveira wrote:
> Because named restore point is a noop xlog record; besides, transaction and
> time involves xlog records that contain data.
Committed. Thanks for the patch and the review.
I changed the patch to require wal_level > minimal, r
>From here, I consider myself free and clear to work on Sync Rep as my
final contribution to this Commit Fest. There's still patches I'm
interested in, but priority and time means I won't be reviewing anything
further.
I'm mostly unreachable for next few days, but expect to be working on
Sync rep
pg...@j-davis.com (Jeff Davis) writes:
> On Tue, 2011-02-08 at 06:57 -0500, Stephen Frost wrote:
>> * Robert Haas (robertmh...@gmail.com) wrote:
>> > - Range Types. This is a large patch which was submitted for the
>> > first time to the last CommitFest of the cycle, and the first version
>> > tha
Greetings,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I resend a patch with last update of this patch
Alright, so, like I said, I really like this feature and would like to
see it included. To that end, I've done perhaps a bit more than a
review of the patch. Pavel, if you could go over
On Tue, 2011-02-08 at 13:53 -0500, Robert Haas wrote:
> That having been said, there is at least one part of this patch which
> looks to be in pretty good shape and seems independently useful
> regardless of what happens to the rest of it, and that is the code
> that sends replies from the standby
On Tue, Feb 8, 2011 at 3:26 PM, Stephen Frost wrote:
> Greetings,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I resend a patch with last update of this patch
>
> Alright, so, like I said, I really like this feature and would like to
> see it included. To that end, I've done perhaps a
Tom Lane writes:
> Yeah, I deleted that relocatable test because it's redundant:
> control->schema cannot be set for a relocatable extension,
> cf the test in read_extension_control_file.
I missed that you kept this test in your version of the patch. Sorry
for noise.
Regardsm
--
Dimitri Fontai
On 8 February 2011 19:53, Simon Riggs wrote:
> On Tue, 2011-02-08 at 14:07 -0300, Euler Taveira de Oliveira wrote:
>
>> Because named restore point is a noop xlog record; besides, transaction and
>> time involves xlog records that contain data.
>
> Committed. Thanks for the patch and the review.
>
Tom Lane writes:
> that they might be out on disk. Suppose that you have the cube
> extension installed and there are some user tables containing columns of
> type cube[]. Those arrays are going to have type cube's OID embedded in
> them. If cube has a different OID after pg_upgrade then the ar
One other nit re. the predicate lock table size GUCs: the out-of-memory
case in RegisterPredicateLockingXid (predicate.c:1592 in my tree) gives
the hint to increase max_predicate_locks_per_transaction. I don't think
that's correct, since that GUC isn't used to size SerializableXidHash.
In fact, th
Tom Lane writes:
> Personally I find the extension stuff to be a bigger deal than anything
> else remaining in the commitfest. Also, I've fixed a number of
> pre-existing bugs in passing, and I'd have to go extract those changes
> out of the current extensions patch if we abandon it now. So I'd
* Robert Haas (robertmh...@gmail.com) wrote:
> Amen to that!
Hopefully it helped. :)
> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
> arr rather than just FOREACH thingy IN arr. That's probably a good
> idea, because it gives us an escape hatch against needing to invent
>
2011/2/8 Stephen Frost :
> Greetings,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I resend a patch with last update of this patch
>
> Alright, so, like I said, I really like this feature and would like to
> see it included. To that end, I've done perhaps a bit more than a
> review of t
2011/2/8 Stephen Frost :
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Amen to that!
>
> Hopefully it helped. :)
>
>> I think the syntax Tom suggested before was FOREACH thingy IN ARRAY
>> arr rather than just FOREACH thingy IN arr. That's probably a good
>> idea, because it gives us an escape
1 - 100 of 151 matches
Mail list logo
