On Sat, Feb 5, 2011 at 04:50, Joachim Wieland wrote:
> On Thu, Feb 3, 2011 at 11:46 PM, Itagaki Takahiro
> wrote:
>> It might be better to remove Windows-specific codes from the first try.
>> I doubt Windows message queue is the best API in such console-based
>> application. I hope we could use t
On Fri, Feb 4, 2011 at 2:46 PM, Robert Haas wrote:
> On Fri, Feb 4, 2011 at 2:44 PM, Tom Lane wrote:
>> While poking at the extensions patch I noticed that doDeletion() and
>> getObjectDescription() both seem to be missing cases for
>> OCLASS_FOREIGN_TABLE. Surely this is broken.
>
> I'll look i
On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch wrote:
> Done as attached. This preserves compatibility with our current handling of
> composite type dependencies. The rest you've seen before.
OK, so I took a look at this in more detail today. The current logic
for table rewrites looks like this:
Josh Berkus wrote:
So: Linux flavor? Kernel version? Disk system and PG directory layout?
OS configuration and PostgreSQL settings are saved into the output from
the later runs (I added that somewhere in the middle):
http://www.2ndquadrant.us/pgbench-results/294/pg_settings.txt
That's
Mark Kirkwood wrote:
Are you going to do some runs with ext4? I'd be very interested to see
how it compares (assuming that you are on a kernel version 2.6.32 or
later so ext4 is reasonably stable...).
Yes, before I touch this system significantly I'll do ext4 as well, and
this is running the
Magnus Hagander wrote:
> On Thu, Feb 3, 2011 at 04:40, Bruce Momjian wrote:
> > I am seeing the following compiler warning for the past few days:
> >
> > ? ? ? ?basebackup.c:213: warning: variable `ptr' might be clobbered by
> > ? ? ? ?`longjmp' or `vfork'
> >
> > and I see this comment in the fil
On Thu, Feb 3, 2011 at 11:46 PM, Itagaki Takahiro
wrote:
> I think we have 2 important technical issues here:
> * The consistency is not perfect. Each transaction is started
> with small delays in step 1, but we cannot guarantee no other
> transaction between them.
This is exactly where the
Tom Lane wrote:
> I wrote:
> > In particular, now that there's a distinction between smgr flush
> > and relcache flush, maybe we could associate targblock reset with
> > smgr flush (only) and arrange to not flush the smgr level during
> > ANALYZE --- basically, smgr flush would only be needed when
On Tue, Feb 1, 2011 at 10:02 AM, Euler Taveira de Oliveira
wrote:
> Em 14-01-2011 17:41, Jaime Casanova escreveu:
>>
>> Here is a patch that implements "named restore points".
>>
> Sorry, I was swamped with work. :(
>
> Your patch no longer applied so I rebased it and slightly modified it.
> Revie
On Sat, Feb 5, 2011 at 04:24, Dimitri Fontaine wrote:
>> In math class, maybe. But in programming, no. Multiset is a
>> datatype. Array is a different datatype. There is no reason why we
>> need to clutter our parser with extra keywords to support a
>> non-standard feature extension.
>
> My un
I see there was significant discussion back in February 2010 as to an
OpenVMS port of PostgreSQL.
I am interested in seeing PostgreSQL ported to OpenVMS as it will then
faciliate other Open Source ports - like OpenBravo.
HP OpenVMS Engineering is encouraging Open Source ports. A set of machines
On Fri, Feb 4, 2011 at 12:31 PM, Greg Smith wrote:
> -Switching from ext3 to xfs gave over a 3X speedup on the smaller test set:
> from the 600-700 TPS range to around 2200 TPS. TPS rate on the larger data
> set actually slowed down a touch on XFS, around 10%. Still, such a huge win
> when it's
On 05/02/11 07:31, Greg Smith wrote:
Switching to a new thread for this summary since there's some much
more generic info here...at this point I've finished exploring the
major Linux filesystem and tuning options I wanted to, as part of
examining changes to the checkpoint code. You can find al
I wrote:
> repeatable read
> [best] Time: 51.150 ms
> serializable
> [best] Time: 52.089 ms
It occurred to me that taking the best time from each was likely to
give a reasonable approximation of the actual overhead of SSI in
this situation. That came out to about 1.8% in this (small) set of
I wrote:
>> If this works, it would be a very minor change, which might
>> eliminate a lot of that overhead for many common cases.
With that change in place, I loaded actual data from one county for
our most heavily searched table and searched it on the most heavily
searched index. I returned
Greg,
Thanks for doing these tests!
So: Linux flavor? Kernel version? Disk system and PG directory layout?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> I have reviewed is_absolute_path() and have implemented
> >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
> >>> Win32; patch attached.
> >>
> >> This patch appears to remove
Noah Misch wrote:
> On Thu, Feb 03, 2011 at 05:53:28PM +0200, Peter Eisentraut wrote:
> > On tor, 2011-02-03 at 00:10 -0500, Noah Misch wrote:
> > > > This is good stuff. I'll send you a new patch in a day or three for
> > > > perhaps another round of performance tests. Some of the other
> > > is
Tom Lane writes:
> While I'm looking at this ... what is the rationale for treating rewrite
> rules as members of extensions, ie, why does the patch touch
> rewriteDefine.c? ISTM a rule is a property of a table and could not
> sensibly be an independent member of an extension. If there is a use
While I'm looking at this ... what is the rationale for treating rewrite
rules as members of extensions, ie, why does the patch touch
rewriteDefine.c? ISTM a rule is a property of a table and could not
sensibly be an independent member of an extension. If there is a use
for that, why are table co
On Fri, Feb 4, 2011 at 1:16 PM, Robert Haas wrote:
> On Fri, Feb 4, 2011 at 1:04 PM, Tom Lane wrote:
>> I agree, that is not cool.
>
> OK, changed.
It looks like pipe.c is full of backend-specific error-reporting code.
I could rewrite it to work in the frontend, but since it's obviously
not use
Tom Lane writes:
> Dimitri Fontaine writes:
>> Do you really think the new dependency type has to be re-usable easily
>> in the future? DEPENDENCY_EXTENSION ('e') would look fine by me.
>
> Hmm ... Haas suggested that too, but to me it seems confusing: which way
> does such a dependency point?
2011/2/4 Robert Haas :
> On Fri, Jan 28, 2011 at 2:19 PM, Pavel Stehule
> wrote:
>> 2011/1/28 Robert Haas :
>>> On Tue, Jan 25, 2011 at 11:29 AM, Pavel Stehule
>>> wrote:
variant a) my first patch - detoast on first usage with avoiding to
useless detoast checking
variant b) my fi
Dimitri Fontaine writes:
> Tom Lane writes:
>> What are the guc.c changes in this patch? They appear completely
>> unrelated to the topic.
> Right. Didn't spot them. Sorry for the noise in the patch, it must be
> a merge problem in my repository. Do you want me to clean that up or is
> it al
Dimitri Fontaine writes:
> Tom Lane writes:
>> If we go with a new deptype, I was thinking of using 'm' (macro
>> DEPENDENCY_MEMBER) but am not set on that. Have we been using any
>> particular term to refer to the objects that belong to an extension?
> Do you really think the new dependency ty
On Fri, Feb 4, 2011 at 2:44 PM, Tom Lane wrote:
> While poking at the extensions patch I noticed that doDeletion() and
> getObjectDescription() both seem to be missing cases for
> OCLASS_FOREIGN_TABLE. Surely this is broken.
I'll look into fixing this.
--
Robert Haas
EnterpriseDB: http://www.e
While poking at the extensions patch I noticed that doDeletion() and
getObjectDescription() both seem to be missing cases for
OCLASS_FOREIGN_TABLE. Surely this is broken.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
Tom Lane writes:
> The extensions patch currently records that an object is part of an
> extension by making a pg_depend entry with deptype 'i' (INTERNAL).
> While that has the behavior we want, I wonder whether it wouldn't
> be smarter in the long run to invent a new deptype for this purpose.
I
On Fri, Feb 4, 2011 at 2:08 PM, Greg Smith wrote:
> -The total number of buffers I'm computing based on the checkpoint writes
> being sorted it not a perfect match to the number reported by the
> "checkpoint complete" status line. Sometimes they are the same, sometimes
> not. Not sure why yet.
On Fri, Feb 4, 2011 at 2:08 PM, Tom Lane wrote:
> The extensions patch currently records that an object is part of an
> extension by making a pg_depend entry with deptype 'i' (INTERNAL).
> While that has the behavior we want, I wonder whether it wouldn't
> be smarter in the long run to invent a ne
Tom Lane writes:
> What are the guc.c changes in this patch? They appear completely
> unrelated to the topic.
Right. Didn't spot them. Sorry for the noise in the patch, it must be
a merge problem in my repository. Do you want me to clean that up or is
it already to late?
Regards,
--
Dimitri
On 02/04/2011 02:08 PM, Tom Lane wrote:
The extensions patch currently records that an object is part of an
extension by making a pg_depend entry with deptype 'i' (INTERNAL).
While that has the behavior we want, I wonder whether it wouldn't
be smarter in the long run to invent a new deptype for
Robert Haas writes:
> On Fri, Feb 4, 2011 at 1:15 PM, Itagaki Takahiro
> wrote:
>> Multisets. But I chose the same function name and syntax because
>> arrays *are* multisets by definition.
>
> In math class, maybe. But in programming, no. Multiset is a
> datatype. Array is a different datatype
The extensions patch currently records that an object is part of an
extension by making a pg_depend entry with deptype 'i' (INTERNAL).
While that has the behavior we want, I wonder whether it wouldn't
be smarter in the long run to invent a new deptype for this purpose.
We do not want people confusi
As already mentioned in the broader discussion at
http://archives.postgresql.org/message-id/4d4c4610.1030...@2ndquadrant.com
, I'm seeing no solid performance swing in the checkpoint sorting code
itself. Better sometimes, worse others, but never by a large amount.
Here's what the statistics p
2011/2/5 Tom Lane :
> Hitoshi Harada writes:
>> 2011/2/5 Tom Lane :
>>> Yeah, putting backend-only stuff into that header is a nonstarter.
>
>> Do you mean you think it' all right to define
>> pg_cached_encoding_conversion() in pg_conversion_fn.h?
>
> That seems pretty random too. I still think y
Dimitri Fontaine writes:
> Tom Lane writes:
>> Actually, I was about to pick up and start working on the whole
>> extensions patch series, but now I'm confused as to what and where is
>> the latest version.
> Ok, here's what I have, attached, as patch v30. What Itagaki just sent
> applies on to
On Fri, Feb 4, 2011 at 10:29, Andrew Dunstan wrote:
>> Anyone object to fixing the above as part of this patch? That is
>> making plperl_(build_tuple_result, modify_tuple, return_next,
>> hash_from_tuple) handle array and hash (composite/row) types
>> consistently? And _that_ would be to recurse a
Michael Banck wrote:
On Sat, Jan 15, 2011 at 05:47:24AM -0500, Greg Smith wrote:
For example, the pre-release Squeeze numbers we're seeing are awful so
far, but it's not really done yet either.
Unfortunately, it does not look like Debian squeeze will change any more
(or has changed mu
Switching to a new thread for this summary since there's some much more
generic info here...at this point I've finished exploring the major
Linux filesystem and tuning options I wanted to, as part of examining
changes to the checkpoint code. You can find all the raw data at
http://www.2ndquadr
I have toyed around with KNN a little and I am pretty impressed when it comes
to the results we have seen in the GIS world.
Given the infrastructure we have at the moment I wonder if KNN can help to
speedup queries like that:
SELECT ... WHERE fti_query ORDER BY numeric_col LIMIT x
The use case
On Fri, Feb 4, 2011 at 1:15 PM, Itagaki Takahiro
wrote:
> On Sat, Feb 5, 2011 at 03:04, Robert Haas wrote:
I am still not in favor of adding this syntax.
>>>
>>> I also don't like the syntax, but unfortunately, almost all of
>>> them are in the SQL standard :-(.
>>
>> The standard specifies
On Fri, Feb 4, 2011 at 1:04 PM, Tom Lane wrote:
> I agree, that is not cool.
OK, changed.
> BTW, I noted here that errcodes.h doesn't seem to get built till after
> src/port/ is built. That seems wrong --- there is definitely code in
> there that needs to throw errors.
It does, actually, but i
On Sat, Feb 5, 2011 at 03:04, Robert Haas wrote:
>>> I am still not in favor of adding this syntax.
>>
>> I also don't like the syntax, but unfortunately, almost all of
>> them are in the SQL standard :-(.
>
> The standard specifies this syntax for arrays, or for multisets?
Multisets. But I chose
Dne 4.2.2011 03:37, Greg Smith napsal(a):
> Thinking I should start with why I think this patch is neat...most of
> the servers I deal with are up 24x7 minus small amounts of downtime,
> presuming everyone does their job right that is. In that environment,
> having a starting timestamp for when th
I wrote:
> I just had a thought -- we already have the LocalPredicateLockHash
> HTAB to help with granularity promotion issues without LW
> locking. Offhand, I can't see any reason we couldn't use this for
> an initial check for a relation level lock, before going through
> the more rigorous pas
On Fri, Feb 4, 2011 at 1:02 PM, Itagaki Takahiro
wrote:
> On Sat, Feb 5, 2011 at 02:29, Robert Haas wrote:
>> I am still not in favor of adding this syntax.
>
> I also don't like the syntax, but unfortunately, almost all of
> them are in the SQL standard :-(.
The standard specifies this syntax f
Robert Haas writes:
> mingw is unhappy with my latest stab at fixing the mess created by the
> errcodes patch last night. It appears that there are several files in
> src/port that include "postgres.h" even when FRONTEND is defined. For
> example, chklocale.c does this, which looks good:
> #ifn
On Sat, Feb 5, 2011 at 02:29, Robert Haas wrote:
> I am still not in favor of adding this syntax.
I also don't like the syntax, but unfortunately, almost all of
them are in the SQL standard :-(. In addition, Oracle already
uses the same feature with the special syntax, though true multiset
data
On 02/03/2011 08:29 PM, 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 function won't bring surprises
there. I've also added check_stack_dept
On Mon, Jan 31, 2011 at 1:49 AM, Itagaki Takahiro
wrote:
> I removed collect() aggregate function because the result type is MULTISET
> in the spec. I keep all of other functions and operators because they won't
> break anything in the standard. When we will have true MULTISET data type,
> we can
Heikki Linnakangas wrote:
> The logic of PredicateLockAcquire is:
>
> 1. Check if we already have a lock on the tuple.
> 2. Check if we already have a lock on the page.
> 3. Check if we already have a lock on the relation.
>
> So if you're accessing a lot of rows, so that your lock is
> promot
mingw is unhappy with my latest stab at fixing the mess created by the
errcodes patch last night. It appears that there are several files in
src/port that include "postgres.h" even when FRONTEND is defined. For
example, chklocale.c does this, which looks good:
#ifndef FRONTEND
#include "postgres
2011/1/11 Jan Urbański :
> Here's a patch that adds a few PL/Python functions for quoting strings.
> It's an incremental patch on top of the plpython-refactor patch sent in
> http://archives.postgresql.org/message-id/4d135170.3080...@wulczer.org.
>
> Git branch for this patch:
> https://github.com/
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://commitfest.postgresql.org/action/patch_view?id=350 Jan 21
Now, I realised it was too late. Added
"David E. Wheeler" writes:
> Dim, I haven't followed that closely lately, but is the ALTER
> EXTENSION UPGRADE bit still a separate patch?
Yes it is. It's an incremental that apply on top of the extension patch
and get its own patch entry on the commit fest application:
https://commitfest.pos
On Feb 4, 2011, at 8:54 AM, Robert Haas wrote:
> Yeah, I understand. I believe Tom said he was going to look at the
> basic functionality with an eye toward commit, and I hope to look at
> it as well, either before or after it gets committed. Time
> permitting, I'd then like to look at this, but
On Fri, Feb 4, 2011 at 11:07 AM, Heikki Linnakangas
wrote:
> On 04.02.2011 15:37, Robert Haas wrote:
>>
>> Not sure. How much benefit do we get from upgrading tuple locks to
>> page locks? Should we just upgrade from tuple locks to full-relation
>> locks?
>
> Hmm, good question. Page-locks are t
On Fri, Feb 4, 2011 at 11:48 AM, David E. Wheeler wrote:
> Robert, I think that the core extension if pretty uncontroversial, modulo
> some minor issues. It's the upgrade process that's more controversial. I
> think the case can be made to accept even that part as Dim has written it,
> because
Hitoshi Harada writes:
> 2011/2/5 Tom Lane :
>> Yeah, putting backend-only stuff into that header is a nonstarter.
> Do you mean you think it' all right to define
> pg_cached_encoding_conversion() in pg_conversion_fn.h?
That seems pretty random too. I still think you've designed this API
badly
On Feb 4, 2011, at 7:48 AM, Robert Haas wrote:
> I'd like to answer this question, but I have not had enough time to
> read through this patch in detail, because there are 97 patches in
> this CommitFest. The point I'm trying to make, however, is
> procedural. We shouldn't commit anything at the
Heikki Linnakangas wrote:
> On 04.02.2011 14:30, Kevin Grittner wrote:
>> OK. So it looks like right now it will move to btvacuumpage(),
>> right before the call to RecordFreeIndexPage(), and we will need
>> to add it to one spot each in the GiST and GIN AMs, when we get
>> to those. Would you
2011/2/5 Tom Lane :
> Hitoshi Harada writes:
>> 2011/2/5 Tom Lane :
>>> 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 CRE
Hitoshi Harada writes:
> 2011/2/5 Tom Lane :
>> 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.
> What about
2011/2/5 Tom Lane :
> Itagaki Takahiro writes:
>> * Syntax: ENCODING encoding vs. ENCODING 'encoding'
>> We don't have to quote encoding names in the patch, but we always need
>> quotes for CREATE DATABASE WITH ENCODING. I think we should modify
>> CREATE DATABASE to accept unquoted encoding names
2011/1/28 Jan Urbański :
> On 23/12/10 15:15, Jan Urbański wrote:
>> Here's a patch implementing custom parsers for data types mentioned in
>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>> an incremental patch on top of the plpython-refactor patch sent eariler.
>
> Upda
On Fri, Jan 28, 2011 at 2:19 PM, Pavel Stehule wrote:
> 2011/1/28 Robert Haas :
>> On Tue, Jan 25, 2011 at 11:29 AM, Pavel Stehule
>> wrote:
>>> variant a) my first patch - detoast on first usage with avoiding to
>>> useless detoast checking
>>> variant b) my first patch - detoast on first usage
On 04.02.2011 15:37, Robert Haas wrote:
Not sure. How much benefit do we get from upgrading tuple locks to
page locks? Should we just upgrade from tuple locks to full-relation
locks?
Hmm, good question. Page-locks are the coarsest level for the b-tree
locks, but maybe that would make sense f
On Fri, Feb 4, 2011 at 10:46 AM, Oleg Bartunov wrote:
> I don't see btree_gist with knn-support. I'm afraid it'll be forgotten.
If you don't see it there, it's because you didn't add it. The
deadline for getting your patch into the CommitFest application was
January 15th, and several reminders w
On Fri, Feb 4, 2011 at 10:13 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I don't think we should commit something that for 9.1 that we may need
>> to change incompatibly for 9.2. If we're not completely happy with
>> it, it gets booted. Whatever we put in place here is going to be with
Itagaki Takahiro writes:
> * Syntax: ENCODING encoding vs. ENCODING 'encoding'
> We don't have to quote encoding names in the patch, but we always need
> quotes for CREATE DATABASE WITH ENCODING. I think we should modify
> CREATE DATABASE to accept unquoted encoding names aside from the patch.
Th
Robert,
I don't see btree_gist with knn-support. I'm afraid it'll be forgotten.
Oleg
On Fri, 4 Feb 2011, Robert Haas wrote:
With ten days left in the current CommitFest, being the last
CommitFest for 9.1 development, there are presently 40 patches that
are marked either Needs Review or Waiting
On 04.02.2011 14:30, Kevin Grittner wrote:
Heikki Linnakangas wrote:
The assertion in RecordFreeIndexPage() is a reasonable sanity
check, but I'm inclined to move it to the caller instead: I don't
think the FSM should need to access predicate lock manager, even
for an assertion.
OK. So it lo
With ten days left in the current CommitFest, being the last
CommitFest for 9.1 development, there are presently 40 patches that
are marked either Needs Review or Waiting on Author. The 11 patches
that are Waiting on Author are the following:
Synchronous Replication, transaction-controlled
Recove
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 incrementally over the new set of refactor
>> patches that I will post shortly to the refactor thread).
>
> Attached is a patch for
Robert Haas writes:
> I don't think we should commit something that for 9.1 that we may need
> to change incompatibly for 9.2. If we're not completely happy with
> it, it gets booted. Whatever we put in place here is going to be with
> us for a long, long time.
So, what is it specifically here
On Fri, Jan 21, 2011 at 8:12 AM, Shigeru HANADA
wrote:
>> * Try strVal() instead of DefElem->val.str
>> * FdwEPrivate seems too abbreviated for me. How about FileFdwPrivate?
>
> Thanks, fixed.
Was there supposed to be a patch attached here? Or where is it? We
are past out of time to get this co
2011/2/4 Itagaki Takahiro :
> On Tue, Feb 1, 2011 at 13:08, Hitoshi Harada wrote:
>>> The third patch is attached, modifying mb routines so that they can
>>> receive conversion procedures as FmgrInof * and save the function
>>> pointer in CopyState.
>>> I tested it with encoding option and could n
On Thu, Feb 3, 2011 at 4:24 PM, Josh Berkus wrote:
> So every package would include a script called upgrade.sql ( or
> upgrade.c? ) which is supposed to handle the upgrade, and it's up to the
> module author to power that, at least until 9.2? Seem like the most
> reasonable course for February ..
On Fri, Feb 4, 2011 at 9:29 AM, Heikki Linnakangas
wrote:
> The interesting thing is that CoarserLockCovers() accounts for 20% of the
> overall CPU time, or 2/3 of the overhead. The logic of PredicateLockAcquire
> is:
>
> 1. Check if we already have a lock on the tuple.
> 2. Check if we already ha
We know that the predicate locking introduced by the serializable
snapshot isolation patch adds a significant amount of overhead, when
it's used. It was fixed for sequential scans by acquiring a relation
level lock upfront and skipping the locking after that, but the general
problem for index s
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
Heikki Linnakangas wrote:
> On 02.02.2011 19:36, Kevin Grittner wrote:
>> I really appreciate you putting this testing framework together.
>> This is clearly the right way to do it, although we also clearly
>> don't want this test in the check target at the root directory,
>> because of the run ti
On Fri, Feb 4, 2011 at 8:07 AM, Fujii Masao wrote:
> On Fri, Feb 4, 2011 at 9:07 PM, Robert Haas wrote:
>> On Fri, Feb 4, 2011 at 6:39 AM, Fujii Masao wrote:
>>> When I ran "make" before "make install", both successfully
>>> finished. So I guess that the "make install" rule in Makefile might
>>>
On Fri, Feb 4, 2011 at 9:07 PM, Robert Haas wrote:
> On Fri, Feb 4, 2011 at 6:39 AM, Fujii Masao wrote:
>> When I ran "make" before "make install", both successfully
>> finished. So I guess that the "make install" rule in Makefile might
>> be corrupted.
>
> Ah - that's the key. Not corrupted, bu
On 3 February 2011 13:58, Thom Brown wrote:
> On 3 February 2011 13:32, Thom Brown wrote:
>> Actually, further testing indicates this causes other problems:
>>
>> postgres=# SELECT x FROM generate_series(1, 9,-1) AS a(x);
>> x
>> ---
>> 1
>> (1 row)
>>
>> Should return no rows.
>>
>> postgres=#
On Fri, Feb 4, 2011 at 6:39 AM, Fujii Masao wrote:
> When I ran "make" before "make install", both successfully
> finished. So I guess that the "make install" rule in Makefile might
> be corrupted.
Ah - that's the key. Not corrupted, but missing a dependency. Try it now...
--
Robert Haas
Ente
On Fri, Feb 4, 2011 at 12:59 AM, Josh Berkus wrote:
> Robert,
>
>> Seeing as how there seem to be neither objections nor endorsements,
>> I'm inclined to commit what I proposed more or less as-is. There
>> remains the issue of what do about the log spam. Josh Berkus
>> suggested logging it when
On 02.02.2011 19:36, Kevin Grittner wrote:
I really appreciate you putting this testing framework together.
This is clearly the right way to do it, although we also clearly
don't want this test in the check target at the root directory,
because of the run time.
It would be nice to get some buil
ce but uninteresting.
BTW, how do you determine which field is shifted in your broken CSV file?
For example, the case you find "AB,CD,EF" for 2 columns tables.
I could provide a raw CSV reader for jagged files, but you still have to
cook the returned fields into a proper tuple...
--
On Fri, Feb 4, 2011 at 06:19, Robert Haas wrote:
> On Fri, Feb 4, 2011 at 12:11 AM, Robert Haas wrote:
>> On Thu, Feb 3, 2011 at 11:42 PM, Robert Haas wrote:
>>> On Thu, Feb 3, 2011 at 11:02 PM, Fujii Masao wrote:
Hi,
When I run "git pull" from the git master and "make", I encoun
Josh Berkus writes:
> How *are* we detecting which version is installed, anyway? Is that in
> the pg_extenstions table?
The installed version is in the pg_extenstion catalog, the version we're
upgrading to is in the control file and can be seen in the system view
pg_available_extensions or from
92 matches
Mail list logo
