A Dijous, 6 de setembre de 2012 00:30:53, Josh Berkus va escriure:
In general I think the selling point for such a feature would be no
administrative hassles, and I believe that has to go not only for the
end-user experience but also for the application-developer experience.
If you have to
Andrew Dunstan and...@dunslane.net writes:
This seems totally stupid, but it happens when the path to the current
directory includes a cross-device symlink. If I cd following the link,
then this effect doesn't happen. Weird.
Huh. So maybe a gmake bug, or maybe there's something wrong with
Hello
This patch disable bypassing of parameters for variadic function with
ANY type variadic parameter. Now - this functionality is just
broken. Because there are no any requests for fixing this issue, I
propose the most simply solution - just disable using this type of
variadic function when
Pavel Stehule pavel.steh...@gmail.com writes:
This patch disable bypassing of parameters for variadic function with
ANY type variadic parameter.
This seems completely silly. If you think it's broken now (which I
don't particularly agree with: does not do what you want in some corner
cases is
2012/9/8 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
This patch disable bypassing of parameters for variadic function with
ANY type variadic parameter.
This seems completely silly. If you think it's broken now (which I
don't particularly agree with: does not
This question comes about after reading the VLDB paper Serializable
Snapshot Isolation in PostgreSQL.
We release predicate locks after a transaction abort, but not after a
subtransaction abort. The paper says that the reason is:
We do not drop SIREAD locks acquired during a subtransaction if the
On 09/08/2012 11:06 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
This seems totally stupid, but it happens when the path to the current
directory includes a cross-device symlink. If I cd following the link,
then this effect doesn't happen. Weird.
Huh. So maybe a gmake bug,
After reading the recent thread about python 2 vs python 3 support,
I thought I'd amuse myself by trying to get plpython3 supported in
the Fedora packages. That turned out to be unreasonably painful
(which is something we oughta fix eventually), but it worked,
at least with F16/F17. When I went
On Sat, 2012-09-08 at 16:35 -0400, Tom Lane wrote:
and obviously, python is iterating through the hash's keys in a
different order than it was a minor version or two back. (The failure
is occurring with 3.3.0-0.4.rc1.fc19, whereas I saw no failure with
3.2.3-7.fc17.)
Yes, known problem with
Andrew Dunstan and...@dunslane.net writes:
Scratch that theory, that was just a transient. If anything it looks
like it is related to system load. When almost nothing was running on
the machine it worked fine. When I started up a Browser and an MUA the
problem occurred. This VM has 4 CPUs
Andrew Dunstan and...@dunslane.net writes:
And it's the stock Fedora build of make.
Which Fedora branch exactly?
The package version I was trying to reproduce with here is
make-3.82-8.fc16.x86_64.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Peter Eisentraut pete...@gmx.net writes:
On Sat, 2012-09-08 at 16:35 -0400, Tom Lane wrote:
I think probably the best thing is to change the test case so it has
one valid key and one not-valid one, rather than assuming that the
same key will always be complained of when there's more than one
On 09/08/2012 04:54 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
And it's the stock Fedora build of make.
Which Fedora branch exactly?
The package version I was trying to reproduce with here is
make-3.82-8.fc16.x86_64.
Same:
$ rpm -q make
make-3.82-8.fc16.x86_64
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Scratch that theory, that was just a transient. If anything it looks
like it is related to system load. When almost nothing was running on
the machine it worked fine. When I started up a Browser and an MUA the
I propose that we try and develop better commit_delay advice, to make
it easier to set the parameter in a way that actually helps
performance. I have been researching a way to make commit_delay
adaptive, though have yet to develop any further insight that is worth
sharing. This may change.
The
Here's a patch to provide for the pg_upgrade tests to be run in MSVC
builds. I want to get this running on the buildfarm before long on HEAD
and REL9_2_STABLE.
cheers
andrew
diff --git a/src/tools/msvc/Install.pm b/src/tools/msvc/Install.pm
index 3923532..235a150 100644
---
The attached simple patch alters the output produced by pg_test_fsync,
so that we also see the average sync time per op.
Good idea. A median would be even better, but harder to calculate, I
imagine. You might consider providing a maximum, too.
The pg_test_fsync
docs have had minor
I wrote:
After reading the recent thread about python 2 vs python 3 support,
I thought I'd amuse myself by trying to get plpython3 supported in
the Fedora packages. That turned out to be unreasonably painful
(which is something we oughta fix eventually), but it worked,
To give you an idea of
On 09/08/2012 04:52 PM, Andrew Dunstan wrote:
On 09/08/2012 04:46 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Scratch that theory, that was just a transient. If anything it looks
like it is related to system load. When almost nothing was running on
the machine it worked
Andrew Dunstan and...@dunslane.net writes:
I have just repeated this on an absolutely fresh up to date F17 machine,
with no symlink stuff in play.
Steps to recreate:
CC=ccache gcc ../postgres/configure --enable-depend --enable-debug
--enable-cassert --with-perl --with-python
On 09/08/2012 07:54 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I have just repeated this on an absolutely fresh up to date F17 machine,
with no symlink stuff in play.
Steps to recreate:
CC=ccache gcc ../postgres/configure --enable-depend --enable-debug
On Sat, 2012-09-08 at 16:52 -0400, Tom Lane wrote:
How come you did not back-patch that commit ... are we not supporting
3.3 in branches before 9.2 for some reason?
Python 3.3 isn't even released yet, much less so back then, so it seemed
premature.
Also, it's a fairly big change just to make
On Sat, 2012-09-08 at 19:54 -0400, Tom Lane wrote:
Anyway, what I notice is that I get different types of failures, but
they are all under ecpg/. What I think we need to do is insert
.NOTPARALLEL in ecpg/Makefile,
I'd hate that, because the ecpg build is one of the slowest parts of the
build,
On Sat, 2012-09-08 at 19:18 -0400, Tom Lane wrote:
To give you an idea of what unreasonably painful means, attached is
the specfile diff needed to make this happen. I will not comment on
the fragility of this beyond observing that the touch -r commands
are *necessary*, else you get incorrect
24 matches
Mail list logo
