On Wednesday, July 24, 2013 4:23 AM Tom Lane wrote:
> I wrote:
> > Marc Cousin writes:
> >> The example below is of course extremely simplified, and obviously
> not
> >> what we are really doing in the database, but it exhibits the
> slowdown
> >> between 9.1.9 and 9.2.4.
>
> > Hm. Some experime
On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes wrote:
> On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote wrote:
>> Hello,
>>
>> While understanding the effect of maintenance_work_mem on time taken
>> by CREATE INDEX, I observed that for the values of
>> maintenance_work_mem less than the value for whic
On Tuesday, July 23, 2013 5:06 AM Josh Berkus wrote:
> All,
>
> Christophe just discovered something with include files which is going
> to cause issues with ALTER SYSTEM SET.
>
> So, take as a hypothetical that you use the default postgresql.conf
> file, which sets shared_buffers = 32MB.
>
> In
Noah Misch said:
> Other aggregates based on this syntax might not desire such type unification.
Then there would have to be some way to distinguish that. Maybe those could
have -1 and the standard hypothetical set functions -2, with some flag in
CREATE AGGREGATE to sort it out.
> Having parse an
[ sorry for slow response, this month has been mostly crazy ]
Antonin Houska writes:
> As far as I understand, deconstruct_recurse() ensures that
> SpecialJoinInfo of a new join always gets added to higher position in
> join_info_list than SJ infos of all joins located below the new join in
>
On Tue, Jul 23, 2013 at 01:06:26PM +0100, Tim Kane wrote:
> I haven't given this a lot of thought, but it struck me that when
> rebuilding tables (be it for a restore process, or some other operational
> activity) - there is more often than not a need to build an index or two,
> sometimes many inde
On Wed, Jul 24, 2013 at 11:30 AM, Amit Langote wrote:
> On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes wrote:
>> If you are using trace_sort to report that, it reports the switch as
>> happening as soon as it runs out of memory.
>>
>> At point, all we have been doing is reading tuples into memory.
On Wed, Jul 24, 2013 at 6:02 AM, Jeff Janes wrote:
> On Tue, Jul 23, 2013 at 1:23 AM, Amit Langote wrote:
>> On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote
>> wrote:
>>> Hello,
>>>
>>> While understanding the effect of maintenance_work_mem on time taken
>>> by CREATE INDEX, I observed that for t
On Tue, Jul 23, 2013 at 01:21:52AM +, Andrew Gierth wrote:
> For hypothetical set functions we add a special case, aggordnargs=-1,
> for which both the aggregate and the finalfn must be defined as
> (variadic "any") and parse analysis detects this case and unifies the
> types of the normal args
On Mon, Jul 22, 2013 at 10:02:30PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sun, Jul 21, 2013 at 12:40:38PM -0400, Tom Lane wrote:
> >> Hmm ... good point. The other plan I'd been considering was to add
> >> explicit tracking inside spi.c of all tuple tables created within the
> >> curr
Stephen Frost writes:
> * Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
>> If you have legitimate technical concerns then let's hear them, now.
> Fine- I'd have been as happy leaving this be and letting Greg commit it,
> but if you'd really like to hear my concerns, I'd start with pointing
>
On 07/23/2013 09:42 PM, Craig Ringer wrote:
(Replying on phone, please forgive bad quoting)
Isn't this pretty much what adopting ICU is supposed to give us? OS-independent
collations?
Yes, we need OS-independent collations.
I'd be interested in seeing the rest data for this performance repo
Stephen Frost said:
> [stuff about foreign tables]
I think the issue with foreign tables is probably moot because if you
_did_ want to have some types of foreign tables with a fixed
ordinality, you'd probably also want qual pushdown to work for it
(i.e. so that WHERE rownum=123 doesn't have to fil
On Tuesday, July 23, 2013, David Fetter wrote:
>
> Are you saying that there's stuff that if I don't put it in now will
> impede our ability to add this to FTs later?
>
I'm saying that it'd be a completely different implementation and that this
one would get in the way and essentially have to be r
As failures to use a generic plan goes, that one's fairly tame. I've
seen much worse. For example:
PREPARE foo(integer[]) AS SELECT * FROM complexview WHERE id = ANY ($1);
where the caller typically supplies 1-5 array elements (or any number
less than 10, because generic parameter arrays are assu
I wrote:
> Marc Cousin writes:
>> The example below is of course extremely simplified, and obviously not
>> what we are really doing in the database, but it exhibits the slowdown
>> between 9.1.9 and 9.2.4.
> Hm. Some experimentation shows that the plan cache is failing to switch
> to a generic
On 07/23/2013 03:34 PM, Greg Smith wrote:
> I happen to think the review structure is one of the most important
> components to PostgreSQL release quality. It used to be a single level
> review with just the committers, now it's a two level structure. The
> reason the Postgres code is so good is
On 7/23/13 2:30 PM, Josh Berkus wrote:
You know as well as me that, as consultants, we can get clients to pay for 10%
extra time
for review in the course of developing a feature
Before this number gets quoted anywhere, I think it's on the low side.
I've spent a good bit of time measuring how
On Tue, Jul 23, 2013 at 06:09:20PM -0400, Stephen Frost wrote:
> David
>
> On Tuesday, July 23, 2013, David Fetter wrote:
> >
> > There are a lot of ways foreign tables don't yet act like local
> > ones. Much as I'm a booster for fixing that problem, I'm thinking
> > improvements in this directio
David
On Tuesday, July 23, 2013, David Fetter wrote:
>
> There are a lot of ways foreign tables don't yet act like local ones.
> Much as I'm a booster for fixing that problem, I'm thinking
> improvements in this direction are for a separate patch.
>
This isn't about making FDWs more like local ta
On Tue, Jul 23, 2013 at 05:23:17PM -0400, Stephen Frost wrote:
> * Greg Stark (st...@mit.edu) wrote:
> > So given that WITH ORDINALITY is really only useful for UNNEST and we
> > can generalize it to all SRFs on the basis that Postgres SRFs do
> > produce ordered sets not unordered relations it isn
> Everything was already *not* hunky-dory as soon as you did that, since
> a SIGHUP would have had the same problem.
>
> I'd be inclined to think that ALTER SYSTEM SET should not be allowed to
> modify any PGC_POSTMASTER parameters.
That makes alter system set a bunch less useful, but might be
i
* Greg Stark (st...@mit.edu) wrote:
> So given that WITH ORDINALITY is really only useful for UNNEST and we
> can generalize it to all SRFs on the basis that Postgres SRFs do
> produce ordered sets not unordered relations it isn't crazy for the
> work to be in the Function node.
I agree, it isn't
On Tue, Jul 23, 2013 at 9:27 PM, Stephen Frost wrote:
>
> Fine- I'd have been as happy leaving this be and letting Greg commit it,
> but if you'd really like to hear my concerns, I'd start with pointing
> out that it's pretty horrid to have to copy every record around like
> this and that the hack
On Tue, Jul 23, 2013 at 1:23 AM, Amit Langote wrote:
> On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote wrote:
>> Hello,
>>
>> While understanding the effect of maintenance_work_mem on time taken
>> by CREATE INDEX, I observed that for the values of
>> maintenance_work_mem less than the value for wh
Andrew,
* Andrew Gierth (and...@tao11.riddles.org.uk) wrote:
> Right, and we all know that all code is perfect when committed. sheesh.
That clearly wasn't what was claimed.
> (This is actually the first time in six months that I've had occasion
> to look at that part of the code; that's how long
Tom Lane said:
> If you yourself are still finding bugs in the code as of this afternoon,
> onlookers could be forgiven for doubting that the code is quite as
> readable or ready to commit as all that.
Right, and we all know that all code is perfect when committed. sheesh.
(This is actually the f
Hi.
I want add Zigzag Merge join to Index Nested Loops Join alghoritm.
http://www.cs.berkeley.edu/~fox/summaries/database/query_eval_5-8.html
Which files are responsible for Index nested loops join ? (not simple nested
loops join which has double foreach in nodeNestloop.c) nodeIndexscan.c?
nodeI
Robert Haas writes:
> OK, so GetActiveSnapshot()?
Works for me.
regards, tom lane
--
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, Jul 23, 2013 at 2:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote:
>>> As far as get_actual_variable_range() is concerned, an MVCC snapshot
>>> would probably be the thing to use anyway;
>
>> That surprises me, though. I really thought th
Greg,
> It's more than the available experienced reviewers are willing to chew
> on fully as volunteers. The reward for spending review time is pretty
> low right now.
Short of paying for review time, I don't think we have another solution
for getting the "big patches" reviewed, except to rely o
Robert Haas writes:
> On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote:
>> As far as get_actual_variable_range() is concerned, an MVCC snapshot
>> would probably be the thing to use anyway;
> That surprises me, though. I really thought the point was to cost the
> index scan, and surely that wil
On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote wrote:
> Hello,
>
> While understanding the effect of maintenance_work_mem on time taken
> by CREATE INDEX, I observed that for the values of
> maintenance_work_mem less than the value for which an internal sort is
> performed, the time taken by CREATE
Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>
> > I would suggest that these changes be undone, except that the old
> > "SELECT FOR ..." be replaced by a dynamic string that reverse-parses the
> > LockingClause to provide the actual clause that was used.
>
> Here's a patch for this.
Pushed t
On Tue, Jul 23, 2013 at 12:28 PM, Tom Lane wrote:
> Robert Haas writes:
>>> 2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow
>>> to use SnapshotSelf instead. These include pgrowlocks(),
>>> pgstat_heap(), and get_actual_variable_range().
>
>> Tom proposed that we use Snapsho
On 7/23/13 12:10 PM, Josh Berkus wrote:
Apparently it's a little much for experienced reviewers to chew on, too,
since I've been trying to get someone to review it since the beginning
of the Commitfest.
It's more than the available experienced reviewers are willing to chew
on fully as voluntee
Robert Haas writes:
>> 2. snapshot-self-not-now-v1.patch changes several uses of SnapshotNow
>> to use SnapshotSelf instead. These include pgrowlocks(),
>> pgstat_heap(), and get_actual_variable_range().
> Tom proposed that we use SnapshotDirty for this case; let me just ask
> whether there are
Andres Freund wrote:
> Hm. There seems to be more things that need some more improvement
> from a quick look.
>
> First, I have my doubts of the general modus operandy of
> CONCURRENTLY here. I think in many, many cases it would be faster
> to simply swap in the newly built heap + indexes in conc
On Jul 23, 2013, at 1:17 AM, Tom Lane wrote:
> Does that create any ambiguities against formats we already support?
> I'm worried about examples like this one:
>
> select 'monday, july 22, 22:30 2013'::timestamptz;
> timestamptz
>
> 2013-07-22 22:30:00-04
> (
Greg,
> As far as motivating new reviewers goes, let's talk about positive
> feedback. Anything that complicates the release notes is a non-starter
> because that resource is tightly controlled by a small number of people,
> and it's trying to satisfy a lot of purposes.
Greg, you're re-arguing
On 7/23/13 10:56 AM, Robert Haas wrote:
On Mon, Jul 22, 2013 at 11:48 PM, Greg Smith wrote:
We know that a 1GB relation segment can take a really long time to write
out. That could include up to 128 changed 8K pages, and we allow all of
them to get dirty before any are forced to disk with fsyn
On 07/22/2013 01:27 PM, Greg Smith wrote:
>
> Anyone who would like to see RLS committed should consider how you can
> get resources to support a skilled PostgreSQL reviewer spending time on
> it. (This is a bit much to expect new reviewers to chew on usefully)
> I've been working on that here, b
On Tue, Jul 23, 2013 at 7:32 PM, Greg Stark wrote:
> This exact idea was discussed a whole back. I think it was even implemented.
>
> The problem Tom raised at the time is that the memory usage of the bloom
> filter implies smaller or less efficient hash table. It's difficult to
> determine whethe
On Thu, Jul 18, 2013 at 8:46 AM, Robert Haas wrote:
> There seems to be a consensus that we should try to get rid of
> SnapshotNow entirely now that we have MVCC catalog scans, so I'm
> attaching two patches that together come close to achieving that goal:
>
> 1. snapshot-error-v1.patch introduces
On Mon, Jul 22, 2013 at 11:48 PM, Greg Smith wrote:
> Recently I've been dismissing a lot of suggested changes to checkpoint fsync
> timing without suggesting an alternative. I have a simple one in mind that
> captures the biggest problem I see: that the number of backend and
> checkpoint writes
On Tue, Jul 23, 2013 at 9:22 AM, Greg Smith wrote:
> On 7/23/13 9:06 AM, Robert Haas wrote:
>>
>> But just BTW, you kind of messed up that CommitFest entry. The link you
>> added as a new version of the
>> patch was actually to a different patch from the same flock.
>
> Fixed now, since I find my
On Tue, Jul 23, 2013 at 9:42 AM, Craig Ringer wrote:
> (Replying on phone, please forgive bad quoting)
>
> Isn't this pretty much what adopting ICU is supposed to give us?
> OS-independent collations?
Yes.
> I'd be interested in seeing the rest data for this performance report, partly
> as I'd
On Tuesday, July 23, 2013 7:06 PM Andres Freund wrote:
> On 2013-07-23 18:59:11 +0530, Amit Kapila wrote:
> > > * I'd be very surprised if this doesn't make WAL replay of update
> heavy
> > > workloads slower by at least factor of 2.
> >
> > Yes, if you just consider the cost of replay, but i
This exact idea was discussed a whole back. I think it was even
implemented.
The problem Tom raised at the time is that the memory usage of the bloom
filter implies smaller or less efficient hash table. It's difficult to
determine whether you're coming out ahead or behind.
I think it should be po
Marc Cousin writes:
> The example below is of course extremely simplified, and obviously not
> what we are really doing in the database, but it exhibits the slowdown
> between 9.1.9 and 9.2.4.
Hm. Some experimentation shows that the plan cache is failing to switch
to a generic plan, but I'm not
On 2013-07-23 09:27:18 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
> >> In file included from gram.y:13612:0:
> >> scan.c: In function ‘yy_try_NUL_trans’:
> >> scan.c:10181:23: warning: unused variable ‘yyg’ [-Wunused-variable]
> >> Post
(Replying on phone, please forgive bad quoting)
Isn't this pretty much what adopting ICU is supposed to give us? OS-independent
collations?
I'd be interested in seeing the rest data for this performance report, partly
as I'd like to see how ICU collations would compare when ICU is crudely hacke
On 2013-07-23 18:59:11 +0530, Amit Kapila wrote:
> > * I'd be very surprised if this doesn't make WAL replay of update heavy
> > workloads slower by at least factor of 2.
>
> Yes, if you just consider the cost of replay, but it involves other
> operations as well
> like for standby case
On 2013-07-23 09:21:54 -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
> > > Writing postgres.bki
> > > Writing schemapg.h
> > > Writing postgres.description
> > > Writing postgres.shdescription
> > > Writing fm
On 2013-07-23 14:17:13 +0100, Greg Stark wrote:
> We already do this in pg_restore by starting multiple worker processes.
> Those processes should get the benefit of synchronised sequential scans.
>
> The way the api for indexes works y wouldn't really be hard to start
> multiple parallel index bu
On Tuesday, July 23, 2013 12:27 AM Andres Freund wrote:
> On 2013-07-19 10:40:01 +0530, Hari Babu wrote:
> >
> > On Friday, July 19, 2013 4:11 AM Greg Smith wrote:
> > >On 7/9/13 12:09 AM, Amit Kapila wrote:
> > >>I think the first thing to verify is whether the results posted
> can be validate
Andres Freund writes:
> On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
>> I have noticed that some people post examples using make --silent (-s).
>> I found this actually kind of neat to use from time to time, because
>> then you only see output if you have warnings or errors. But we get
>
On 7/23/13 9:06 AM, Robert Haas wrote:
But just BTW, you kind of messed up that CommitFest entry. The link you added
as a new version of the
patch was actually to a different patch from the same flock.
Fixed now, since I find myself looking back through history on
submissions often enough to
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
> > Writing postgres.bki
> > Writing schemapg.h
> > Writing postgres.description
> > Writing postgres.shdescription
> > Writing fmgroids.h
> > Writing fmgrtab.c
>
> I personally don't feel the n
We already do this in pg_restore by starting multiple worker processes.
Those processes should get the benefit of synchronised sequential scans.
The way the api for indexes works y wouldn't really be hard to start
multiple parallel index builds. I'm not sure how well the pg_restore thing
works and
On Tue, Jul 23, 2013 at 12:04 AM, Greg Smith wrote:
> A further look at recently ALTER OPERATOR FAMILY changes shows that Robert
> has been working on those quite a bit. I'm putting him down as the
> committer on this last one.
I missed that one, now committed. But just BTW, you kind of messed
On Tue, Jul 23, 2013 at 09:48:16PM +0900, Michael Paquier wrote:
>
>
>
> On Tue, Jul 23, 2013 at 8:53 PM, Pavel Raiskup wrote:
>
> Is pg_upgrade supposed to work even across multiple major releases? (I
> know
> that the README.rpm-dist is mentioning just one major release step, bu
On Thu, May 23, 2013 at 6:52 PM, Robins wrote:
> Please find attached a patch to take code-coverage of ALTER OPERATOR
> FAMILY.. ADD / DROP (src/backend/commands/opclasscmds.c) from 50% to 87%.
>
> Any and all feedback is welcome.
Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.
On 2013-07-23 08:38:03 -0400, Peter Eisentraut wrote:
> I have noticed that some people post examples using make --silent (-s).
> I found this actually kind of neat to use from time to time, because
> then you only see output if you have warnings or errors. But we get
> some extra output that does
On 23 July 2013 06:10, Tom Lane wrote:
> Andrew Gierth writes:
>> I must admit to finding all of this criticism of unread code a bit
>> bizarre.
>
> If you yourself are still finding bugs in the code as of this afternoon,
> onlookers could be forgiven for doubting that the code is quite as
> read
On Tue, Jul 23, 2013 at 8:53 PM, Pavel Raiskup wrote:
> Is pg_upgrade supposed to work even across multiple major releases? (I
> know
> that the README.rpm-dist is mentioning just one major release step, but it
> could be bound just to actual pg_upgrade which is packaged..)
>
Yes you should be a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Even if we thought the functionality was worth the trouble, which I
> continue to doubt, this particular syntax proposal is a disaster.
Agreed. While there might be things worthwhile to add to psql's
backslash commands, this isn't one of those.
Th
I have noticed that some people post examples using make --silent (-s).
I found this actually kind of neat to use from time to time, because
then you only see output if you have warnings or errors. But we get
some extra output that doesn't quite fit:
Writing postgres.bki
Writing schemapg.h
Writin
Greg,
First, thanks for helping out with the CF.
* Greg Smith (g...@2ndquadrant.com) wrote:
> That leaves only 1 patch where I have no idea who will commit it:
>
> access to calls stack from GET DIAGNOSTICS statement
I'll take a look at this.
Thanks again,
Stephen
On Mon, Jul 22, 2013 at 12:49 PM, Greg Stark wrote:
> On Mon, Jul 22, 2013 at 12:50 PM, Peter Eisentraut wrote:
>> I think part of the problem is that we call strcoll for each comparison,
>> instead of doing strxfrm once for each datum and then just strcmp for
>> each comparison. That is effecti
On Tuesday, July 23, 2013 12:02 AM Greg Smith wrote:
> The v3 patch applies perfectly here now. Attached is a spreadsheet
> with test results from two platforms, a Mac laptop and a Linux server.
> I used systems with high disk speed because that seemed like a worst
> case for this improvement. Th
Hi all,
I haven't given this a lot of thought, but it struck me that when
rebuilding tables (be it for a restore process, or some other operational
activity) - there is more often than not a need to build an index or two,
sometimes many indexes, against the same relation.
It strikes me that in or
Hello all,
don't know much about pg_upgrade implementation so I rather asking here before
I start trying the process once again with debugging and observing deeply
the code.
I tried to setup our postgresql RPM to package pg_upgrade in version
8.4.13 to automatize post-rpm-upgrade update of postgr
On 7/23/13 2:16 AM, Satoshi Nagayasu wrote:
> I've been working on new pgstattuple function to allow
> block sampling [1] in order to reduce block reads while
> scanning a table. A PoC patch is attached.
Take a look at all of the messages linked in
https://commitfest.postgresql.org/action/patch_vi
On 07/16/2013 09:14 PM, I wrote:
> But okay, you're saying we *have* and *want* a guarantee that even a
> superuser cannot execute arbitrary native code via libpq (at least in
> default installs w/o extensions).
I stand corrected and have to change my position, again. For the record:
We do not ha
Hi,
I've been trying to diagnose a severe performance regression we've been
having in one of our plpgsql procedures.
The example below is of course extremely simplified, and obviously not
what we are really doing in the database, but it exhibits the slowdown
between 9.1.9 and 9.2.4.
So here is t
Magnus Hagander wrote:
> In that case, doesn't this patch break Windows? We no longer do the
> anonymous bind on Windows, since it's now in the #ifdef HAVE_LIBLDAP.
>
> Don't we need to keep the ldap_simple_bind() call in the Windows case,
> or break it up so the call to ldap_sasl_bind_s() is moved
On 2013-07-22 13:50:08 -0400, Robert Haas wrote:
> On Fri, Jun 14, 2013 at 6:51 PM, Andres Freund wrote:
> > The git tree is at:
> > git://git.postgresql.org/git/users/andresfreund/postgres.git branch
> > xlog-decoding-rebasing-cf4
> > http://git.postgresql.org/gitweb/?p=users/andresfreund/postgr
On 2013-04-29 23:37:43 -0400, Peter Eisentraut wrote:
> On Sat, 2013-04-06 at 12:59 -0400, Tom Lane wrote:
> > The reason I'm thinking it's a good idea is that it would expose any
> > remaining places where we have nominally var-length arrays embedded in
> > larger structs. Now that I've seen the
On Tue, Jul 23, 2013 at 1:11 PM, Amit Langote wrote:
> Hello,
>
> While understanding the effect of maintenance_work_mem on time taken
> by CREATE INDEX, I observed that for the values of
> maintenance_work_mem less than the value for which an internal sort is
> performed, the time taken by CREATE
On 2013-07-23 09:11:00 +0200, Andres Freund wrote:
> Hi,
>
> Anchovy is failing on 9.1 and earlier for quite some time now:
> http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=anchovy&br=REL9_1_STABLE
> The commit at that date looks rather unconspicuous. Looking at the
> 'config' section reveals t
On Mon, Jul 22, 2013 at 10:59 PM, Greg Stark wrote:
> On Fri, Jul 19, 2013 at 2:20 PM, Samrat Revagade
> wrote:
>
>> for example:
>> if i want to configure 2 servers then it will add 6 lines,for 3 -9, for 4-12
>> setting's for particular server will be:
>>
>> considering the way of setting value
W dniu 23.07.2013 06:22, David Fetter pisze:
> What problem or problems did you notice, and what did you change to
> fix them?
"UPDATE ... FROM" generated "ERROR: variable not found in subplan
target lists". I've added some workaround in add_vars_to_targetlist:
- if it is an "after" - simple chang
Hi,
Anchovy is failing on 9.1 and earlier for quite some time now:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=anchovy&br=REL9_1_STABLE
The commit at that date looks rather unconspicuous. Looking at the
'config' section reveals the difference between the failing
http://pgbuildfarm.org/cgi-bi
On Mon, Jul 22, 2013 at 8:48 PM, Greg Smith wrote:
> And I can't get too excited about making this as my volunteer effort when I
> consider what the resulting credit will look like. Coding is by far the
> smallest part of work like this, first behind coming up with the design in
> the first place
85 matches
Mail list logo
