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:
On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan and...@dunslane.net 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
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
On Mon, Feb 7, 2011 at 20:38, Thom Brown t...@linux.com 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.
Tom Lane t...@sss.pgh.pa.us 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
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
On 02/08/2011 03:49 AM, Itagaki Takahiro wrote:
On Tue, Feb 8, 2011 at 09:38, Andrew Dunstanand...@dunslane.net 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
On Tue, 8 Feb 2011 17:49:09 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan and...@dunslane.net 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
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 sfr...@snowman.net wrote:
Ibrar,
* Ibrar Ahmed (ibrar.ah...@gmail.com) wrote:
I
On 8 February 2011 09:22, Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Mon, Feb 7, 2011 at 20:38, Thom Brown t...@linux.com 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
Tom Lane t...@sss.pgh.pa.us 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
.
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)
To make changes to your subscription:
http
* 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. Some
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 ja...@2ndquadrant.com 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
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
InvalidSerCommitSeqno
On Tue, Feb 8, 2011 at 2:23 AM, Nick Rudnick joerg.rudn...@t-online.de 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:
On Tue, Feb 8, 2011 at 4:42 AM, Shigeru HANADA
han...@metrosystems.co.jp wrote:
On Tue, 8 Feb 2011 17:49:09 +0900
Itagaki Takahiro itagaki.takah...@gmail.com wrote:
On Tue, Feb 8, 2011 at 09:38, Andrew Dunstan and...@dunslane.net wrote:
Here is a patch against the latest revision of file_fdw
On Tue, 2011-02-08 at 08:05 -0500, Robert Haas wrote:
On Tue, Feb 8, 2011 at 2:05 AM, Jaime Casanova ja...@2ndquadrant.com 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)
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 0) ? :
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
2011/2/8 Steve Singer ssinger...@sympatico.ca:
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
On 08/02/11 15:44, Hitoshi Harada wrote:
2011/2/8 Steve Singer ssinger...@sympatico.ca:
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
On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker bada...@gmail.com wrote:
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin al...@commandprompt.com
wrote:
I've looked at the patch and added a test for arrays exceeding or equal
maximum dimensions to
Dimitri Fontaine dimi...@2ndquadrant.fr 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
On Mon, Feb 7, 2011 at 11:52 PM, Noah Misch n...@leadboat.com 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 n...@leadboat.com:
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
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 we
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 encoding
2011/2/8 Noah Misch n...@leadboat.com:
On Tue, Feb 08, 2011 at 08:00:42AM +0100, Pavel Stehule wrote:
2011/2/8 Noah Misch n...@leadboat.com:
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
Dan Ports d...@csail.mit.edu 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
Peter Eisentraut pete...@gmx.net 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
2011/2/8 Robert Haas robertmh...@gmail.com:
On Mon, Feb 7, 2011 at 11:52 PM, Noah Misch n...@leadboat.com 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
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 that
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.
On Mon, Feb 7, 2011 at 5:16 PM, Simon Riggs si...@2ndquadrant.com 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
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 of
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
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 think
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dimi...@2ndquadrant.fr 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
2011/2/9 Tom Lane t...@sss.pgh.pa.us:
Peter Eisentraut pete...@gmx.net 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
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
On Tue, Feb 8, 2011 at 10:40 AM, Chris Browne cbbro...@acm.org 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
Tom Lane t...@sss.pgh.pa.us 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
dumpreload
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us 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
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 fit?
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 contain
2011/2/8 Noah Misch n...@leadboat.com:
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
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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Now what?
What would be the problem with pg_upgrade acting the same as a
dumpreload cycle as far as extensions are concerned?
Um, how about it doesn't work?
The reason that data type OIDs have to be
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin al...@commandprompt.com 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
On Tue, Feb 8, 2011 at 11:53 AM, Tom Lane t...@sss.pgh.pa.us 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
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
On Tue, Feb 8, 2011 at 11:38 AM, Noah Misch n...@leadboat.com 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
On Mon, Feb 07, 2011 at 10:37:06PM -0500, Robert Haas wrote:
On Mon, Feb 7, 2011 at 3:57 PM, Chris Browne cbbro...@acm.org 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
On Tue, Feb 8, 2011 at 12:57 PM, David E. Wheeler da...@kineticode.com 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
Robert Haas robertmh...@gmail.com 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 -
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 extension.
David E. Wheeler da...@kineticode.com 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
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 that
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker bada...@gmail.com wrote:
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin al...@commandprompt.com 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
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 a
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
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
almost
On tis, 2011-02-08 at 10:53 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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..
On Mon, Feb 7, 2011 at 1:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs si...@2ndquadrant.com 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
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
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
On Tue, Feb 8, 2011 at 1:02 PM, David Fetter da...@fetter.org 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
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
On Tue, Feb 08, 2011 at 02:04:04PM -0500, Robert Haas wrote:
On Tue, Feb 8, 2011 at 1:02 PM, David Fetter da...@fetter.org 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
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 heikki.linnakan...@enterprisedb.com 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,
On Tue, Feb 8, 2011 at 2:02 PM, Jeff Davis pg...@j-davis.com 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
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 robertmh...@gmail.com wrote:
On Mon, Feb 7, 2011 at 1:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jan 15, 2011 at 4:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Here's the latest patch for sync rep.
Here is a rebased version of this
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 INTRANGE
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 da...@fetter.org 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
On Tue, Feb 8, 2011 at 2:34 PM, Magnus Hagander mag...@hagander.net 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
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,
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
that had no
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 sfr...@snowman.net 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
Tom Lane t...@sss.pgh.pa.us 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
--
On 8 February 2011 19:53, Simon Riggs si...@2ndquadrant.com 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
Tom Lane t...@sss.pgh.pa.us 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
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,
Tom Lane t...@sss.pgh.pa.us 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
* 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
yet
2011/2/8 Stephen Frost sfr...@snowman.net:
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
2011/2/8 Stephen Frost sfr...@snowman.net:
* 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
1 - 100 of 151 matches
Mail list logo
