On Fri, Feb 19, 2010 at 7:54 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Heikki Linnakangas wrote:
Magnus Hagander wrote:
Well, it's going to make the process that reads the WAL cause actual
physical I/O... That'll take a chunk out of your total available I/O,
which is
Heikki Linnakangas wrote:
Magnus Hagander wrote:
Well, it's going to make the process that reads the WAL cause actual
physical I/O... That'll take a chunk out of your total available I/O,
which is likely to push you to the limit of your I/O capacity much
quicker.
Right, doesn't seem
2010/2/18 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Fujii Masao wrote:
On Thu, Feb 18, 2010 at 5:28 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If I'm reading the patch correctly, when wal_sync_method is 'open_sync',
walreceiver nevertheless opens the WAL
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we are, which is the case here, it
should be really bad for performance, since we actually have to do a
physical read.
Incidentally, that should also apply to general
On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we are, which is the case here, it
should be really bad for performance,
2010/2/18 Fujii Masao masao.fu...@gmail.com:
On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we are, which is the case
Magnus Hagander wrote:
2010/2/18 Fujii Masao masao.fu...@gmail.com:
On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we
On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander mag...@hagander.net wrote:
In that case, O_DIRECT would be counterproductive, no? It maps to
FILE_FLAG_NOI_BUFFERING, which makes sure it doesn't go into the
cache. So the
On Wed, Feb 17, 2010 at 6:00 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander mag...@hagander.net wrote:
In that case, O_DIRECT would be counterproductive, no? It maps to
Fujii Masao wrote:
On Wed, Feb 17, 2010 at 6:00 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander mag...@hagander.net
wrote:
In that case, O_DIRECT would be
On Thu, Feb 18, 2010 at 5:28 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If I'm reading the patch correctly, when wal_sync_method is 'open_sync',
walreceiver nevertheless opens the WAL file without the O_DIRECT flag.
When it later flushes it in XLogWalRcvFlush() by
Fujii Masao wrote:
On Thu, Feb 18, 2010 at 5:28 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If I'm reading the patch correctly, when wal_sync_method is 'open_sync',
walreceiver nevertheless opens the WAL file without the O_DIRECT flag.
When it later flushes it in
On Tue, Feb 16, 2010 at 12:37 AM, Magnus Hagander mag...@hagander.net wrote:
With the libpq fixes, I get further (more on that fix later, btw), but
now I get stuck in this. When I do something on the master that
generates WAL, such as insert a record, and then try to query this on
the slave,
2010/2/16 Fujii Masao masao.fu...@gmail.com:
On Tue, Feb 16, 2010 at 12:37 AM, Magnus Hagander mag...@hagander.net wrote:
With the libpq fixes, I get further (more on that fix later, btw), but
now I get stuck in this. When I do something on the master that
generates WAL, such as insert a
On Tue, Feb 16, 2010 at 7:20 PM, Magnus Hagander mag...@hagander.net wrote:
2010/2/16 Fujii Masao masao.fu...@gmail.com:
On Tue, Feb 16, 2010 at 12:37 AM, Magnus Hagander mag...@hagander.net
wrote:
With the libpq fixes, I get further (more on that fix later, btw), but
now I get stuck in
2010/2/16 Fujii Masao masao.fu...@gmail.com:
On Tue, Feb 16, 2010 at 7:20 PM, Magnus Hagander mag...@hagander.net wrote:
2010/2/16 Fujii Masao masao.fu...@gmail.com:
On Tue, Feb 16, 2010 at 12:37 AM, Magnus Hagander mag...@hagander.net
wrote:
With the libpq fixes, I get further (more on that
On Wed, Feb 17, 2010 at 6:28 AM, Magnus Hagander mag...@hagander.net wrote:
If you send me your amazon id, I can get you premissions on my private
image. I plan to clean it up and make it public, just haven't gotten
around to it yet...
Thanks for your concern! I'll send the ID when I complete
On Wed, Feb 17, 2010 at 06:55, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 17, 2010 at 6:28 AM, Magnus Hagander mag...@hagander.net wrote:
If you send me your amazon id, I can get you premissions on my private
image. I plan to clean it up and make it public, just haven't gotten
around
Magnus Hagander mag...@hagander.net writes:
On Wed, Feb 17, 2010 at 06:55, Fujii Masao masao.fu...@gmail.com wrote:
2. Straightforwardly observe the alignment rule. Since the received WAL
data might start at the middle of WAL block, walreceiver needs to keep
the last half-written WAL block
On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander mag...@hagander.net wrote:
In that case, O_DIRECT would be counterproductive, no? It maps to
FILE_FLAG_NOI_BUFFERING, which makes sure it doesn't go into the
cache. So the read in the startup proc is actually guaranteed to
reuqire a physical
On Wed, Feb 17, 2010 at 3:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Wed, Feb 17, 2010 at 06:55, Fujii Masao masao.fu...@gmail.com wrote:
2. Straightforwardly observe the alignment rule. Since the received WAL
data might start at the middle of
21 matches
Mail list logo
