On 26 November 2012 02:32, Jeff Davis pg...@j-davis.com wrote:
Updated both patches.
Changes:
* Moved the changes to pageinspect into the TLI patch, because it
makes more sense to be a part of that patch and it also reduces the size
of the main checksums patch.
* Fix off-by-one bug in
On 02.12.2012 20:19, Tom Lane wrote:
Alexander Korotkovaekorot...@gmail.com writes:
Nice idea to delay expanding colors to characters! Obviously, we should
delay expanding inly alphanumerical characters. Because non-alphanumberical
characters influence graph structure. Trying to implement...
Kohei KaiGai kai...@kaigai.gr.jp writes:
The attached patch is a revised version.
I think you fixed all the problems I could see with your patch. It
applies cleanly (with some offsets), compiles cleanly (I have a custom
Makefile with CUSTOM_COPT=-Werror) and passes regression tests.
I'll go
Noah Misch n...@leadboat.com writes:
Acquiring the lock could still take an unpredictable amount of time.
I think there's a new GUC brewing about setting the lock timeout
separately from the statement timeout, right?
being said, I share Tom's doubts. The DEBUG1 messages are a sorry excuse for
On 29 November 2012 09:06, Heikki Linnakangas hlinnakan...@vmware.com wrote:
The code that reads the WAL from the archive, from pg_xlog, and from a
master server via walreceiver, is quite complicated. I'm talking about the
WaitForWALToBecomeAvailable() function in xlog.c. I got frustrated with
On 30.11.2012 13:11, Dimitri Fontaine wrote:
Hi,
Heikki Linnakangashlinnakan...@vmware.com writes:
Attached is a patch to refactor that logic into a more straightforward state
machine. It's always been a kind of a state machine, but it's been hard to
see, as the code wasn't explicitly written
On Saturday, December 01, 2012 10:00 PM Tom Lane wrote:
Amit Kapila amit.kap...@huawei.com writes:
On Saturday, December 01, 2012 1:30 AM Tom Lane wrote:
which cannot work if persistent could be a var_name, because bison
has to decide whether to reduce opt_persistent to PERSISTENT or empty
Hi Steve,
On 2012-12-02 21:52:08 -0500, Steve Singer wrote:
On 12-11-14 08:17 PM, Andres Freund wrote:
I am getting errors like the following when I try to use either your
test_decoding plugin or my own (which does even less than yours)
LOG: database system is ready to accept connections
On Mon, Dec 3, 2012 at 2:05 PM, Heikki Linnakangas
hlinnakan...@vmware.comwrote:
On 02.12.2012 20:19, Tom Lane wrote:
Alexander Korotkovaekorot...@gmail.com writes:
Nice idea to delay expanding colors to characters! Obviously, we should
delay expanding inly alphanumerical characters.
On 2012-12-03 13:22:12 +0100, Andres Freund wrote:
Hi Steve,
On 2012-12-02 21:52:08 -0500, Steve Singer wrote:
On 12-11-14 08:17 PM, Andres Freund wrote:
I am getting errors like the following when I try to use either your
test_decoding plugin or my own (which does even less than yours)
Is this patch available in version 9.2.1 ?
Senthil
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Switching-timeline-over-streaming-replication-tp5723547p5734744.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers
On 3 December 2012 09:56, Simon Riggs si...@2ndquadrant.com wrote:
I think the way forwards for this is...
1. Break out the changes around inCommit flag, since that is just
uncontroversial refactoring. I can do that. That reduces the noise
level in the patch and makes it easier to understand
On 26 November 2012 02:32, Jeff Davis pg...@j-davis.com wrote:
* Make the checksum algorithm process 4 bytes at a time and sum into a
signed 64-bit int, which is faster than byte-at-a-time. Also, forbid
zero in either byte of the checksum, because that seems like a good
idea.
Like that,
On 03.12.2012 14:21, senthilnathan wrote:
Is this patch available in version 9.2.1 ?
Nope, this is for 9.3.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas hlinnakan...@vmware.com writes:
I'm not understanding the sequence difference well enough to comment
here, but I think some people are currently playing tricks in their
failover scripts with moving files directly to the pg_xlog of the server
to be promoted.
That's still
I think we should expect provided path to be relative to current directory
or may consider it to be relative to either one of Data or CWD.
Because normally we expect path to be relative to CWD if some program is
asking for path in command line.
Please find the attached patch to make the path
On Tue, Nov 20, 2012 at 8:43 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks, rather
than doing all the stuffs with macros. It allows to use local variables,
unlike
macros; that has a risk of naming conflict with temporary
On Sat, Dec 1, 2012 at 2:57 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
* Do we need OAT_POST_ALTER hook even if no fields were updated
actually? In case when ALTER SET OWNER, it checks object's ownership
only when current and new user-id is not same. Right now, I follow this
manner on
On Fri, Nov 30, 2012 at 6:41 PM, Andres Freund and...@2ndquadrant.com wrote:
While we're talking about changing defaults, how about changing the
default value of the recovery.conf parameter 'standby_mode' to on?
Not sure about anybody else, but I never want it any other way.
Hm. But only if
On Fri, Nov 30, 2012 at 1:02 AM, Magnus Hagander mag...@hagander.net wrote:
In the interest of moving things along, I'll remove these for now at
least, and commit the rest of the patch, so we can keep working on the
basebacku part of things.
I see you committed this - does this possibly
Markus Wanner wrote:
On 11/28/2012 03:51 PM, Alvaro Herrera wrote:
I remember your patchset. I didn't look at it for this round, for no
particular reason. I did look at KaiGai's submission from two
commitfests ago, and also at a patch from Simon which AFAIK was never
published openly.
On 12-12-03 07:42 AM, Andres Freund wrote:
Two things:
1) Which exact options are you using for pg_receivellog? Not -d
replication by any chance?
Yes that is exactly what I'md doing. Using a real database name instead
makes this go away.
Thanks
This seems to produce exactly that kind off
2012/12/3 Robert Haas robertmh...@gmail.com:
On Tue, Nov 20, 2012 at 8:43 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I'd like to have catalog/objectaccess.c to wrap-up invocation of hooks,
rather
than doing all the stuffs with macros. It allows to use local variables,
unlike
macros; that
On 2012-12-03 09:35:55 -0500, Steve Singer wrote:
On 12-12-03 07:42 AM, Andres Freund wrote:
Two things:
1) Which exact options are you using for pg_receivellog? Not -d
replication by any chance?
Yes that is exactly what I'md doing. Using a real database name instead
makes this go away.
On 12-12-03 09:48 AM, Andres Freund wrote:
On 2012-12-03 09:35:55 -0500, Steve Singer wrote:
On 12-12-03 07:42 AM, Andres Freund wrote:
Yes that is exactly what I'md doing. Using a real database name
instead makes this go away.
Was using replication an accident or do you think it makes sense
2012/12/3 Robert Haas robertmh...@gmail.com:
On Sat, Dec 1, 2012 at 2:57 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
* Do we need OAT_POST_ALTER hook even if no fields were updated
actually? In case when ALTER SET OWNER, it checks object's ownership
only when current and new user-id is not
On 12/03/2012 03:28 PM, Alvaro Herrera wrote:
I'm not really that interested in it currently ... and there are enough
other patches to review. I would like bgworkers to mature a bit more
and get some heavy real world testing before we change autovacuum.
Understood.
Just like av_launcher
On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
But even if we can't make that work, it's not grounds for reserving
PERSISTENT. Instead I'd be inclined to forget about RESET PERSISTENT
syntax and use, say, SET PERSISTENT var_name TO DEFAULT to mean that.
(BTW, I
On Mon, Dec 3, 2012 at 6:38 AM, Amit Kapila amit.kap...@huawei.com wrote:
On Saturday, December 01, 2012 10:00 PM Tom Lane wrote:
Amit Kapila amit.kap...@huawei.com writes:
On Saturday, December 01, 2012 1:30 AM Tom Lane wrote:
which cannot work if persistent could be a var_name, because
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
In case when we try to update / delete a table with inherited
children and RETURNING clause was added, is loses right
references to the pseudo columns, even though it
On 3 December 2012 15:17, Markus Wanner mar...@bluegap.ch wrote:
Just like av_launcher does it now: set a flag in shared memory and
signal the postmaster (PMSIGNAL_START_AUTOVAC_WORKER).
I'm not sure how this works. What process is in charge of setting such
a flag?
The only process that
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
But even if we can't make that work, it's not grounds for reserving
PERSISTENT. Instead I'd be inclined to forget about RESET PERSISTENT
syntax and use, say, SET PERSISTENT var_name
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 3, 2012 at 6:38 AM, Amit Kapila amit.kap...@huawei.com wrote:
opt_persistent: PERSISTENT{ $$ = TRUE; }
| /*EMPTY*/%prec Op{ $$ = FALSE; }
;
I am not sure if there are any problems
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
In case when we try to update / delete a table with inherited
children and RETURNING clause was added, is loses right
On 12/03/2012 10:32 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 3, 2012 at 6:38 AM, Amit Kapila amit.kap...@huawei.com wrote:
opt_persistent: PERSISTENT{ $$ = TRUE; }
| /*EMPTY*/%prec Op{ $$ = FALSE; }
;
I
On 3 December 2012 15:36, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
In case when we try to update / delete a table with inherited
Markus Wanner wrote:
On 12/03/2012 03:28 PM, Alvaro Herrera wrote:
Just like av_launcher does it now: set a flag in shared memory and
signal the postmaster (PMSIGNAL_START_AUTOVAC_WORKER).
I'm not sure how this works. What process is in charge of setting such
a flag?
The only
Simon Riggs wrote:
On 3 December 2012 15:17, Markus Wanner mar...@bluegap.ch wrote:
The only process that currently starts background workers ... ehm ...
autovacuum workers is the autovacuum launcher. It uses the above
Postmaster Signal in autovacuum.c:do_start_autovacuum_worker() to have
On 12/03/2012 04:27 PM, Simon Riggs wrote:
My understanding was that the patch keep autovac workers and
background workers separate at this point.
I agree to that, for this patch. However, that might not keep me from
trying to (re-)sumbit some of the bgworker patches in my queue. :-)
Regards
On 12/03/2012 04:44 PM, Alvaro Herrera wrote:
Simon Riggs wrote:
Is there anything to be gained *now* from merging those two concepts?
I saw that as refactoring that can occur once we are happy it should
take place, but isn't necessary.
IMO it's a net loss in robustness of the autovac
On Mon, Dec 03, 2012 at 03:41:47PM +, Simon Riggs wrote:
On 3 December 2012 15:36, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support is not perfect right now.
Alvaro,
in general, please keep in mind that there are two aspects that I tend
to mix and confuse: one is what's implemented and working for
Postgres-R. The other this is how I envision (parts of it) to be merged
back into Postgres, itself. Sorry if that causes confusion.
On 12/03/2012 04:43 PM,
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Sorry for the delay. I've reviewed the patch. It was applied
successfully, and it worked well for tests I did including the example
you showed. I think it's worth the work, but I'm not sure you go
about it in the right way. (I feel the
Marko Tiikkaja wrote:
Kevin Grittner kgri...@mail.com wrote:
Marko Tiikkaja wrote:
T2 sees an empty table
As far as I know you are the first to notice this behavior.
Thanks for pointing it out.
I will take a look at the issue; I don't know whether it's
something small I can address in
David Fetter escribió:
On Mon, Dec 03, 2012 at 03:41:47PM +, Simon Riggs wrote:
On 3 December 2012 15:36, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2012/12/3 David Fetter da...@fetter.org:
On Sun, Nov 25, 2012 at 03:20:28PM +0100, Kohei KaiGai wrote:
However, UPDATE / DELETE support
On 15 November 2012 21:07, Kohei KaiGai kai...@kaigai.gr.jp wrote:
The attached patch is a revised version of row-level security
feature.
I've got time to review this patch, so I've added myself as a CF reviewer.
Definitely looks very interesting, well done for getting it this far along.
--
On Dec 3, 2012 2:55 AM, Andrew Dunstan and...@dunslane.net wrote:
On 12/02/2012 07:50 PM, Magnus Hagander wrote:
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Someone just reported a problem when they had created a new
I was looking at the code when the following tiny bit caught my attention.
In vacuumlazy.c, we release the pin on the final VM page at line number 972.
954 if (vacrelstats-num_dead_tuples 0)
955 {
956 /* Log cleanup info before we touch indexes */
957
Hi,
Thanks for your very good review!
Ibrar Ahmed ibrar.ah...@gmail.com writes:
I looked at the discussion for this patch and the patch itself. Here
are my comments and observations about the patch.
What I got from the discussion is that the patch tries to implement a
mechanism to install
On 12/03/2012 12:33 PM, Magnus Hagander wrote:
On Dec 3, 2012 2:55 AM, Andrew Dunstan and...@dunslane.net
mailto:and...@dunslane.net wrote:
On 12/02/2012 07:50 PM, Magnus Hagander wrote:
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us
mailto:t...@sss.pgh.pa.us wrote:
I wonder if we really need to make another pass over the entire visibility
map to count the number of all-visible pages at the end of the vacuum. The
code that I'm looking at is in src/backend/commands/vacuumlazy.c:
247 new_rel_allvisible = visibilitymap_count(onerel);
248 if
Hi,
On 2012-12-03 23:44:36 +0530, Pavan Deolasee wrote:
I wonder if we really need to make another pass over the entire visibility
map to count the number of all-visible pages at the end of the vacuum. The
code that I'm looking at is in src/backend/commands/vacuumlazy.c:
247
On Mon, Dec 3, 2012 at 11:50 PM, Andres Freund and...@2ndquadrant.comwrote:
A full-table vacuum can take a *long* (as in days) time, so I think
recounting makes sense. And normally the cost is pretty small, so I
don't see a problem in this.
Well, may be the cost is low. But it can still
On 3 December 2012 17:37, Pavan Deolasee pavan.deola...@gmail.com wrote:
I was looking at the code when the following tiny bit caught my attention.
In vacuumlazy.c, we release the pin on the final VM page at line number 972.
954 if (vacrelstats-num_dead_tuples 0)
955 {
956
On 3 December 2012 18:20, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2012-12-03 23:44:36 +0530, Pavan Deolasee wrote:
I wonder if we really need to make another pass over the entire visibility
map to count the number of all-visible pages at the end of the vacuum. The
code that I'm
Hi,
Thanks for the review. Please see the updated patch.
Hmm. We're running an I/O cast during do_tup_convert() now, and look
up the required functions for each tuple. I think if we're going to
support this operation at that level, we need to look up the necessary
functions at
Andrew Dunstan and...@dunslane.net writes:
On 12/03/2012 01:45 PM, Alvaro Herrera wrote:
$ LC_ALL=C make
Makefile:15: invalid `override' directive
Well, you seem to have more problems than just the database name.
I see this too. Given that I want to wrap the back branches in a few
minutes,
On 12/03/2012 02:46 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 12/03/2012 01:45 PM, Alvaro Herrera wrote:
$ LC_ALL=C make
Makefile:15: invalid `override' directive
Well, you seem to have more problems than just the database name.
I see this too. Given that I want to
On Sat, Dec 1, 2012 at 03:41:15PM -0500, Andrew Dunstan wrote:
On 12/01/2012 02:34 PM, Bruce Momjian wrote:
On Sat, Dec 1, 2012 at 02:31:03PM -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-01 12:14:37 -0500, Tom Lane wrote:
It could do with some comments
On Mon, Dec 3, 2012 at 1:36 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
Well, may be the cost is low. But it can still run into several hundred or
thousand pages that are read into the buffer pool again. If there is indeed
too much churn happening, an ANALYZE will kick in which will
Jan Wieck wrote:
Attached is a new patch that addresses most of the points raised
in discussion before.
1) Most of the configuration variables are derived from
deadlock_timeout now. The check for conflicting lock request
interval is deadlock_timeout/10, clamped to 10ms. The try to
acquire
On 12/3/2012 5:42 PM, Kevin Grittner wrote:
Jan Wieck wrote:
Attached is a new patch that addresses most of the points raised
in discussion before.
1) Most of the configuration variables are derived from
deadlock_timeout now. The check for conflicting lock request
interval is
On Tue, Dec 4, 2012 at 3:16 AM, Robert Haas robertmh...@gmail.com wrote:
Also, if someone does have a 100GB relation, rereading 2MB of
visibility map pages at the end probably isn't a significant part of
the total cost. Even if 99.9% of the relation is all-visible and we
skip reading those
On 12/03/2012 04:02 PM, Andrew Dunstan wrote:
Looks like undefine is a new feature in gmake 3.82. I can reproduce
this on my SL6 box which has 3.81. I'll have to come up with something
other than ifdef, like
ifneq ($(USE_MODULE_DB),)
and use the override in dblink's Makefile to set
Andrew,
What about doing:
json_get(json, json)
returns json
where parameter #2 is a path expressed as JSON? For example,
json_get(personal_profile, '[ {contact_info {phone numbers {cell phones}
} } ]')
... would return whatever was in that heirarchical object, in this case
an array of cell
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=8de72b66a2edcf12c812de0a73bd50b6b7d81d62
Part of that patch was reverted later:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5457a130d3a66db807d1e0ee2b8e829321809b83
I assume that refers to the discussion
EXPLAIN ALTER TABLE would be the next step I guess. I discovered plenty
of magic tricks when working on the rewriting support for that command,
and I think exposing them in the EXPLAIN output would go a long way
towards reducing some POLA violations.
I think this would be cool on its own
Josh Berkus j...@agliodbs.com writes:
EXPLAIN ALTER TABLE would be the next step I guess. I discovered plenty
of magic tricks when working on the rewriting support for that command,
and I think exposing them in the EXPLAIN output would go a long way
towards reducing some POLA violations.
I
On 12/03/2012 08:14 PM, Josh Berkus wrote:
Andrew,
What about doing:
json_get(json, json)
returns json
where parameter #2 is a path expressed as JSON? For example,
json_get(personal_profile, '[ {contact_info {phone numbers {cell phones}
} } ]')
... would return whatever was in that
On Mon, Dec 3, 2012 at 02:38:20AM -, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
As there isn't (as far as I know at least) any actual *point* in
creating a tablespace inside the main data directory, should we
perhaps disallow this in CREATE
On Monday, December 03, 2012 8:59 PM Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
But even if we can't make that work, it's not grounds for reserving
PERSISTENT. Instead I'd be inclined to forget about RESET
On Monday, December 03, 2012 8:50 PM Robert Haas wrote:
On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
But even if we can't make that work, it's not grounds for reserving
PERSISTENT. Instead I'd be inclined to forget about RESET
PERSISTENT
syntax and use,
On Mon, Dec 03, 2012 at 11:37:17AM +0100, Dimitri Fontaine wrote:
Noah Misch n...@leadboat.com writes:
Acquiring the lock could still take an unpredictable amount of time.
I think there's a new GUC brewing about setting the lock timeout
separately from the statement timeout, right?
Yes.
I recently applied the attached patch to prevent recreation of the
current database user in the dump file when in binary upgrade mode.
This was necessary because pg_upgrade will fail on any error from a
pg_dumpall restore.
It would be nice of we could do the same for non-binary-upgrade
Hi all,
While reading some index-related code, I found that the description of the
argument is_internal of index_create in index.c has been forgotten in
commit f4c4335.
Correction patch attached.
Thanks,
--
Michael Paquier
http://michael.otacoo.com
20121204_index_create_header.patch
On Dec 3, 2012, at 12:33, Magnus Hagander wrote:
On Dec 3, 2012 2:55 AM, Andrew Dunstan and...@dunslane.net wrote:
On 12/02/2012 07:50 PM, Magnus Hagander wrote:
On Sat, Dec 1, 2012 at 6:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Someone
Applied.
---
On Fri, Nov 30, 2012 at 10:43:29PM -0500, Bruce Momjian wrote:
On Mon, Nov 26, 2012 at 02:43:19PM -0500, Bruce Momjian wrote:
In any event, I think the documentation should caution that the
upgrade
Why was this change made?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Nov 30, 2012 at 06:06:39PM -0500, Andrew Dunstan wrote:
On 11/30/2012 04:45 PM, Bruce Momjian wrote:
On Thu, Nov 29, 2012 at 11:12:23PM -0500, Bruce Momjian wrote:
In looking to add an fsync-only option to initdb, I found its main()
function to be 743 lines long, and very hard to
On Mon, Dec 3, 2012 at 11:24:08PM -0500, Peter Eisentraut wrote:
Why was this change made?
I asked Andrew and he had no idea why a 'set -x' would be in the script.
I ran the script and saw the commands being echoed. Was that
intentional? If so, I can add it back, but it would be good to add a
On Mon, 2012-11-26 at 18:15 -0300, Alvaro Herrera wrote:
Should we be referencing RFC 4516 instead?
True.
I'm not very fond of the way this entry is worded:
Good point. I've rewritten it a little bit.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Mon, 2012-12-03 at 23:26 -0500, Bruce Momjian wrote:
On Mon, Dec 3, 2012 at 11:24:08PM -0500, Peter Eisentraut wrote:
Why was this change made?
I asked Andrew and he had no idea why a 'set -x' would be in the script.
I ran the script and saw the commands being echoed. Was that
On Mon, Dec 3, 2012 at 11:38:03PM -0500, Peter Eisentraut wrote:
On Mon, 2012-12-03 at 23:26 -0500, Bruce Momjian wrote:
On Mon, Dec 3, 2012 at 11:24:08PM -0500, Peter Eisentraut wrote:
Why was this change made?
I asked Andrew and he had no idea why a 'set -x' would be in the script.
On Sun, Dec 2, 2012 at 5:56 AM, Phil Sorber p...@omniti.com wrote:
Here is the updated patch. I renamed it, but using v5 to stay consistent.
After looking at this patch, I found the following problems:
- There are a couple of whitespaces still in the code, particularly at the
end of those
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Sorry for the delay. I've reviewed the patch. It was applied
successfully, and it worked well for tests I did including the example
you showed. I think it's worth the work, but I'm not sure you
Hi all
While doing some setup I've noticed that master (at least) appears to
fail to build if LDAP headers aren't installed.
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv
On 12/02/2012 03:07 AM, Noah Misch wrote:
On Sat, Dec 01, 2012 at 07:34:51PM +0100, Andres Freund wrote:
On 2012-12-01 18:27:08 +, Simon Riggs wrote:
On 1 December 2012 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
It's hard to know whether your
Hello all,
the extension modules (TestUpgrade etc.) in the buildfarm client do not
use the make command override defined in the config file, instead
hardcoding command lines using make. This fails where make is not GNU
make.
Patch attached, which fixes the problem on jaguarundi.
--
88 matches
Mail list logo
