On Tue, Aug 19, 2014 at 4:27 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
Few more comments:
Some more comments:
1. I could see one shortcoming in the way the patch has currently
parallelize the
work for --analyze-in-stages. Basically patch is performing the work for
each stage
for
Add --limit to limit latency under throttling
Under throttling, transactions are scheduled for execution at certain times.
Transactions may be far behind schedule and the system may catch up with the
load later. This option allows to change this behavior by skipping
transactions which are
On Sun, Aug 24, 2014 at 12:34 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 08/24/2014 09:40 AM, Haribabu Kommi wrote:
Any suggestions?
Another point I didn't raise first time around, but that's IMO quite
significant, is that you haven't addressed why this approach to fully
parallel
On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 07/25/2014 07:10 PM, Alexey Klyukin wrote:
Greetings,
I'd like to propose a patch for checking subject alternative names entry
in
the SSL certificate for DNS names during SSL authentication.
Thanks!
Tomas Vondra t...@fuzzy.cz writes:
I stopped the already running test on addax and started the test on
barnacle again. Let's see in a few days/weeks/months what is the result.
It seems to be running much faster (probably after removing the
randomization), and apparently it passed the
On 24.8.2014 18:01, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
I stopped the already running test on addax and started the test on
barnacle again. Let's see in a few days/weeks/months what is the result.
It seems to be running much faster (probably after removing the
randomization),
Tomas Vondra t...@fuzzy.cz writes:
Regarding those leaks we've detected so far - is it the kind of leaks
that can happen only in testing with those specific flags, or is it
something that can happen in production too? (Assuming no one is running
with CLOBBER_CACHE_RECURSIVELY in production, of
On 24.8.2014 18:28, Tom Lane wrote:
Tomas Vondra t...@fuzzy.cz writes:
Regarding those leaks we've detected so far - is it the kind of leaks
that can happen only in testing with those specific flags, or is it
something that can happen in production too? (Assuming no one is running
with
On Thu, Aug 21, 2014 at 6:20 PM, Josh Berkus j...@agliodbs.com wrote:
On 08/20/2014 03:42 PM, Arthur Silva wrote:
What data are you using right now Josh?
The same data as upthread.
Can you test the three patches (9.4 head, 9.4 with Tom's cleanup of
Heikki's patch, and 9.4 with Tom's
On 22 August 2014 23:02, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
heap_lock_tuple() has the following comment on top:
* In the failure cases, the routine fills *hufd with the tuple's t_ctid,
* t_xmax (resolving a possible MultiXact, if necessary), and t_cmax
* (the last only for
Thanks for the replies and thoughts.
On 08/19/14 18:27, Heikki Linnakangas wrote:
On 08/20/2014 12:17 AM, John Lumby wrote:
I am attaching a new version of the patch for consideration in the
current commit fest.
Thanks for working on this!
Relative to the one I submitted on 25 June in
Folks,
Quoth our docs
(http://www.postgresql.org/docs/9.3/static/sql-alterdatabase.html):
The fourth form changes the default tablespace of the database. Only
the database owner or a superuser can do this; you must also have create
privilege for the new tablespace. This command physically moves
On 24 August 2014 22:04, Thomas Munro mu...@ip9.org wrote:
On 22 August 2014 23:02, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Did you consider heap_lock_updated_tuple? A rationale for saying it
doesn't need to pay attention to the wait policy is: if you're trying to
lock-skip-locked an
On 08/25/2014 09:44 AM, Thomas Munro wrote:
On 24 August 2014 22:04, Thomas Munro mu...@ip9.org wrote:
On 22 August 2014 23:02, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Did you consider heap_lock_updated_tuple? A rationale for saying it
doesn't need to pay attention to the wait policy
Thomas Munro wrote:
While trying to produce the heap_lock_updated_tuple_rec case you
describe (so far unsuccessfully), I discovered I could make SELECT ...
FOR UPDATE NOWAIT block indefinitely on unpatched 9.3 in a different
code path after heap_lock_tuple returns: in another session, UPDATE,
On Wed, Jul 30, 2014 at 9:11 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
I have verified the patch and found that it works well for
all scenario's. Few minor suggestions:
1.
!values to the filenamepostgresql.auto.conf/filename file.
!Setting the parameter to
Le 8 août 2014 09:08, Guillaume Lelarge guilla...@lelarge.info a écrit :
Hi,
As part of our monitoring work for our customers, we stumbled upon an
issue with our customers' servers who have a wal_keep_segments setting
higher than 0.
We have a monitoring script that checks the number of WAL
Robert == Robert Haas robertmh...@gmail.com writes:
Robert I can accept ugly code, but I feel strongly that we shouldn't
Robert accept ugly semantics. Forcing cube to get out of the way
Robert may not be pretty, but I think it will be much worse if we
Robert violate the rule that quoting a
18 matches
Mail list logo
