On Wed, 2011-02-09 at 15:39 +0900, Itagaki Takahiro wrote:
> On Wed, Feb 9, 2011 at 14:50, Jeff Davis wrote:
> > 1.
> > The obvious constructor would be:
> > range(1, 10)
> > But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
> > all 4, and it's not obvious how to do that easil
On Wed, Feb 09, 2011 at 02:55:26PM +0900, Itagaki Takahiro wrote:
> On Wed, Feb 9, 2011 at 03:49, Noah Misch wrote:
> > The code still violates the contract of ExecEvalExpr() by calling it with
> > CurrentMemoryContext != econtext->ecxt_per_tuple_memory.
>
> I'm not sure whether we have such cont
On Wed, Feb 9, 2011 at 14:50, Jeff Davis wrote:
> 1.
> The obvious constructor would be:
> range(1, 10)
> But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
> all 4, and it's not obvious how to do that easily.
here is the same issue in table partitioning. Also, We might use th
On Wed, Feb 9, 2011 at 2:02 PM, Simon Riggs wrote:
>> Why did you change the default to on? This would surprise people who are
>> used to PITR.
>
> You pointed out that the code did not match the documented default. So I
> made them match according to the docs.
Well, I meant changing the docs rat
On Wed, Feb 9, 2011 at 4:53 AM, Simon Riggs wrote:
> Committed. Thanks for the patch and the review.
- * We also track the timestamp of the latest applied COMMIT/ABORT record
- * in XLogCtl->recoveryLastXTime, for logging purposes.
+ * We also track the timestamp of the latest applied COMMIT/ABOR
On Tue, 2011-02-08 at 20:43 +0100, Erik Rijkers wrote:
> --
> Documentation:
> --
>
> Section 9.18:
> table 9-42. range functions:
> The following functions are missing (I encountered them in the regression
> tests):
> contained_by()
> range_eq()
I opted not t
There are two issues I'd like to discuss related to constructing range
types from other values.
1.
The obvious constructor would be:
range(1, 10)
But is that [1, 10), (1, 10], (1, 10), or [1, 10]? We need to support
all 4, and it's not obvious how to do that easily. The solution that I
came up
On Tue, 2011-02-08 at 09:10 -0800, Jeff Davis wrote:
> 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 data
On Tue, Feb 08, 2011 at 09:09:48PM -0500, Robert Haas wrote:
> No way to fail is a tall order.
Well, no way to fail due to running out of shared memory in
RegisterPredicateLock/RegisterPredicateLockingXid, but that doesn't
have quite the same ring to it...
> If we don't allocate all the memory up
On Wed, 2011-02-09 at 12:50 +0900, Fujii Masao wrote:
> On Wed, Feb 9, 2011 at 3:30 AM, Simon Riggs wrote:
> > Basic Recovery Control functions for use in Hot Standby. Pause, Resume,
> > Status check functions only. Also, new recovery.conf parameter to
> > pause_at_recovery_target, default on.
>
On Tue, Feb 8, 2011 at 8:31 PM, Itagaki Takahiro
wrote:
> On Tue, Feb 8, 2011 at 13:34, Robert Haas wrote:
>> So how close are we to having a committable version of this? Should
>> we push this out to 9.2?
>
> I think so. The feature is pretty attractive, but more works are required:
> * Re-bas
2010/12/31 Jan Urbański :
> (continuing the flurry of patches)
>
> Here's a patch that stops PL/Python from removing the function's
> arguments from its globals dict after calling it. It's
> an incremental patch on top of the plpython-refactor patch sent in
> http://archives.postgresql.org/message-
On Wed, Feb 9, 2011 at 3:30 AM, Simon Riggs wrote:
> Basic Recovery Control functions for use in Hot Standby. Pause, Resume,
> Status check functions only. Also, new recovery.conf parameter to
> pause_at_recovery_target, default on.
Why did you change the default to on? This would surprise people
Robert Haas writes:
> On Tue, Feb 8, 2011 at 10:25 PM, Tom Lane wrote:
>> My point is that the current restriction to just one containing
>> extension seems to me to be an implementation restriction, rather than
>> something inherent in the concept of extensions. I have no intention of
>> trying
On Tue, Feb 8, 2011 at 10:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>>> Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
>>> assuming that there can be only one owning extension for an object.
>
>> I would assume that we w
Robert Haas writes:
> On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
>> Like ALTER THING SET SCHEMA, ALTER THING SET EXTENSION is implicitly
>> assuming that there can be only one owning extension for an object.
> I would assume that we would enforce that constraint anyway. No?
> Otherwise whe
2011/2/9 Jan Urbański :
> I hope this version does the right thing, while still avoiding the
> performance hit of looking up I/O funcs every time a row is returned.
> Actually, PL/Perl *does* look up the I/O funcs every time, so in the
> worst case I can just drop this optimisation. But let's hope
On Tue, Feb 8, 2011 at 9:48 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... And you could even allow multiple objects:
>> ALTER EXTENSION extension_name ADD object-description [, ...];
>> Which might be handy.
>
> I just thought of a different way of coming at the question, which might
> help us
Robert Haas writes:
> ... And you could even allow multiple objects:
> ALTER EXTENSION extension_name ADD object-description [, ...];
> Which might be handy.
I just thought of a different way of coming at the question, which might
help us make a choice.
Like ALTER THING SET SCHEMA, ALTER THING S
Robert Haas writes:
> On Tue, Feb 8, 2011 at 6:54 PM, Tom Lane wrote:
>> Having now looked at it a bit closer, I think the syntax choice is a
>> complete wash from an implementation standpoint: either way, we'll have
>> a list of bison productions that build AlterObjectExtensionStmt nodes,
>> and
On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan wrote:
> Quite right, but the commitfest manager isn't meant to be a substitute for
> one. Bug fixes aren't subject to the same restrictions of feature changes.
Another option would be to add this here:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1
On Tue, Feb 8, 2011 at 7:23 PM, Dan Ports wrote:
> On Tue, Feb 08, 2011 at 04:04:39PM -0600, Kevin Grittner wrote:
>> (2) The predicate lock and lock target initialization code was
>> initially copied and modified from the code for heavyweight locks.
>> The heavyweight lock code adds 10% to the c
On Tue, Feb 8, 2011 at 6:54 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane writes:
>>> (I was vaguely imagining that it could share most of the COMMENT
>>> infrastructure --- but haven't looked yet).
>
>> Well the code footprint is quite small already.
>
> Having now looked at it a b
On Mon, Feb 7, 2011 at 22:47, Heikki Linnakangas
wrote:
> On Mon, Feb 7, 2011 at 21:17, Noah Misch wrote:
>> The message does not show which foreign table yielded the error. We could
>> evade
>> the problem in this case by adding a file name to the error message in the
>> COPY
>> code,
> Yeah
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker wrote:
> 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
>>
On 02/07/2011 11:30 PM, Robert Haas wrote:
On Tue, Dec 28, 2010 at 9:23 PM, Karl Lehenbauer
wrote:
On Dec 28, 2010, at 7:29 PM, Tom Lane wrote:
This patch appears to be changing a whole lot of stuff that in fact
pg_indent has never changed, so there's something wrong with the way you
are do
On Tue, Feb 8, 2011 at 13:34, Robert Haas wrote:
> So how close are we to having a committable version of this? Should
> we push this out to 9.2?
I think so. The feature is pretty attractive, but more works are required:
* Re-base on synchronized snapshots patch
* Consider to use pipe also on
On 02/08/2011 08:19 PM, Itagaki Takahiro wrote:
On Wed, Feb 9, 2011 at 10:17, Andrew Dunstan wrote:
Isn't this all really a bug fix that should be backpatched, rather than a
commitfest item?
Sure, but we don't have any bug trackers...
Quite right, but the commitfest manager isn't meant to
On Wed, Feb 9, 2011 at 10:17, Andrew Dunstan wrote:
> Isn't this all really a bug fix that should be backpatched, rather than a
> commitfest item?
Sure, but we don't have any bug trackers...
--
Itagaki Takahiro
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 02/07/2011 06:38 AM, Thom Brown wrote:
On 7 February 2011 09:04, Itagaki Takahiro wrote:
On Fri, Feb 4, 2011 at 21:32, Thom Brown wrote:
The issue is that generate_series will not return if the series hits
either the upper or lower boundary during increment, or goes beyond
it. The attac
On Tue, 2011-02-08 at 14:25 -0500, Robert Haas wrote:
> > The patch is a million little decisions: names, catalog structure,
> > interface, representation, general usability, grammar, functionality,
> > etc. Without some checkpoint, the chances that everyone agrees with all
> > of these decisions a
On Tue, Feb 08, 2011 at 04:04:39PM -0600, Kevin Grittner wrote:
> (2) The predicate lock and lock target initialization code was
> initially copied and modified from the code for heavyweight locks.
> The heavyweight lock code adds 10% to the calculated maximum size.
> So I wound up doing that fo
Dimitri Fontaine writes:
> Tom Lane writes:
>> (I was vaguely imagining that it could share most of the COMMENT
>> infrastructure --- but haven't looked yet).
> Well the code footprint is quite small already.
Having now looked at it a bit closer, I think the syntax choice is a
complete wash fro
On Tue, 2011-02-08 at 22:58 +0100, Bernd Helmle wrote:
>
> --On 8. Februar 2011 12:24:11 + Simon Riggs
> wrote:
>
> > Extend ALTER TABLE to allow Foreign Keys to be added without initial
> > validation. FK constraints that are marked NOT VALID may later be
> > VALIDATED, which uses an Share
Robert Haas wrote:
> On Fri, Feb 4, 2011 at 12:02 PM, Oleg Bartunov wrote:
> > Aha,
> >
> > Teodor sent it to the list Dec 28, see
> > http://archives.postgresql.org/message-id/4D1A1677.80300%40sigaev.ru
> >
> > After a month I didn't see any activity on this patch, so I I added it to
> > https://
Dimitri Fontaine writes:
> Tom Lane writes:
>>> [ ALTER object SET EXTENSION versus ALTER EXTENSION ADD object ]
>> OK, that seems like an equally reasonable syntax; although doing it the
>> way I was thinking might have less of a code and documentation footprint
>> (I was vaguely imagining that
On 07/02/11 06:10, Hitoshi Harada wrote:
> 2011/2/7 Jan Urbański :
>> On 04/02/11 16:26, Hitoshi Harada wrote:
>>> 2011/1/28 Jan Urbański :
On 27/01/11 00:41, Jan Urbański wrote:
> I'm also attaching an updated version that should apply on top of my
> github refactor branch (or increme
On 8 February 2011 21:08, Peter Eisentraut wrote:
> On tor, 2011-02-03 at 18:36 -0500, Noah Misch wrote:
>> Looks good and tests well. I've attached the same benchmark script
>> with updated timings, and I've marked the patch Ready for Committer.
>
> Committed. Thanks everyone.
Awesome work Pet
Tom Lane writes:
> OK, that seems like an equally reasonable syntax; although doing it the
> way I was thinking might have less of a code and documentation footprint
> (I was vaguely imagining that it could share most of the COMMENT
> infrastructure --- but haven't looked yet). In any case it see
--On 8. Februar 2011 12:24:11 + Simon Riggs
wrote:
Extend ALTER TABLE to allow Foreign Keys to be added without initial
validation. FK constraints that are marked NOT VALID may later be
VALIDATED, which uses an ShareUpdateExclusiveLock on constraint table and
RowShareLock on referenced
Heikki Linnakangas wrote:
> LOG: shmemsize 3153112
> LOG: actual 2339864
>
> Which is a pretty big overestimate, percentage-wise. Taking
> RWConflictPool into account in PredicateLockShmemSize() fixes the
> underestimate, but makes the overestimate correspondingly larger.
> I've never compare
Tom Lane writes:
> I have gone ahead and committed the core and documentation parts of this
Thank you!
And I'd like to take the time to thank all of you who helped me reach
this goal, but that ranges to about everyone here who I talked to at any
conference those last two or three years (I still
Dimitri Fontaine writes:
> Tom Lane writes:
>> 2. Invent a command "ALTER EXTENSION extname ADD object-description"
>> that simply adds a pg_depend entry marking an existing object as
>> belonging to the extension. I think this was going to be part of the
>> plan anyway for ALTER EXTENSION UPGRA
* Robert Haas (robertmh...@gmail.com) wrote:
> 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 another variant of this syntax - the w
I have gone ahead and committed the core and documentation parts of this
patch, but not as yet any of the contrib changes; that is, all the
contrib modules are still building old-style. I had intended to do it
in two steps all along, so as to get some buildfarm proof for the thesis
that we haven't
Bonjour,
On parle plutôt français sur cette liste d'habitude :)
To reach an English-speaking forum please consider pgsql-general.
michel wildcat writes:
> I am a computer student in belgium, for my academic project I am working to
> an extension of postgresql 9 under win xp, by creating h DLL i
Hello,
I am a computer student in belgium, for my academic project I am working to
an extension of postgresql 9 under win xp, by creating h DLL in Visual C++
2008 - I am new in both environments; To start and understand how does it
works, I tried to compile the example complex.c which is in the
dir
> This discussion reveals that it's time to start making some
> discussions about what can be accomplished for 9.1 and what must be
> postponed to 9.2. The big ones I think we should postpone are:
First off, I think that this is a little premature. As others have
pointed out, the unusual schedu
* 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.
commit 9460c0831f5de71e31823b7e9d8511d2d8124776
Author: Stephen Frost
> o in the recent there are no efforts known to experiment with
> reference types, methods, or rule inference on top of PostgreSQL --
> advice that can be given mostly points to the given documented
> functionality
Correct, AFAIK.
> o extensions of PostgreSQL to support such a kind of usage
On tor, 2011-02-03 at 18:36 -0500, Noah Misch wrote:
> Looks good and tests well. I've attached the same benchmark script
> with updated timings, and I've marked the patch Ready for Committer.
Committed. Thanks everyone.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
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
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
* 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
>
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
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:
> 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
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:
> 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 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
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
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
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
>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
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
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, 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 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 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 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 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 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
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, 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
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
* 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, 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
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 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 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, 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
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 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
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 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
>
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 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
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 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
"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: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
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 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
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 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 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: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 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
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
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
1 - 100 of 151 matches
Mail list logo
