Thanks, it's helpful.
The flowchart is a very good point to start.
Cheers,
Soroosh
On Sat, May 18, 2013 at 7:56 PM, Atri Sharma atri.j...@gmail.com wrote:
Sent from my iPad
On 18-May-2013, at 20:49, Dickson S. Guedes lis...@guedesoft.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
On 18.05.2013 03:52, Dickson S. Guedes wrote:
pgbench -S is such a workload. With 9.3beta1, I'm seeing this
profile, when I run pgbench -S -c64 -j64 -T60 -M prepared on a
32-core Linux machine:
- 64.09% postgres postgres [.] tas - tas - 99.83%
s_lock - 53.22% LWLockAcquire + 99.87%
Should it give up trying under some conditions, say there are more errors
than transactions?
I don't really see the point of that. I can't think of a scenario where you
would get too many serialization errors to even finish the pgbench test.
My point is really to avoid in principle a
I have some time now for working on the mystery of why there are no
block write statistics in the database. I hacked out the statistics
collection and reporting side already, rough patch attached if you want
to see the boring parts.
I guessed that there had to be a gotcha behind why this
On 1 May 2013 10:05, Fujii Masao masao.fu...@gmail.com wrote:
In HEAD, when the standby is promoted, recovery requests the checkpoint
but doesn't wait for its completion. I found the checkpoint starting log
message
of this checkpoint looks odd as follows:
LOG: checkpoint starting:
I
On 7 May 2013 10:57, Heikki Linnakangas hlinnakan...@vmware.com wrote:
While testing the bug from the Assertion failure at standby promotion, I
bumped into a different bug in fast promotion. When the first checkpoint
after fast promotion is performed, there is no guarantee that the
On 25 March 2013 19:14, Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 15.03.2013 04:25, Michael Paquier wrote:
Hi,
When trying to *promote* a slave as master by removing recovery.conf and
restarting node, I found an assertion failure on master branch:
LOG: database system was shut
On Wed, May 15, 2013 at 11:11 AM, Noah Misch n...@leadboat.com wrote:
On Wed, May 15, 2013 at 08:12:34AM +0900, Michael Paquier wrote:
The concept of clause parallelism for backend worker is close to the
concept of clause shippability introduced in Postgres-XC. In the case of
XC, the
I'd like to run same query repeatedly and see how long it takes each time.
I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.
Is this intentional, or unavoidable?
Also, is it just or does the inability to watch more frequently than
Jeff Janes jeff.ja...@gmail.com writes:
I'd like to run same query repeatedly and see how long it takes each time.
I thought \watch would be excellent for this, but it turns out that using
\watch suppresses the output of \timing.
Is this intentional, or unavoidable?
\watch uses PSQLexec not
Hey all,
I find the current LISTEN / NOTIFY rather limited in the context of
databases with multiple roles. As it stands it is not possible to restrict
the use of LISTEN or NOTIFY to specific roles, and therefore notifications
(and their payloads) cannot really be trusted as coming from any
Chris Farmiloe chrisfa...@gmail.com writes:
I find the current LISTEN / NOTIFY rather limited in the context of
databases with multiple roles. As it stands it is not possible to restrict
the use of LISTEN or NOTIFY to specific roles, and therefore notifications
(and their payloads) cannot
In fairness NOTIFY has only had a payload since v9 (maybe 8.4?), and the
issue of trust is mainly tied to data leaking from the payload, so I
suspect I won't be last person to request this as people re-visit NOTIFY :)
...but I totally get your point of course.
My first thought was also that
13 matches
Mail list logo
