On 07.02.2011 08:00, Shigeru HANADA wrote:
Sorry for late, attached are revised version of FDW API patches which
reflect Heikki's comments except removing catalog lookup via
IsForeignTable(). ISTM that the point is avoiding catalog lookup
during planning, but I have not found when we can set "fo
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 attached patch fixes this behaviour, but should probably be
> done a better way. The first 3 exam
Hi,
Tom Lane writes:
> As I work through the extensions patch, the aspect of it that I like the
> least is the NO USER DATA clause and related functions. I think it's
> badly designed, badly implemented, and doesn't solve the problem.
I'm not loving it either, but wanting to stay general enough
Hi,
I find that ExecInitExpr creates a ExprState tree (and so say the
comments above the function in the source). Also, it seems to decide
which function would get called when the expression is to be evaluated
when ExecQual runs, by setting the function pointer, for example:
bstate->xprstate.eva
Robert Haas writes:
> On Sat, Feb 5, 2011 at 5:41 PM, Tom Lane wrote:
>> Currently, the extensions patch considers that foreign data wrappers,
>> foreign servers, and user mapping objects can all be parts of extensions.
>> This is slightly problematic for pg_dump, where somebody decided to take
>
On 06/02/11 18:23, Tom Lane wrote:
After a bit of thought I believe that we can fix this if we are willing
to teach pg_dump explicitly about extension configuration tables.
The behavior we want for those is for the table schema definition to
never be dumped (the table should always be created by
On 05.02.2011 21:43, Kevin Grittner wrote:
"Kevin Grittner" wrote:
So now that I'm sure we actually do need code there, I'll add it.
In working on this I noticed the apparent need to move two calls to
PredicateLockTuple a little bit to keep them inside the buffer lock.
Without at least a sha
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 attached patch fixes this behaviour, but s
On Mon, Feb 7, 2011 at 16:01, Shigeru HANADA wrote:
> This patch is based on latest FDW API patches which are posted in
> another thread "SQL/MED FDW API", and copy_export-20110104.patch which
> was posted by Itagaki-san.
I have questions about estimate_costs().
* What value does baserel->tuples
Hi all,
I'm trying to debug an ugly error triggered from a "DROP SCHEMA xxx CASCADE"
call inside a function.
The call is the last step of the stored pl/pgsql procedure.
I've verified that removing the "DROP SCHEMA" command from _inside_
the function body and performing it _outside_ it (right afte
On Mon, Feb 07, 2011 at 03:39:39PM +0900, Itagaki Takahiro wrote:
> On Sun, Feb 6, 2011 at 09:01, Noah Misch wrote:
> > Most "parse analysis"-type bits of DoCopy() move to BeginCopy().
>
> It would be possible to move more FROM-only or TO-only members in BeginCopy()
> into their BeginCopyFrom/To(
Suppose you create several file_fdw foreign tables, query them together, and
read(2) returns EIO for one of the files:
[local] postgres=# SELECT * FROM ft0, ft1, ft2;
ERROR: could not read from COPY file: Input/output error
The message does not show which foreign table yielded the error. We cou
Hi,
Jeff Davis writes:
> * Should pg_range reference the btree opclass or the compare function
> directly?
I would say yes. We use the btree opclass in other similar situations.
> * Should subtype_cmp default to the default btree opclass's compare
> function?
My vote is yes too.
> * Ri
On 02/03/2011 04:45 PM, Robert Haas wrote:
> Your data modem is probably doing something funky to your network
> stack, but I don't know what.
Are other network services affected as well? In that case, I'd file a
bug against the modem driver software.
Regards
Markus Wanner
--
Sent via pgsql-h
Hi,
When I ran pg_basebackup with -x, -P and -v options, I encountered
the following odd output.
$ pg_basebackup -D hoge -x -P -v
xlog start point: 0/220
33708/17322 kB (100%) 1/1 tablespaces (
)02)
"02)" is a part of the previously reported message, it looks
odd that t
strk writes:
> Do you have an idea on how to further debug this ?
That usually goes with providing a self-contained test case… that is a
minimum script that creates the function(s) and calls them.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Suppor
On 07.02.2011 14:17, Noah Misch wrote:
Suppose you create several file_fdw foreign tables, query them together, and
read(2) returns EIO for one of the files:
[local] postgres=# SELECT * FROM ft0, ft1, ft2;
ERROR: could not read from COPY file: Input/output error
The message does not show which
I've handled to produce a small testcase:
http://strk.keybit.net/tmp/could_not_open_relation.sql
It still requires postgis (svn), but if anyone has that it might help.
Will try to go on with the reduction.
--strk;
On Mon, Feb 07, 2011 at 12:38:08PM +0100, strk wrote:
> Hi all,
> I'm trying t
I've uploaded also the script output ( CASCADE traces ) :
http://strk.keybit.net/tmp/could_not_open_relation.sql
http://strk.keybit.net/tmp/could_not_open_relation.log
And realized that the relation oid is the one first
requested for deletion. Ie:
DROP TABLE XXX CASCADE;
..
ERROR: could no
On Mon, Feb 07, 2011 at 02:31:49PM +0100, Dimitri Fontaine wrote:
> strk writes:
> > Do you have an idea on how to further debug this ?
>
> That usually goes with providing a self-contained test case⦠that is a
> minimum script that creates the function(s) and calls them.
I've finally complete
On Mon, Feb 7, 2011 at 4:18 AM, Dimitri Fontaine wrote:
> Or do you want to keep some generality here?
I think it might be slightly advantageous to keep some generality,
because some people might already have catalog columns that do this
(but with a different name) or might have other reasons for
Robert Haas wrote:
> On Sun, Feb 6, 2011 at 11:12 PM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Bruce Momjian wrote:
> >>> remove tags.
> >
> >> Sorry, vague commit message (I forgot squash).
> >
> >> Can I will use git ammend to improve this message?
>
> Absolutely not.
>
> > How about gi
On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> Time's running short - do you have an updated patch?
This patch hasn't been updated in more than three weeks. I assume
this should now be marked Returned with Feedback, and we'll revisit
synchronous replication for 9.2?
--
Robert Haas
Ente
Robert Haas wrote:
> On Sun, Feb 6, 2011 at 6:44 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Thu, Jul 22, 2010 at 1:41 AM, Fujii Masao wrote:
> >> > We should enclose -1 with tag.
> >>
> >> A quick survey of the documentation as a whole suggests that we
> >> enclose -1 with in a few
I have analyzed the PostgreSQL protocol using Wireshark (an open source
packet analyzer), and I observed that the PostgreSQL backend, while doing a
COPY ... FROM STDIN, reports errors as soon as possible (especially errors
related to invalid data).
Therefore, the "late" reporting of errors while d
Robert Haas writes:
> On Mon, Feb 7, 2011 at 4:18 AM, Dimitri Fontaine
> wrote:
>> Or do you want to keep some generality here?
> I think it might be slightly advantageous to keep some generality,
Yeah. I had also thought about hard-wiring the WHERE clause, but
there's at least one big object
Richard Huxton writes:
> Possible alternative approach?
> 1. Extension provides list of config tables/views/set-returning
> functions to be dumped via e.g. my_config_tables()
> 2. They get dumped, but each as a TEMP TABLE (need unique names for
> multiple extensions though).
> 3. On restore, ta
2011/2/7 Greg Smith :
> Robert Haas wrote:
>>
>> With the fsync queue compaction patch applied, I think most of this is
>> now not needed. Attached please find an attempt to isolate the
>> portion that looks like it might still be useful. The basic idea of
>> what remains here is to make the back
On Mon, 7 Feb 2011 21:00:53 +0900
Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 16:01, Shigeru HANADA
> wrote:
> > This patch is based on latest FDW API patches which are posted in
> > another thread "SQL/MED FDW API", and copy_export-20110104.patch which
> > was posted by Itagaki-san.
>
> I
Cédric Villemain wrote:
Is it worth a new thread with the different IO improvements done so
far or on-going and how we may add new GUC(if required !!!) with
intelligence between those patches ? ( For instance, hint bit IO limit
needs probably a tunable to define something similar to
hint_write_co
Robert Haas wrote:
> On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
> > Uh, in this C comment:
> >
> > + ? ? ? ?* or not we want to take the time to write it. ?We allow up to 5%
> > of
> > + ? ? ? ?* otherwise-not-dirty pages to be written due to hint bit changes,
> >
> > 5% of what? ?5% of
There are some things that the current extensions patch leaves
indeterminate during a dump and reload cycle, which strikes me
as a bad thing.
One is ownership. Since we don't record the identity of the user who
created an extension, there's no way for pg_dump to ensure that it's
recreated by the
The update on the work to push towards a bigger pgbench is that I now
have the patch running and generating databases larger than any
previously possible scale:
$ time pgbench -i -s 25000 pgbench
...
25 tuples done.
...
real258m46.350s
user14m41.970s
sys0m21.310s
$ psql -d
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> I'm sending small patch for textsend. It reduces unnecessary copies, and
> memory usage for duplication of varlena data. May you look?
This code will break the day that text and bytea don't have the same
internal representation, which seems likely to b
Vaibhav Kaushal writes:
> Hi,
> I find that ExecInitExpr creates a ExprState tree (and so say the
> comments above the function in the source). Also, it seems to decide
> which function would get called when the expression is to be evaluated
> when ExecQual runs, by setting the function pointer, f
Tom Lane writes:
> one I'd been thinking about a bit was OIDs of modules this one depends
> on. The current design doesn't cope very well with modules that depend
> on other ones.
Or even at all. I guess here "modules" is referring to shared object
libraries, right? Or are you already thinking
Robert Haas wrote:
> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> > Time's running short - do you have an updated patch?
>
> This patch hasn't been updated in more than three weeks. I assume
> this should now be marked Returned with Feedback, and we'll revisit
> synchronous replication
Dimitri Fontaine writes:
> Tom Lane writes:
>> one I'd been thinking about a bit was OIDs of modules this one depends
>> on. The current design doesn't cope very well with modules that depend
>> on other ones.
> Or even at all. I guess here "modules" is referring to shared object
> libraries,
On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
> > Time's running short - do you have an updated patch?
>
> This patch hasn't been updated in more than three weeks. I assume
> this should now be marked Returned with Feedback, and we'l
On 02/04/2011 05:49 AM, Itagaki Takahiro wrote:
Here is a demonstration to support jagged input files. It's a patch
on the latest patch. The new added API is:
bool NextLineCopyFrom(
[IN] CopyState cstate,
[OUT] char ***fields, [OUT] int *nfields, [OUT] Oid *tupleOid)
It j
Tom Lane writes:
> One is ownership. Since we don't record the identity of the user who
> created an extension, there's no way for pg_dump to ensure that it's
> recreated by the same user. I think we'll regret that in future even
> if you don't think it's problematic today. In particular, I for
On Feb6, 2011, at 19:23 , Tom Lane wrote:
> After a bit of thought I believe that we can fix this if we are willing
> to teach pg_dump explicitly about extension configuration tables.
> The behavior we want for those is for the table schema definition to
> never be dumped (the table should always b
On Sun, 2011-02-06 at 20:10 +0100, Erik Rijkers wrote:
> I was trying
> where intrange @> integer
>
> which admittedly is not in the documentation,
> but does already half work, and would be really
> convenient to have. As it stands the construct
> seems to fail after ANALYZE, when there is m
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think we'd better add an extowner column to pg_extension.
> Agreed. There's no need to have it now but we will add it at some
> point. So if now is when that works the best for you, I'm happy to see
> that happen :)
> Would it help that I prep
Florian Pflug writes:
> We could avoid the need for a per-row "system_data" flag if we required
> extensions to split user-editable and system-provided configuration data
> into different tables. For convenient access to the configuration data,
> the extension could let the user-editable table inh
On Mon, 2011-02-07 at 13:33 +0100, Dimitri Fontaine wrote:
> Hi,
>
> Jeff Davis writes:
> > * Should pg_range reference the btree opclass or the compare function
> > directly?
>
> I would say yes. We use the btree opclass in other similar situations.
Ok, but what should the parameter to CREA
On Mon, Feb 7, 2011 at 10:48 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
>> > Uh, in this C comment:
>> >
>> > + ? ? ? ?* or not we want to take the time to write it. ?We allow up to 5%
>> > of
>> > + ? ? ? ?* otherwise-not-dirty pages to
peder...@ccsscorp.com ("Bill Pedersen") writes:
> I look forward to hearing from people in the PostgreSQL community as well as
> from others interested in this effort.
To a number of us, it's academically interesting, though, as we don't
have VMS systems, it's not likely to be super-easy to assist
Tom Lane writes:
> No, I've hacked the code enough already that merging would be painful.
> I'll keep working on it.
I supposed so much, but got to ask :)
> Oh, duh, I'd forgotten about the OverrideSearchPath usage. So never
> mind the above claim. But I still think it'd be a good idea to ensu
Jeff Davis writes:
> Ok, but what should the parameter to CREATE TYPE ... AS RANGE be then?
>
> CREATE TYPE foo AS RANGE (
> SUBTYPE = ...
> SUBTYPE_BTREE_OPERATOR_CLASS = ...
> );
>
> is a little verbose. Ideas?
I would think
CREATE TYPE foo AS RANGE (bar) USING (btree_ops);
The USING cl
On Mon, Feb 7, 2011 at 11:33 AM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
>> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
>> > Time's running short - do you have an updated patch?
>>
>> This patch hasn't been updated in more than three weeks. I assume
>>
On Mon, Feb 7, 2011 at 12:28 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 11:33 AM, Simon Riggs wrote:
>> On Mon, 2011-02-07 at 09:55 -0500, Robert Haas wrote:
>>> On Sun, Jan 30, 2011 at 11:44 AM, Robert Haas wrote:
>>> > Time's running short - do you have an updated patch?
>>>
>>> This patc
Kevin Grittner wrote:
> "Kevin Grittner" wrote:
>> Jeff Davis wrote:
>>
>>> What does PredicateLockTuple do that needs a share lock? Does a
>>> pin suffice?
>>
>> If one process is reading a tuple and another is writing it
>> (e.g., UPDATE or DELETE) the concern is that we need to be able
>> t
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Really? I thought the idea for the last CF of a development cycle was
that it kept going till we'd dealt with everything. Arbitrarily
rejecting stuff we haven't dealt with doesn't seem fair.
re
On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
> Yeah, this is another approach that one could take instead of having
> per-row flags. I'm not sure that it's better, much less so much better
> that we should force extensions to do it that way and not the other.
> But it's definitely another argument
Dimitri Fontaine writes:
> Tom Lane writes:
>> Quite aside from search path, cross-extension dependencies simply aren't
>> going to work unless pg_dump knows about them so it can load the
>> extensions in the right order. I had forgotten about the earthdistance
>> case, but given that I think we
On Feb 7, 2011, at 9:20 AM, Dimitri Fontaine wrote:
> Also, I didn't bite this bullet, but maybe we should provide core PLs as
> extension. Then CREATE LANGUAGE would maybe get deprecated and only
> valid when used in an extension's script — or the next patch (UPGRADE)
> will take care of create
On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
> Interesting point. It's all right at the moment because I tweaked
> pg_dump_sort.c so that procedural languages are dumped before modules.
> But maybe we should convert the PLs to modules.
s/modules/extensions/?
David
--
Sent via pgsql-hackers ma
"David E. Wheeler" writes:
> On Feb 7, 2011, at 8:57 AM, Tom Lane wrote:
>> Yeah, this is another approach that one could take instead of having
>> per-row flags. I'm not sure that it's better, much less so much better
>> that we should force extensions to do it that way and not the other.
>> But
"David E. Wheeler" writes:
> On Feb 7, 2011, at 9:51 AM, Tom Lane wrote:
>> Interesting point. It's all right at the moment because I tweaked
>> pg_dump_sort.c so that procedural languages are dumped before modules.
>> But maybe we should convert the PLs to modules.
> s/modules/extensions/?
Yea
On Mon, 2011-02-07 at 12:39 -0500, Robert Haas 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 don't know for sure how quite I'll
> be able to get up to speed o
On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Well, the current CommitFest ends in one week, ...
>
> Really? I thought the idea for the last CF of a development cycle was
> that it kept going till we'd dealt with everything. Arbitrarily
> rejecting stuff we haven
On Mon, Feb 7, 2011 at 12:59 PM, Simon Riggs wrote:
> On Mon, 2011-02-07 at 12:39 -0500, Robert Haas 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 don't
Dimitri Fontaine writes:
> Tom Lane writes:
>> I think we'd better add an extowner column to pg_extension.
> Agreed. There's no need to have it now but we will add it at some
> point. So if now is when that works the best for you, I'm happy to see
> that happen :)
BTW, on trying this I notic
I wrote:
> ... So where I think we're going to end up
> is adding a clause along the line of "USING list-of-extension-names"
> to CREATE EXTENSION, storing those dependencies explicitly, and having
> the CREATE EXTENSION code set search_path to the target schema followed
> by the target schema(s) o
On sön, 2011-01-30 at 14:52 -0800, Jeff Davis wrote:
> * naming issues:
> - period -> tsrange ?
> - periodtz -> tstzrange ?
> - intrange -> int4range
Have you considered a grammar approach like for arrays, so that you
would write something like
CREATE TABLE ... (
foo RANGE OF in
Greg Smith wrote:
> As a larger statement on this topic, I'm never very excited about
> redesigning here starting from any point other than "saw a
> bottleneck doing on a production system". There's a long list
> of such things already around waiting to be addressed, and I've
> never seen any g
Tom Lane writes:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something like
>
> requires = '
2011/2/7 Robert Haas :
> On Mon, Feb 7, 2011 at 10:48 AM, Bruce Momjian wrote:
>> Robert Haas wrote:
>>> On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
>>> > Uh, in this C comment:
>>> >
>>> > + ? ? ? ?* or not we want to take the time to write it. ?We allow up to
>>> > 5% of
>>> > + ? ? ?
2011/2/7 Cédric Villemain :
> 2011/2/7 Robert Haas :
>> On Mon, Feb 7, 2011 at 10:48 AM, Bruce Momjian wrote:
>>> Robert Haas wrote:
On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
> Uh, in this C comment:
>
> + ? ? ? ?* or not we want to take the time to write it. ?We al
Robert Haas writes:
> done in the time available is another thing entirely. I do NOT want
> to still be working on the items for this CommitFest in June - that's
> about when I'd like to be releasing beta3.
Except that's not how we work here. You want to change that with
respect to the release
On Mon, 2011-02-07 at 17:59 +, Simon Riggs wrote:
> On Mon, 2011-02-07 at 12:39 -0500, Robert Haas 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 d
Dimitri Fontaine writes:
> That said, we should do something about ALTER EXTENSION SET SCHEMA and
> the relocatable property. I'm thinking that an extension stops being
> relocatable as soon as any of its reverse dependencies (all the tree) is
> not relocatable.
If you're worried about that, the
On Mon, Feb 7, 2011 at 2:09 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> done in the time available is another thing entirely. I do NOT want
>> to still be working on the items for this CommitFest in June - that's
>> about when I'd like to be releasing beta3.
>
> Except that's not how we
>> 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 don't know for sure how quite I'll
>> be able to get up to speed on it, so if someone who is more familiar
>> with t
On Feb 7, 2011, at 10:23 AM, Tom Lane wrote:
> On reflection, the set of extensions that an extension depends on is
> obviously a property of the extension, which means it ought to be
> specified in the extension's control file, not in the CREATE EXTENSION
> command. So now I'm thinking something
On Mon, Feb 7, 2011 at 2:56 PM, Dave Page wrote:
> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
>>>
>>> Really? I thought the idea for the last CF of a
On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... Well, the current CommitFest ends in one week, ...
>>
>> Really? I thought the idea for the last CF of a development cycle was
>> that it kept going till we'd dea
On 02/07/2011 01:39 AM, Itagaki Takahiro wrote:
file_fdw uses CopyFromErrorCallback() to give errors the proper context. The
function uses template strings like "COPY %s, line %d", where %s is the name of
the relation being copied. Presumably file_fdw and other features using this
API woul
Tom Lane writes:
> If you're worried about that, then it's questionable whether ALTER
> EXTENSION SET SCHEMA makes sense at all, ever. I don't see any reason
> to think that an extension is more fragile for this purpose than any
> other random SQL dependencies. Also, an extension being relocatab
Robert Haas wrote:
> Dave Page wrote:
>> Robert Haas wrote:
>>> Tom Lane wrote:
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Really? I thought the idea for the last CF of a development
cycle was that it kept going till we'd dealt with ev
On Mon, Feb 7, 2011 at 8:59 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 2:56 PM, Dave Page wrote:
>> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
Robert Haas writes:
> ... Well, the current CommitFest ends in one week, ...
Robert Haas writes:
> I'm not trying to bypass compromising, and I don't know what makes you
> think otherwise. I am trying to ensure that the CommitFest wraps up
Well, I'm too tired to allow myself posting such comments, sorry to have
left the previous mail through. More than one commit fest s
On 2/7/11 11:41 AM, Robert Haas wrote:
> However, I don't want to prolong
> the CommitFest indefinitely in the face of patches that the authors
> are not actively working on or can't finish in the time available, or
> where there is no consensus that the proposed change is what we want.
> I believe
On Mon, Feb 7, 2011 at 3:06 PM, Dave Page wrote:
>>> Rejecting stuff because we haven't gotten round to dealing with it in
>>> such a short period of time is a damn good way to limit the number of
>>> contributions we get. I don't believe we've agreed at any point that
>>> the last commitfest shou
On Mon, 2011-02-07 at 12:24 -0800, Josh Berkus wrote:
> +1.
>
> I, for one, would vote against extending beta if Sync Rep isn't ready
> yet. There's plenty of other "big features" in 9.1, and Sync Rep will
> benefit from having additional development time given the number of
> major spec points
On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
> You're moving the bar. It DOES say that the CommitFest will end on
> February 15th. Now, if we want to have a discussion about changing
> that, let's have that discussion (perhaps on a thread where the
> subject has something to do with the to
On Mon, Feb 7, 2011 at 3:14 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> I'm not trying to bypass compromising, and I don't know what makes you
>> think otherwise. I am trying to ensure that the CommitFest wraps up
>
> Well, I'm too tired to allow myself posting such comments, sorry to h
Hello hackers,
Just FYI, the CFP for PgEast in NYC closes in three days.
https://www.postgresqlconference.org/talk_types
Sincerely,
JD
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engine
On Mon, Feb 7, 2011 at 3:34 PM, Dave Page wrote:
> On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
>> You're moving the bar. It DOES say that the CommitFest will end on
>> February 15th. Now, if we want to have a discussion about changing
>> that, let's have that discussion (perhaps on a thr
On Mon, Feb 7, 2011 at 9:46 PM, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 3:34 PM, Dave Page wrote:
>> On Mon, Feb 7, 2011 at 9:25 PM, Robert Haas wrote:
>>> You're moving the bar. It DOES say that the CommitFest will end on
>>> February 15th. Now, if we want to have a discussion about chang
On Wed, 2011-02-02 at 21:21 -0500, Robert Haas wrote:
> On Tue, Feb 1, 2011 at 3:17 AM, Simon Riggs wrote:
> > ERRCODE_DATABASE_DROPPED57P04 looks best
>
> So I guess the only remaining issue is whether we should distinguish
> the error message text, as well as the error codes. Tom was in
Dimitri Fontaine writes:
> Tom Lane writes:
>> If you're worried about that, then it's questionable whether ALTER
>> EXTENSION SET SCHEMA makes sense at all, ever. I don't see any reason
>> to think that an extension is more fragile for this purpose than any
>> other random SQL dependencies. Al
dp...@pgadmin.org (Dave Page) writes:
> On Mon, Feb 7, 2011 at 6:55 PM, Robert Haas wrote:
>> On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Well, the current CommitFest ends in one week, ...
>>>
>>> Really? I thought the idea for the last CF of a development
Just from curious may I ask in which direction this will go, and how this will
affect performance of text and binary format?
Actually I started to make smaller improvements, and I think about one big to
encode text (when client and server encoding are different) directly to
StringInfo, without
On Mon, 2011-02-07 at 15:25 -0500, Robert Haas wrote:
> I would certainly appreciate it if
> everyone could at least credit me with acting in good faith.
I think you are, if that helps.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training a
Kevin Grittner wrote:
There are occasional posts from those wondering why their read-only
queries are so slow after a bulk load, and why they are doing heavy
writes. (I remember when I posted about that, as a relative newbie,
and I know I've seen others.)
Sure; I created http://wiki.postgre
On 06.02.2011 20:30, Kevin Grittner wrote:
"Kevin Grittner" wrote:
I'm working on it now, and hope to have it all settled down today.
Done and pushed to the git repo. Branch serializable on:
git://git.postgresql.org/git/users/kgrittn/postgres.git
Heikki: I'm back to not having any outstan
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 don't know for sure how quite I'll
> >> be able to get up
On Mon, Feb 7, 2011 at 23:14, Heikki Linnakangas
wrote:
> On 06.02.2011 20:30, Kevin Grittner wrote:
>>
>> "Kevin Grittner" wrote:
>>
>>> I'm working on it now, and hope to have it all settled down today.
>>
>> Done and pushed to the git repo. Branch serializable on:
>>
>> git://git.postgresql.o
1 - 100 of 130 matches
Mail list logo