On Wed, Jun 27, 2012 at 11:35 PM, Robert Haas wrote:
> It looks to me like pg_wchar2utf_with_len will not work, because
> unicode_to_utf8 returns its second argument unmodified - not, as your
> code seems to assume, the byte following what was already written.
>
Fixed.
> MULE also looks proble
Hi,
attached is a patch that does $SUBJECT.
It's a usability enhancement, to take a backup, write
a minimalistic recovery.conf and start the streaming
standby in one go.
Comments?
Best regards,
Zoltán Böszörményi
--
--
Zoltán Böszörményi
Cybertec Schönig & Schö
Hi, Andres!
There is my review of this patch.
1) Patches don't apply cleanly to head. So I used commit
bed88fceac04042f0105eb22a018a4f91d64400d as the base for patches, then all
the patches close to this apply cleanly. Regression tests pass OK, but it
seems that new functionality isn't covered by
On Fri, Jun 29, 2012 at 1:07 PM, Nils Goroll wrote:
>> FWIW, I kicked off a looong benchmarking run on this a couple of days
>> ago on the IBM POWER7 box, testing pgbench -S, regular pgbench, and
>> pgbench --unlogged-tables at various client counts with and without
>> the patch; three half-hour t
2012/6/28 Tom Lane :
> Kohei KaiGai writes:
>> 2012/6/27 Florian Pflug :
>>> Hm, what happens if a SECURITY DEFINER functions returns a refcursor?
>
>> My impression is, here is no matter even if SECURITY DEFINER function
>> returns refcursor.
>
> I think Florian has a point: it *should* work, but
Thank you, Robert.
as this patch was not targeted towards increasing tps, I am at happy to hear
that your benchmarks also suggest that performance is "comparable".
But my main question is: how about resource consumption? For the issue I am
working on, my current working hypothesis is that spinnin
> test runs on an IBM POWER7 system with 16 cores, 64 hardware threads.
Could you add the CPU Type / clock speed please?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sun, Jul 1, 2012 at 8:02 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> attached is a patch that does $SUBJECT.
>
> It's a usability enhancement, to take a backup, write
> a minimalistic recovery.conf and start the streaming
> standby in one go.
>
> Comments?
Could you add the patch to the next Commi
Hi,
2012-07-01 17:38 keltezéssel, Fujii Masao írta:
On Sun, Jul 1, 2012 at 8:02 PM, Boszormenyi Zoltan wrote:
Hi,
attached is a patch that does $SUBJECT.
It's a usability enhancement, to take a backup, write
a minimalistic recovery.conf and start the streaming
standby in one go.
Comments?
On Sun, Jul 1, 2012 at 1:02 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> attached is a patch that does $SUBJECT.
>
> It's a usability enhancement, to take a backup, write
> a minimalistic recovery.conf and start the streaming
> standby in one go.
I like the writing of recovery.conf. In fact, I had it
On Sun, Jul 1, 2012 at 3:11 PM, Alexander Korotkov wrote:
> 1) Patches don't apply cleanly to head. So I used commit
> bed88fceac04042f0105eb22a018a4f91d64400d as the base for patches, then all
> the patches close to this apply cleanly. Regression tests pass OK, but it
> seems that new functionali
On Mon, Jul 2, 2012 at 12:42 AM, Boszormenyi Zoltan wrote:
> Hi,
>
> 2012-07-01 17:38 keltezéssel, Fujii Masao írta:
>
>> On Sun, Jul 1, 2012 at 8:02 PM, Boszormenyi Zoltan wrote:
>>>
>>> Hi,
>>>
>>> attached is a patch that does $SUBJECT.
>>>
>>> It's a usability enhancement, to take a backup, w
On Mon, Jul 2, 2012 at 12:44 AM, Magnus Hagander wrote:
> On Sun, Jul 1, 2012 at 1:02 PM, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> attached is a patch that does $SUBJECT.
>>
>> It's a usability enhancement, to take a backup, write
>> a minimalistic recovery.conf and start the streaming
>> standby i
seeing some of the latest commits about fixing compiler warnings I took
a look at the buildfarm to see if there are any interesting ones there
(in total we have a thousends of warnings on the buildfarm but most of
those are from very noisy compilers).
so in case anybody is interested those are a s
Thanks for the review!
On Fri, Jun 29, 2012 at 7:22 PM, Magnus Hagander wrote:
> On Wed, Jun 27, 2012 at 7:24 PM, Fujii Masao wrote:
>> On Thu, Jun 21, 2012 at 3:18 AM, Robert Haas wrote:
>>> On Wed, Jun 20, 2012 at 7:18 AM, Magnus Hagander
>>> wrote:
>>> You agreed to add something like
On Sat, Jun 30, 2012 at 5:51 AM, Andres Freund wrote:
> Currently its possible to cause transactions to fail with ALTER ENUM ADD
> AFTER/BEFORE:
>
> psql 1:
>
> CREATE TYPE enumcrash AS ENUM('a', 'b');
> CREATE FUNCTION randenum() RETURNS enumcrash LANGUAGE sql AS $$SELECT * FROM
> unnest(enum_ran
On Sun, Jul 1, 2012 at 11:13 AM, Nils Goroll wrote:
> as this patch was not targeted towards increasing tps, I am at happy to hear
> that your benchmarks also suggest that performance is "comparable".
>
> But my main question is: how about resource consumption? For the issue I am
> working on, my
On Sun, Jul 1, 2012 at 11:18 AM, Nils Goroll wrote:
>> test runs on an IBM POWER7 system with 16 cores, 64 hardware threads.
>
> Could you add the CPU Type / clock speed please?
cpu : POWER7 (architected), altivec supported
clock : 3550.00MHz
revision: 2.1 (pvr 0
On Fri, Jun 29, 2012 at 3:32 PM, Bruce Momjian wrote:
> On Mon, Jun 25, 2012 at 11:57:36AM -0400, Robert Haas wrote:
>> In retrospect, it seems as though it might have been a good idea to
>> make the postgres database read-only and undroppable, so that all
>> client utilities could count on being
On Sun, Jul 1, 2012 at 7:14 PM, Fujii Masao wrote:
>
> On Fri, Jun 29, 2012 at 7:22 PM, Magnus Hagander wrote:
>> On Wed, Jun 27, 2012 at 7:24 PM, Fujii Masao wrote:
>>> On Thu, Jun 21, 2012 at 3:18 AM, Robert Haas wrote:
On Wed, Jun 20, 2012 at 7:18 AM, Magnus Hagander
wrote:
>
Hi Robert,
> Spinlock contentions cause tps to go down. The fact that tps didn't
> change much in this case suggests that either these workloads don't
> generate enough spinlock contention to benefit from your patch, or
> your patch doesn't meaningfully reduce it, or both. We might need a
> test
On Jul 1, 2012, at 5:44 PM, Magnus Hagander wrote:
> On Sun, Jul 1, 2012 at 1:02 PM, Boszormenyi Zoltan wrote:
>> Hi,
>>
>> attached is a patch that does $SUBJECT.
>>
>> It's a usability enhancement, to take a backup, write
>> a minimalistic recovery.conf and start the streaming
>> standby in o
On Sat, Jun 30, 2012 at 3:28 PM, Marco Nenciarini
wrote:
>
> On 30/06/2012 04:16, Alex Hunsaker wrote:
> >
> > Hi, I've been reviewing this patch.
> >
> > Good documentation, and regression tests. The code looked fine but I
> > didn't care for the code duplication between array_replace and
> > arr
Robert Haas writes:
> On Sat, Jun 30, 2012 at 5:51 AM, Andres Freund wrote:
>> This is not surprising. psql 2's backend finds rows in the index with enum
>> values that are not visible in its mvcc snapshot.
> I think the problem is that load_enum_cache_data() uses
> GetTransactionSnapshot() rath
I wrote:
> Robert Haas writes:
>> I think the problem is that load_enum_cache_data() uses
>> GetTransactionSnapshot() rather than GetLatestSnapshot().
> That would only make the race condition window smaller (ie, hard
> to reproduce manually like this, but not gone).
No, wait, we made ALTER TYPE
On Fri, Jun 29, 2012 at 10:07 AM, Nils Goroll wrote:
> On 06/28/12 05:21 PM, Jeff Janes wrote:
>
>> It looks like the hacked code is slower than the original. That
>> doesn't seem so good to me. Am I misreading this?
>
> No, you are right - in a way. This is not about maximizing tps, this is ab
On Wed, Jun 20, 2012 at 12:32 AM, Heikki Linnakangas
wrote:
> On 01.06.2012 03:02, Jeff Janes wrote:
>>
>> I've attached a new patch which addresses several of your concerns,
>> and adds the documentation. The description is much longer than the
>> descriptions of other nearby options, which most
Hi Jeff,
>>> It looks like the hacked code is slower than the original. That
>>> doesn't seem so good to me. Am I misreading this?
>>
>> No, you are right - in a way. This is not about maximizing tps, this is about
>> maximizing efficiency under load situations
>
> But why wouldn't this maximiz
On Thu, Jun 28, 2012 at 6:57 PM, Josh Berkus wrote:
>
> A second obstacle to "opportunistic wraparound vacuum" is that
> wraparound vacuum is not interruptable. If you have to kill it off and
> do something else for a couple hours, it can't pick up where it left
> off; it needs to scan the whole t
Hi,
I've been playing around with the idea of supporting automatically
updatable views, and I have a working proof of concept. I've taken a
different approach than the previous attempts to implement this
feature (e.g.,
http://archives.postgresql.org/pgsql-hackers/2009-01/msg01746.php),
instead do
On Sun, Jul 1, 2012 at 2:28 PM, Nils Goroll wrote:
> Hi Jeff,
>
It looks like the hacked code is slower than the original. That
doesn't seem so good to me. Am I misreading this?
>>>
>>> No, you are right - in a way. This is not about maximizing tps, this is
>>> about
>>> maximizing ef
My thoughts on this is that it would be a very valuable feature to have, and
would make Postgres views behave more like they always were intended to behave,
which is indistinguishible to users from tables in behavior where all possible,
and that the reverse mapping would be automatic with the DB
On Jul 1, 2012, at 4:18 PM, Tom Lane wrote:
> However, I'm a bit worried by the "if (!FirstSnapshotSet)" restriction
> in GetLatestSnapshot. Are we sure that enum comparisons could never
> happen without a snapshot already being set? What's the point of
> throwing an error there anyway, as oppos
On Jul 2, 2012, at 12:04 AM, Robert Haas wrote:
> On Jul 1, 2012, at 4:18 PM, Tom Lane wrote:
>> However, I'm a bit worried by the "if (!FirstSnapshotSet)" restriction
>> in GetLatestSnapshot. Are we sure that enum comparisons could never
>> happen without a snapshot already being set? What's t
Robert Haas writes:
> On Jul 2, 2012, at 12:04 AM, Robert Haas wrote:
>> On Jul 1, 2012, at 4:18 PM, Tom Lane wrote:
>>> However, I'm a bit worried by the "if (!FirstSnapshotSet)" restriction
>>> in GetLatestSnapshot.
>> I don't know whether it should set the transaction snapshot or just r
> Ar
Excerpts from Tom Lane's message of lun jul 02 00:24:06 -0400 2012:
> Robert Haas writes:
> > On Jul 2, 2012, at 12:04 AM, Robert Haas wrote:
> >> On Jul 1, 2012, at 4:18 PM, Tom Lane wrote:
> >>> However, I'm a bit worried by the "if (!FirstSnapshotSet)" restriction
> >>> in GetLatestSnapshot.
36 matches
Mail list logo
