Sent from my iPad
On 18-May-2013, at 12:34, Liming Hu wrote:
> On Fri, May 17, 2013 at 11:44 PM, Atri Sharma wrote:
>>
>>
>> Sent from my iPad
>>
>> On 18-May-2013, at 12:07, Liming Hu wrote:
>>
>>> On Fri, May 17, 2013 at 11:13 PM, Atri Sharma wrote:
Sent from my iPad
On 5/18/2013 12:11 AM, Atri Sharma wrote:
Sent from my iPad
On 18-May-2013, at 12:34, Liming Hu wrote:
On Fri, May 17, 2013 at 11:44 PM, Atri Sharma wrote:
Sent from my iPad
On 18-May-2013, at 12:07, Liming Hu wrote:
On Fri, May 17, 2013 at 11:13 PM, Atri Sharma wrote:
Sent from my
On Sat, May 18, 2013 at 1:30 PM, Liming Hu wrote:
> On 5/18/2013 12:11 AM, Atri Sharma wrote:
>
> Sent from my iPad
>
> On 18-May-2013, at 12:34, Liming Hu wrote:
>
> On Fri, May 17, 2013 at 11:44 PM, Atri Sharma wrote:
>
> Sent from my iPad
>
> On 18-May-2013, at 12:07, Liming Hu wrote:
>
> On
On 5/18/2013 1:03 AM, Atri Sharma wrote:
On Sat, May 18, 2013 at 1:30 PM, Liming Hu wrote:
On 5/18/2013 12:11 AM, Atri Sharma wrote:
Sent from my iPad
On 18-May-2013, at 12:34, Liming Hu wrote:
On Fri, May 17, 2013 at 11:44 PM, Atri Sharma wrote:
Sent from my iPad
On 18-May-2013, at 12:0
On Sat, May 18, 2013 at 1:47 PM, Liming Hu wrote:
> On 5/18/2013 1:03 AM, Atri Sharma wrote:
>>
>> On Sat, May 18, 2013 at 1:30 PM, Liming Hu wrote:
>>>
>>> On 5/18/2013 12:11 AM, Atri Sharma wrote:
>>>
>>> Sent from my iPad
>>>
>>> On 18-May-2013, at 12:34, Liming Hu wrote:
>>>
>>> On Fri, May
Hello,
The attached patch by Kyotaro Horiguchi-san fixes a PAM authentication
error logging issue which is that when using PAM authentication,
connection attempts by clients (like psql) result in an unnecessary
logging of failed authentication.
-- Forwarded message --
From: Amit L
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Em 16-05-2013 07:52, Pavel Stehule escreveu:
> 2013/5/16 Thom Brown :
>> On 16 May 2013 11:09, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> I proposed a some months log plans of cancelled queries
>>> http://www.postgresql.org/message-id/cafj8pra-duzkmd
Hi
I was tracing a simple SELECT query to find how pg works for fetching
tuples.
but I'm totally lost in the code.
Could you help me to understand under the hood?
I know about parsing and planning parts, my actual problem is executer.
If you show me a road map to study, I would appreciate it.
Reg
Sent from my iPad
On 18-May-2013, at 20:01, Soroosh Sardari wrote:
> Hi
>
> I was tracing a simple SELECT query to find how pg works for fetching tuples.
> but I'm totally lost in the code.
> Could you help me to understand under the hood?
> I know about parsing and planning parts, my actual
On Fri, May 17, 2013 at 10:54:25AM -0400, Alvaro Herrera wrote:
> Dmitriy Igrishin escribió:
>
> > I've noticed a small inaccuracy:
> >
> > E.1.3.4 Object Manipulation
> > [...]
> >
> > "This allows C functions to be called when DDL commands are run."
> >
> > But according to
> > http://www.pos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Em 18-05-2013 11:40, Atri Sharma escreveu:
> On 18-May-2013, at 20:01, Soroosh Sardari
> wrote:
>
>> Hi
>>
>> I was tracing a simple SELECT query to find how pg works for
>> fetching tuples. but I'm totally lost in the code. Could you
>> help me t
Sent from my iPad
On 18-May-2013, at 20:49, "Dickson S. Guedes" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Em 18-05-2013 11:40, Atri Sharma escreveu:
>> On 18-May-2013, at 20:01, Soroosh Sardari
>> wrote:
>>
>>> Hi
>>>
>>> I was tracing a simple SELECT query to find how
Hackers,
I recently had a reason to benchmark a database which is default
SERIALIZABLE mode. I was startled to discover that pgbench is set up to
abort the client once it hits a serialization failure. You get a bunch
of these:
Client 7 aborted in state 11: ERROR: could not serialize access due
My thinking is that what pgbench should do is:
* track an error count
* if it finds an error, don't increment the transaction count, but do
increment the error count.
* then continue to the next transaction.
Does that seem like the right approach?
Could it retry the *same* transaction instead
On 2013-05-19 00:03, Fabien COELHO wrote:
My thinking is that what pgbench should do is:
* track an error count
* if it finds an error, don't increment the transaction count, but do
increment the error count.
* then continue to the next transaction.
Does that seem like the right approach?
Shou
On Fri, May 17, 2013 at 05:50:38PM +0200, Cédric Villemain wrote:
> Hello Liming,
>
> > >> Sounds interesting. How can we build this over our current
> > >> implementation, or do we need to build it from scratch?
> > >>
> > > I know how to write the code, but just need approval of accepting into
On 05/17/2013 08:22 AM, amul sul wrote:
> Hello,
>
> I have observed the following same situation in PG 9.3beta1
> Multiple PSQL clients are connected to server, some of them running
> transaction and some of them are idle state.
>
>
> When one of the backend is killed or crashed (using kill -9
> It isn't clear to me why this needs to be tackled in psql or the other
> clients.
This case only for the client PSQL, who has running transaction,yet not has
been finished
and suddenly some other backend crashed or killed, then server restarted in
recovery mode.
Then this client immediatel
On 05/19/2013 11:41 AM, amul sul wrote:
> in a way, we client terminal wont hangup by throwing *The connection to the
> server was lost. Attempting reset: Failed. !*
The thing is that this just should not be a routine occurrence. It's a
minor irritation to me when debugging sometimes, but it's n
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 wrote:
>
>
> Sent from my iPad
>
> On 18-May-2013, at 20:49, "Dickson S. Guedes"
> wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Em 18-05-2
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 poten
22 matches
Mail list logo
