less work to do at fsync time, hopefully they have been written by the
OS background task during the spread and are not re-dirtied by other
backends.
Didier
On Sat, Jul 20, 2013 at 6:28 PM, Greg Smith g...@2ndquadrant.com wrote:
On 7/20/13 4:48 AM, didier wrote:
With your tests did you try to write the hot buffers first? ie buffers
with a high refcount, either by sorting them on refcount or at least
sweeping the buffer list in reverse?
I
Hi,
On Sat, Jul 20, 2013 at 6:28 PM, Greg Smith g...@2ndquadrant.com wrote:
On 7/20/13 4:48 AM, didier wrote:
That is the theory. In practice write caches are so large now, there is
almost no pressure forcing writes to happen until the fsync calls show up.
It's easily possible to enter
;
sysidentifier |= (uint32) (tv.tv_sec | tv.tv_usec);
should be
sysidentifier |= (uint32) (tv.tv_sec ^ tv.tv_usec);
Regards
Didier
discussed but why isn't postresql writing
sequentially its cache in a temporary file? With storage random speed at
least five to ten time slower it could help a lot.
Thanks
Didier
on)
Didier
Hi,
On Fri, Jul 26, 2013 at 11:42 AM, Greg Smith g...@2ndquadrant.com wrote:
On 7/25/13 6:02 PM, didier wrote:
It was surely already discussed but why isn't postresql writing
sequentially its cache in a temporary file?
If you do that, reads of the data will have to traverse
Hi,
On Fri, Jul 26, 2013 at 3:41 PM, Greg Smith
greg@2ndquadg...@2ndquadrant.com(needrant.comg...@2ndquadrant.com
wrote:
On 7/26/13 9:14 AM, didier wrote:
During recovery you have to load the log in cache first before applying
WAL.
Checkpoints exist to bound recovery time after a crash
Hi,
On Thu, Aug 29, 2013 at 2:35 PM, MauMau maumau...@gmail.com wrote:
Great! Could anybody find the root cause for the following memory leak
problem, and if possible, fix this?
http://www.postgresql.org/**message-id/**214653D8DF574BFEAA6ED53E545E99**
Hi
On Fri, Sep 20, 2013 at 5:11 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
I think we should go through the various implementations and make sure
they are actual compiler barriers and then change the documented policy.
From a quick
Hi,
IMO it's a bug if S_UNLOCK is a not a compiler barrier.
Moreover for volatile remember:
https://www.securecoding.cert.org/confluence/display/seccode/DCL17-C.+Beware+of+miscompiled+volatile-qualified+variables
Who is double checking compiler output? :)
regards
Didier
On Fri, Sep 20, 2013
Hi
fix a small memory leak in guc-file.l ParseConfigFile
AbsoluteConfigLocation() return a strdup string but it's never free or
referenced outside ParseConfigFile
Courtesy Valgrind and Noah Misch MEMPOOL work.
Regards
Didier
memory_leak_in_parse_config_file.patch
Description: Binary data
triggering the same assert for strcpy and gcc at
http://lists.gnu.org/archive/html/bug-bash/2013-07/msg00011.html.
Didier
hi
On Thu, Sep 4, 2014 at 7:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 4, 2014 at 3:09 AM, Ants Aasma a...@cybertec.at wrote:
On Thu, Sep 4, 2014 at 12:36 AM, Andres Freund and...@2ndquadrant.com
wrote:
It's imo quite clearly better to keep it allocated. For one after
Hi
Well, I'd like to hear someone from the field complaining that
pg_receivexlog is thrashing the cache and thus reducing the performance of
some other process. Or a least a synthetic test case that demonstrates that
happening.
It's not with pg_receivexlog but it's related.
On a small box
Hi,
Currently the value is hard code to NBuffers / 4 but ISTM that with
bigger shared_buffer it's too much, ie even with a DB 10 to 20 time
the memory size there's a lot of tables under this limit and nightly
batch reports are trashing the shared buffers cache as if there's no
tomorrow.
when I tried with promote. The old
master disconnects from the new. What am I missing?
I think you have to add
recovery_target_timeline = '2'
in recovery.conf
with '2' being the new primary timeline .
cf http://www.postgresql.org/docs/9.4/static/recovery-target-settings.html
Didier
--
Sent
...
What other useful actions can WAL receiver do while it's waiting? It doesn't
do much else than receive WAL, and fsync it to disk.
So now it will only need to do one of those two things.
Regards
Didier
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi
On Wed, Dec 17, 2014 at 2:39 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
didier wrote:
On many Linux systems it may not do that much (2.6.32 and 3.2 are bad,
3.13 is better but still it slows the fsync).
If there's a fsync in progress WALReceiver will:
1- slow the fsync because
on synchronization primitives and your
collision probability will be very close to 1.
Moreover they will write to the same cache lines for every fprintf
and this is very very bad even without atomic operations.
Regards
Didier
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Hi,
On Sat, Mar 21, 2015 at 8:42 PM, Fabien COELHO coe...@cri.ensmp.fr wrote:
Hello Didier,
If fprintf takes p = 0.025 (1/40) of the time, then with 2 threads the
collision probability would be about 1/40 and the delayed thread would be
waiting for half this time on average, so
to
look at whether the FK checking queries need to include explicit casts
...
Well, I reproduced the slowdown with some 20 to 30 different tables.
Anyway, glad I could be of some help, albeit only by testing some
(probably quite meaningless) border cases ... :)
Regards,
Didier
--
Didier Moens
the only thing that the 2 versions of
pgAdmin are doing differently. Even the PostgreSQL logs agree with that.
I'm relying on Didier for test results though as I don't have a test
system I can use for this at the moment.
But it gives us something to try - Didier can you create a new database
Dave Page wrote:
From what Tom has said in his reponse, I think the answer for you Didier
is to remap your integer columns to int8 instead of int4 and see what
happens. When I get a couple of minutes I will look at putting a Serials
as... Option in the type map.
Thanks Dave, for all of your
24 matches
Mail list logo
