* Stephen Frost (sfr...@snowman.net) wrote:
> > llist_opt: 9289 tps
> > HEAD: 9286 tps
>
> llist_opt: 9407 tps
>
> Which gives us ~1.3% improvment.
Trying out some different options- going with 32 pre-allocated
ListCell's actually reduced performance, according to these tests.
Dropping it
Seems system() call cleanups sigaction state on FreeBSD.
The root of problem is a threading library. In FreeBSD there are two versions of
sigaction() (system() and others) depending on thread enabled. libpq library is
compiled by default with -pthread switch but psql is linked without that.
T
Excerpts from Florian Pflug's message of jue may 17 09:08:26 -0400 2012:
> On May16, 2012, at 15:51 , Tom Lane wrote:
> > It is by design, in that the only contemplated case was truncated-away
> > pages. I'm pretty hesitant to consider allowing arbitrary kernel errors
> > to be ignored here …
>
* Stephen Frost (sfr...@snowman.net) wrote:
> Alright, so I've done some pgbench's using all default configs with just
> a straight up './configure' and pgbench -S -T 300, 3 runs each and then
> averaged:
>
> llist_opt: 9289 tps
> HEAD: 9286 tps
Ok, apparently part of the issue with the prev
Fujii,
>
> You mean that "remaster" is, after promoting one of standby servers,
> to make
> remaining standby servers reconnect to new master and resolve the
> timeline
> gap without the shared archive? Yep, that's one of my TODO items, but
> I'm not
> sure if I have enough time to implement that
> It might be easy to detect the situation where the standby has
> connected to itself,
> e.g., by assigning ID for each instance and checking whether IDs of
> two servers
> are the same. But it seems not easy to detect the
> circularly-connected
> two or more
> standbys.
Well, I think it would b
On Fri, May 18, 2012 at 8:27 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
>
> After fixing that, however, I'm now getting another error, much later in
> the build process:
>
> ERROR: failed to re-find parent for block 123002
> STATEMENT: create index i_gisttest on gisttest
I bumped into a bug in the new buffering GiST build code. I did this:
create table gisttest (t text);
insert into gisttest select
a||'fooo' from
generate_series(1,1000) a;
create index i_gisttest on gisttest using gist (t collate "C") WITH
(fil
I've been testing the crash recovery of REL9_2_BETA1, using the same
method I posted in the "Scaling XLog insertion" thread. I have the
checkpointer occasionally throw a FATAL error, which causes the
postmaster to take down all of the other processes (DETAIL: The
postmaster has commanded this ser
Hi All,
I just realized that anyone can listen for notifications (using listen)
so long as they know the "channel" name. This means that a user could
receive and view the payload for another user.
Perhaps it would be good to note this in the documentation (i.e., there
should be no expectati
On Fri, May 18, 2012 at 3:57 AM, Joshua Berkus wrote:
> Yeah, I don't know how I produced the crash in the first place, because of
> course the self-replica should block all writes, and retesting it I can't get
> it to accept a write. Not sure how I did it in the first place.
>
> So the bug is
On Wed, May 16, 2012 at 4:14 PM, Miroslav Šimulčík
wrote:
>
> This is only a illustration of main functionality. Later I can create a
> document about the design and implementation details, but first I need to
> know if such temporal features as described here, could be added to future
> versions
Hi,
yes you are right, storing old versions of entry to history table can be
handled with triggers and my solution also uses triggers to do that.
Advantage of my implementation is that user doesn't need to create all
necessary objects (triggers, history table, begin/end columns ...)
manually. He j
Hello.
SQL 2011 standard wasn't available in time I started this project so I
built my implementation on older standards TSQL2 and SQL/Temporal, that
were only available. None of these were accepted by ANSI/ISO commissions
however.
There is different syntax in SQL 2011 and it looks like one that
Miroslav Šimulcík wrote:
> as a part of my master's thesis I have created temporal support patch for
> PostgreSQL. It enables the
> creation of special temporal tables with entries versioning. Modifying
> operations (UPDATE, DELETE,
> TRUNCATE) on these tables don't cause permanent changes to ent
Hello.
Basically my implementation serve for the same thing as table_log extension -
entry versioning. It also uses history table and triggers to store old
versions of entries. After quick review of table_log extension, here is
comparison with my solution:
tale_log advantages compared to my solu
16 matches
Mail list logo
