On Thu, Mar 21, 2013 at 8:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Because it's wrong. Removing volatile means that the compiler is
permitted to optimize away stores (and fetches!)
On Fri, Mar 22, 2013 at 2:29 PM, Robert Haas robertmh...@gmail.com wrote:
The barrier essentially
divides up the code into chunks and requires that those chunks be
optimized independently by the compiler without knowledge of what
earlier or later chunks are doing
While all this sounds
On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Boszormenyi Zoltan z...@cybertec.at writes:
How about the attached patch over current GIT? In other words,
why I am wrong with this idea?
Because it's wrong. Removing volatile means that the compiler is
permitted to
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Because it's wrong. Removing volatile means that the compiler is
permitted to optimize away stores (and fetches!) on the basis of their
being unnecessary according to straight-line
2013-03-18 06:47 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
The volatile marking shouldn't even be necessary there.
The signal handler doesn't writes to it, only the main code.
Well, (a) that's not the case in the patch as committed, and (b) even if
it were true,
Boszormenyi Zoltan z...@cybertec.at writes:
How about the attached patch over current GIT? In other words,
why I am wrong with this idea?
Because it's wrong. Removing volatile means that the compiler is
permitted to optimize away stores (and fetches!) on the basis of their
being unnecessary
2013-03-17 04:48 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
[ 2-lock_timeout-v37.patch ]
Applied after a fair amount of additional hacking.
Thank you, thank you, thank you! :-)
I was disappointed to find that the patch introduced a new race
condition into
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 04:48 keltezéssel, Tom Lane írta:
[ worries about stray SIGALRM events ]
Your reasoning seems to be correct. However, if we take it to the
extreme, enable_timeout_at/enable_timeout_after/enable_timeouts
should also disable the interrupt
2013-03-17 16:07 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 04:48 keltezéssel, Tom Lane írta:
[ worries about stray SIGALRM events ]
Your reasoning seems to be correct. However, if we take it to the
extreme,
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add another static flag variable called
sigalrm_allowed or some such, and have the signal handler test that
2013-03-18 03:52 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add another static flag variable called
sigalrm_allowed or
2013-03-18 06:22 keltezéssel, Boszormenyi Zoltan írta:
2013-03-18 03:52 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add
Boszormenyi Zoltan z...@cybertec.at writes:
The volatile marking shouldn't even be necessary there.
The signal handler doesn't writes to it, only the main code.
Well, (a) that's not the case in the patch as committed, and (b) even if
it were true, the volatile marking is still *necessary*,
2013-03-15 18:53 keltezéssel, Tom Lane írta:
Boszormenyi Zoltanz...@cybertec.at writes:
[ 2-lock_timeout-v33.patch ]
I looked at this patch a bit. I don't understand why you've chosen to
alter the API of the enable_timeout variants to have a bool result that
says I didn't bother to process
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-15 18:53 keltezéssel, Tom Lane írta:
Also, I'm not really enamored of the choice to use List* infrastructure
for enable_timeouts().
Changed. However, the first member of the structure is
TimeoutId id and a sensible end-of-array value can be
2013-03-16 17:42 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-03-15 18:53 keltezéssel, Tom Lane írta:
Also, I'm not really enamored of the choice to use List* infrastructure
for enable_timeouts().
Changed. However, the first member of the structure is
TimeoutId
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
Stephen Frost was against the array pointer/count variant,
it was done that way earlier. Let me redo it again. :-)
I still don't particularly like the array approach, and see the
array+count approach as worse (seems like a higher chance that the
Stephen Frost sfr...@snowman.net writes:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
Stephen Frost was against the array pointer/count variant,
it was done that way earlier. Let me redo it again. :-)
I still don't particularly like the array approach, and see the
array+count approach as
* Tom Lane (t...@sss.pgh.pa.us) wrote:
On the whole though, I don't see anything wrong with pointer-and-count.
I don't really believe that there's ever going to be a need to enable
more than a couple of timeouts simultaneously, so I don't want an overly
complicated data structure for it.
Tom Lane wrote:
Another way that we perhaps should consider is to follow the example of
XLogInsert and use internally-threaded lists that are typically stored
in local arrays in the callers. I've never thought that way was
especially beautiful, but it does have the advantage of being an
Boszormenyi Zoltan z...@cybertec.at writes:
[ 2-lock_timeout-v37.patch ]
Applied after a fair amount of additional hacking.
I was disappointed to find that the patch introduced a new race
condition into timeout.c, or at least broke a safety factor that had
been there. The argument why
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Another way that we perhaps should consider is to follow the example of
XLogInsert and use internally-threaded lists that are typically stored
in local arrays in the callers. I've never thought that way was
especially beautiful,
Boszormenyi Zoltan z...@cybertec.at writes:
[ 2-lock_timeout-v33.patch ]
I looked at this patch a bit. I don't understand why you've chosen to
alter the API of the enable_timeout variants to have a bool result that
says I didn't bother to process the timeout because it would have fired
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost sfr...@snowman.net wrote:
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock on and just tip over the lock_timeout_stmt
limit due to prior waiting and ending up
2013-03-06 19:53 keltezéssel, Tom Lane írta:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost sfr...@snowman.net wrote:
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock on and just tip over the
On Wed, Feb 27, 2013 at 8:58 AM, Stephen Frost sfr...@snowman.net wrote:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
But unlike statement_timeout,
with lock_timeout_stmt the statement can still finish after this limit
as it does useful work besides waiting for locks.
It's still entirely
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2013 09:58 PM, Stephen Frost wrote:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
But unlike statement_timeout,
with lock_timeout_stmt the statement can still finish after this limit
as it does useful work besides waiting for locks.
Craig,
* Craig Ringer (cr...@2ndquadrant.com) wrote:
There are questions about whether this is a good idea, and there's still
discussion ongoing. It doesn't look like it's in a state where we can
confidently say let's include this for 9.3 to me, but I'd like other
viewpoints.
For my part, I
2013-02-27 20:38 keltezéssel, Boszormenyi Zoltan írta:
2013-02-27 20:06 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
If we get rid of the per-statement variant, there is no need for that either.
For my 2c, I didn't see Tom's comments as saying that
2013-02-27 04:06 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
attached is v30, I hope with everything fixed.
Making progress, certainly.
Given the hack to the API of enable_timeout_after() and the need for
timeout_reset_base_time(), I'm just going
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
But unlike statement_timeout,
with lock_timeout_stmt the statement can still finish after this limit
as it does useful work besides waiting for locks.
It's still entirely possible to get 99% done and then hit that last
tuple that you need a lock
Stephen Frost sfr...@snowman.net writes:
Tom, can you comment on your thoughts around this notion of an aggregate
time constraint for waiting on locks? As mentioned upthread, I like the
idea of having an upper-limit on waiting for relation-level locks, but
once you're past that, I'm not sure
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think anything that makes this patch simpler is a good idea. I don't
like any of the accum_time stuff: it complicates the timeout API
unreasonably and slows down existing use cases.
Right, I think we're on the same page there- I had just commented to
2013-02-27 19:07 keltezéssel, Tom Lane írta:
Stephen Frost sfr...@snowman.net writes:
Tom, can you comment on your thoughts around this notion of an aggregate
time constraint for waiting on locks? As mentioned upthread, I like the
idea of having an upper-limit on waiting for relation-level
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
If we get rid of the per-statement variant, there is no need for that either.
For my 2c, I didn't see Tom's comments as saying that we shouldn't have
that capability, just that the implementation was ugly. :)
That said, perhaps we should
2013-02-27 20:06 keltezéssel, Stephen Frost írta:
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
If we get rid of the per-statement variant, there is no need for that either.
For my 2c, I didn't see Tom's comments as saying that we shouldn't have
that capability, just that the
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
attached is v30, I hope with everything fixed.
Making progress, certainly.
Given the hack to the API of enable_timeout_after() and the need for
timeout_reset_base_time(), I'm just going to voice my objection to the
accumulated wait time on
2013-02-24 16:14 keltezéssel, Boszormenyi Zoltan írta:
2013-02-24 15:03 keltezéssel, Stephen Frost írta:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
No, it isn't. Patches posted to the list should be in context diff
format (and
On Sun, Feb 24, 2013 at 4:31 PM, Stephen Frost sfr...@snowman.net wrote:
* Claudio Freire (klaussfre...@gmail.com) wrote:
As another point, it's also the very first thing that we document in
http://wiki.postgresql.org/wiki/Reviewing_a_Patch to check for.
TBH, that wiki link seems to suggest
Zoltan,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
Another question just popped up. Now, that
bool enable_multiple_timeouts(List *timeouts);
exists, do we really need the singular versions?
Since the timeout after N msec have the per-lock and per-stmt
versions,
* Robert Haas (robertmh...@gmail.com) wrote:
True, but I'm with Heikki: it's a pedantic and unhelpful guideline.
Then let's change it, drop the preference, and update the documentation.
I'd certainly prefer that to getting shot for pointing out to patch
submitters that they're not following our
On 2013-02-25 09:11:27 -0500, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
True, but I'm with Heikki: it's a pedantic and unhelpful guideline.
Then let's change it, drop the preference, and update the documentation.
+1
Everyone here who reviews patches regularly
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
True, but I'm with Heikki: it's a pedantic and unhelpful guideline.
Then let's change it, drop the preference, and update the documentation.
I think we should drop the hard requirement for context-format,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
True, but I'm with Heikki: it's a pedantic and unhelpful guideline.
Then let's change it, drop the preference, and update the documentation.
I think we should
2013-02-25 15:25 keltezéssel, Tom Lane írta:
Stephen Frost sfr...@snowman.net writes:
* Robert Haas (robertmh...@gmail.com) wrote:
True, but I'm with Heikki: it's a pedantic and unhelpful guideline.
Then let's change it, drop the preference, and update the documentation.
I think we should
* Stephen Frost (sfr...@snowman.net) wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I think we should drop the hard requirement for context-format, and
instead say that it must not be plain (context-free) diff, since that
clearly *is* a hard requirement.
Alright, I'll start making those
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
Zoltán,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-23 02:55 keltezéssel, Stephen Frost írta:
First off, it's not in context diff format, which is the PG standard for
patch submission.
Since moving to GIT, this expectation is
On 24.02.2013 05:07, Andrew Dunstan wrote:
On 02/23/2013 01:15 PM, Boszormenyi Zoltan wrote:
First off, it's not in context diff format, which is the PG standard for
patch submission.
Since moving to GIT, this expectation is obsolete. All PG hackers
became comfortable with the unified diff
Stephen,
2013-02-23 02:55 keltezéssel, Stephen Frost írta:
Zoltán,
* Zoltán Böszörményi (z...@cybertec.at) wrote:
The patch now passed make check in both cases.
Is v29 the latest version of this patch..?
attached is v30, I hope with everything fixed.
- List based
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
No, it isn't. Patches posted to the list should be in context diff
format (and uncompressed unless it's too large) for easier reading.
That avoids having to download it, apply it to a git tree and
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
So if you want to be kind to readers, look at the patch and choose
the format depending on which one makes it look better. But there's
no need to make a point of it when someone posts in wrong format.
To be more precise- my main complaint
2013-02-24 15:03 keltezéssel, Stephen Frost írta:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
No, it isn't. Patches posted to the list should be in context diff
format (and uncompressed unless it's too large) for easier reading.
That avoids
On Sun, Feb 24, 2013 at 11:08 AM, Stephen Frost sfr...@snowman.net wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
So if you want to be kind to readers, look at the patch and choose
the format depending on which one makes it look better. But there's
no need to make a point of it
On 02/24/2013 12:39 PM, Claudio Freire wrote:
On Sun, Feb 24, 2013 at 11:08 AM, Stephen Frost sfr...@snowman.net wrote:
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
So if you want to be kind to readers, look at the patch and choose
the format depending on which one makes it look
On 24 February 2013 08:44, Heikki Linnakangas hlinnakan...@vmware.com wrote:
I can't speak for others, but I personally don't care whether a patch is
posted in unified or context diff format. Not as a general rule, anyway;
patches that modify a few lines here and there are generally more
* Claudio Freire (klaussfre...@gmail.com) wrote:
As another point, it's also the very first thing that we document in
http://wiki.postgresql.org/wiki/Reviewing_a_Patch to check for.
TBH, that wiki link seems to suggest that *having context* is the
point of the requirement (to be able to
2013-02-23 02:55 keltezéssel, Stephen Frost írta:
Zoltán,
* Zoltán Böszörményi (z...@cybertec.at) wrote:
The patch now passed make check in both cases.
Is v29 the latest version of this patch..?
Yes, is was until you came up with your review... ;-)
Looking through the patch, I've noticed
Zoltán,
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-23 02:55 keltezéssel, Stephen Frost írta:
First off, it's not in context diff format, which is the PG standard for
patch submission.
Since moving to GIT, this expectation is obsolete.
No, it isn't. Patches posted to the list
On 02/23/2013 01:15 PM, Boszormenyi Zoltan wrote:
First off, it's not in context diff format, which is the PG standard for
patch submission.
Since moving to GIT, this expectation is obsolete. All PG hackers
became comfortable with the unified diff format, see references
from the list. A lot
* Andrew Dunstan (and...@dunslane.net) wrote:
Every unified diff can be turned into a context diff by passing it
though filterdiff --format=context.
On that point, annoyingly, it's not accurate for every diff. In
particular, when I tried it with the diff for 'v29' of this lock_timeout
patch,
Zoltán,
* Zoltán Böszörményi (z...@cybertec.at) wrote:
The patch now passed make check in both cases.
Is v29 the latest version of this patch..?
Looking through the patch, I've noticed a couple of things:
First off, it's not in context diff format, which is the PG standard for
patch
2013-01-31 22:12 keltezéssel, Zoltán Böszörményi írta:
2013-01-31 19:38 keltezéssel, Tom Lane írta:
=?ISO-8859-2?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= z...@cybertec.at writes:
Thanks. A question though: how does make check or make installcheck
chooses between the *.out and its different *_N.out
Boszormenyi Zoltan z...@cybertec.at writes:
Why is this patch still in Waiting on Author state in the CF app?
If you're the author, you should change it back to Needs Review when
you've responded to the review.
regards, tom lane
--
Sent via pgsql-hackers mailing list
2013-02-12 19:35 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
Why is this patch still in Waiting on Author state in the CF app?
If you're the author, you should change it back to Needs Review when
you've responded to the review.
regards, tom
Boszormenyi Zoltan z...@cybertec.at writes:
2013-02-12 19:35 keltezéssel, Tom Lane írta:
If you're the author, you should change it back to Needs Review when
you've responded to the review.
Maybe it's just me, but I can't see any facility (link or button) to do that.
Go to the patch page,
2013-02-12 19:45 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-02-12 19:35 keltezéssel, Tom Lane írta:
If you're the author, you should change it back to Needs Review when
you've responded to the review.
Maybe it's just me, but I can't see any facility (link or
On 2013-02-12 19:51:45 +0100, Boszormenyi Zoltan wrote:
2013-02-12 19:45 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-02-12 19:35 keltezéssel, Tom Lane írta:
If you're the author, you should change it back to Needs Review when
you've responded to the review.
Boszormenyi Zoltan z...@cybertec.at writes:
2013-02-12 19:45 keltezéssel, Tom Lane írta:
Go to the patch page, click edit patch, adjust the popdown list for
patch status ...
This is what I am saying, I am logged in and there is no popdown list
for the Patch Status, only text...
That sure
On 02/12/2013 01:51 PM, Boszormenyi Zoltan wrote:
2013-02-12 19:45 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-02-12 19:35 keltezéssel, Tom Lane írta:
If you're the author, you should change it back to Needs Review when
you've responded to the review.
Maybe
2013-02-12 19:58 keltezéssel, Andrew Dunstan írta:
On 02/12/2013 01:51 PM, Boszormenyi Zoltan wrote:
2013-02-12 19:45 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan z...@cybertec.at writes:
2013-02-12 19:35 keltezéssel, Tom Lane írta:
If you're the author, you should change it back to Needs
2013-01-30 17:45 keltezéssel, Zoltán Böszörményi írta:
2013-01-30 16:06 keltezéssel, Hari Babu írta:
On Wednesday, January 30, 2013 7:59 PM Zoltán Böszörményi wrote:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
2. regress check failed because the expected .out file is not
updated properly.
Zoltán Böszörményi wrote:
I have found a little time to look into this problem and
found a way to make pg_regress use prepared_xacts_1.out.
I had to change line 2193 in pg_regress.c from
fputs(max_prepared_transactions = 2\n, pg_conf);
to
fputs(max_prepared_transactions = 0\n,
2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
Zoltán Böszörményi wrote:
I have found a little time to look into this problem and
found a way to make pg_regress use prepared_xacts_1.out.
I had to change line 2193 in pg_regress.c from
fputs(max_prepared_transactions = 2\n, pg_conf);
On 01/31/2013 09:55 AM, Zoltán Böszörményi wrote:
2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
Zoltán Böszörményi wrote:
I have found a little time to look into this problem and
found a way to make pg_regress use prepared_xacts_1.out.
I had to change line 2193 in pg_regress.c from
=?ISO-8859-1?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= z...@cybertec.at writes:
2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
That sounds a lot more difficult than just using make installcheck and
configure the running server with zero prepared xacts ...
It didn't occur to me to use make
2013-01-31 16:39 keltezéssel, Tom Lane írta:
=?ISO-8859-1?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= z...@cybertec.at writes:
2013-01-31 15:22 keltezéssel, Alvaro Herrera írta:
That sounds a lot more difficult than just using make installcheck and
configure the running server with zero prepared xacts ...
=?ISO-8859-2?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= z...@cybertec.at writes:
Thanks. A question though: how does make check or make installcheck
chooses between the *.out and its different *_N.out incarnations?
I couldn't find traces of prepared_xacts_1.out in any file saying this
is the one to be
2013-01-31 19:38 keltezéssel, Tom Lane írta:
=?ISO-8859-2?Q?Zolt=E1n_B=F6sz=F6rm=E9nyi?= z...@cybertec.at writes:
Thanks. A question though: how does make check or make installcheck
chooses between the *.out and its different *_N.out incarnations?
I couldn't find traces of prepared_xacts_1.out
2013-01-28 15:20 keltezéssel, Hari Babu írta:
On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my lock_timeout
patch
for about 3 weeks. Does anyone have a little
2013-01-30 15:29 keltezéssel, Zoltán Böszörményi írta:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my
On Wednesday, January 30, 2013 7:59 PM Zoltán Böszörményi wrote:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
2. regress check failed because the expected .out file is not
updated properly.
Which regress check failed? The .out file was updated in the patch for
prepared_xacts.sql where the
2013-01-30 16:06 keltezéssel, Hari Babu írta:
On Wednesday, January 30, 2013 7:59 PM Zoltán Böszörményi wrote:
2013-01-28 15:20 keltezéssel, Hari Babu írta:
2. regress check failed because the expected .out file is not
updated properly.
Which regress check failed? The .out file was updated in
On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my lock_timeout
patch
for about 3 weeks. Does anyone have a little spare time to test it on
Windows?
I shall try
So, while no native 64-bit compilers are available for free as part of
Visual Studio Express 2012 (11), it doesn't matter much. The issue is
more that it's very much Microsoft's whim whether they release compilers
at all and if so, which ones, when and how.
I think I have a pretty vanilla
On 01/27/2013 12:04 AM, james wrote:
So, while no native 64-bit compilers are available for free as part of
Visual Studio Express 2012 (11), it doesn't matter much. The issue is
more that it's very much Microsoft's whim whether they release compilers
at all and if so, which ones, when and how.
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment sufficient to build a bare
bones
On 01/24/2013 01:44 PM, Jeff Janes wrote:
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan and...@dunslane.net wrote:
On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment
On 01/24/2013 02:41 PM, Andrew Dunstan wrote:
What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)
See Craig's email
On 01/25/2013 02:44 AM, Jeff Janes wrote:
What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)
As far as I'm concerned,
On 01/25/2013 04:08 AM, Andrew Dunstan wrote:
On 01/24/2013 02:41 PM, Andrew Dunstan wrote:
What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
2013-01-20 00:15 keltezéssel, Andrew Dunstan írta:
On 01/19/2013 02:51 AM, Boszormenyi Zoltan wrote:
Yes it rings a bell. See
http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html
I wanted to add a comment to this blog entry but it
2013-01-19 21:15 keltezéssel, Andrew Dunstan írta:
On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
Cross-compiling is not really a supported platform. Why don't you
just build natively? This is know to work as shown by the buildfarm
animals doing it successfully.
Because I don't have
On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
Cross-compiling is not really a supported platform. Why don't you
just build natively? This is know to work as shown by the buildfarm
animals doing it successfully.
Because I don't have a mingw setup on Windows. (Sorry.)
A long time
On 01/19/2013 02:51 AM, Boszormenyi Zoltan wrote:
Yes it rings a bell. See
http://people.planetpostgresql.org/andrew/index.php?/archives/264-Cross-compiling-PostgreSQL-for-WIndows.html
I wanted to add a comment to this blog entry but it wasn't accepted.
The blog is closed for comments. I
On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:
Hi,
using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and trust authentication was set for both.
The firewall was disabled for the
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my lock_timeout patch
for about 3 weeks. Does anyone have a little spare time to test it on Windows?
I shall try to do it, probably next week.
Others are also welcome to
2013-01-19 01:13 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:
Hi,
using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and trust authentication
2013-01-19 06:52 keltezéssel, Amit kapila írta:
On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
Hi,
Unfortunately, I won't have time to do anything with my lock_timeout patch
for about 3 weeks. Does anyone have a little spare time to test it on Windows?
I shall try to do
2013-01-19 01:13 keltezéssel, Andrew Dunstan írta:
On 01/18/2013 05:43 PM, Boszormenyi Zoltan wrote:
Hi,
using the MinGW cross-compiled PostgreSQL binaries from Fedora 18,
I get the following error for both 32 and 64-bit compiled executables.
listen_addresses = '*' and trust authentication
99 matches
Mail list logo
