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.
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
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
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
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 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
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 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 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 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
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
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
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
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
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
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 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:
>
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 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 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 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
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
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
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
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 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 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
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 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
> 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
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
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
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
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
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ö
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
36 matches
Mail list logo
