[EMAIL PROTECTED] (Tom Lane) writes:
[snip]
On a filesystem that does have that kind of problem, can't you avoid it
just by using O_DSYNC on the WAL files? Then there's no need to call
fsync() at all, except during checkpoints (which actually issue sync()
not fsync(), anyway).
This comment
Hi all,
GCC has supported block re-ordering through __builtin_expect() for some
time. I could not see and cannot recall any discussion of this in the
archives. Has anyone played with GCC block re-ordering and PostgreSQL?
Gavin
---(end of
I've been getting only about 60% of the emails sent to the list.
I see many emails in the archives that I never got via email.
Is anyone else having this problems?
- Curtis
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go
tom lane writes:
The notion of a sort process pool seems possibly attractive. I'm
unconvinced that it's going to be a win though because of the cost of
shoving data across address-space boundaries.
What about splitting out parsing, optimization and plan generation from
execution and having a
Curtis Faith [EMAIL PROTECTED] writes:
Assume Transaction A which writes a lot of buffers and XLog entries,
so the Commit forces a relatively lengthy fsynch.
Transactions B - E block not on the kernel lock from fsync but on
the WALWriteLock.
You are confusing WALWriteLock with
Mats Lofkvist [EMAIL PROTECTED] writes:
[ mdsync is ugly and not completely reliable ]
Yup, it is. Do you have a better solution?
fsync is not the answer, since the checkpoint process has no way to know
what files may have been touched since the last checkpoint ... and even
if it could find
You are confusing WALWriteLock with WALInsertLock. A
transaction-committing flush operation only holds the former.
XLogInsert only needs the latter --- at least as long as it
doesn't need to write.
Well that make things better than I thought. We still end up with
a disk write for each
In particular, it would seriously degrade performance if the WAL file
isn't on its own spindle but has to share bandwidth with
data file access.
If the OS is stupid I could see this happening. But if there are
buffers and some sort of elevator algorithm the I/O won't happen
at bad times.
I
I believe I've missed some mails as well, but I think that was a day or two
ago. I don't think I've missed any in the last day.
Regards,
Jeff Davis
On Saturday 05 October 2002 06:41 am, Curtis Faith wrote:
I've been getting only about 60% of the emails sent to the list.
I see many
I currently develop an interface to simulate a
indexed sequential file management with PostgreSql. I must reproduce the same
philosophy used of control of locking of the records.
I seek a solution to lock and unlock implicitly a row of a
table. The locking of several rows, of the same
On Sat, 5 Oct 2002 00:29:03 -0400 (EDT), Bruce Momjian
[EMAIL PROTECTED] wrote:
OK, are we agreed to leave CURRENT_TIMESTAMP/now() alone and just add
now(string)? If no one replies, I will assume that is a yes and I
will add it to TODO.
So my view of CURRENT_TIMESTAMP not being spec compliant
Curtis Faith wrote:
Back-end servers would not issue fsync calls. They would simply block
waiting until the LogWriter had written their record to the disk, i.e.
until the sync'd block # was greater than the block that contained the
XLOG_XACT_COMMIT record. The LogWriter could wake up
pgman wrote:
Curtis Faith wrote:
Back-end servers would not issue fsync calls. They would simply block
waiting until the LogWriter had written their record to the disk, i.e.
until the sync'd block # was greater than the block that contained the
XLOG_XACT_COMMIT record. The LogWriter
Bruce Momjian kirjutas L, 05.10.2002 kell 13:49:
Curtis Faith wrote:
Back-end servers would not issue fsync calls. They would simply block
waiting until the LogWriter had written their record to the disk, i.e.
until the sync'd block # was greater than the block that contained the
Bruce Momjian wrote:
So every backend is to going to wait around until its fsync gets done by
the backend process? How is that a win? This is just another version
of our GUC parameters:
#commit_delay = 0 # range 0-10, in microseconds
#commit_siblings =
Tom Lane [EMAIL PROTECTED] writes:
Curtis Faith [EMAIL PROTECTED] writes:
The log file would be opened O_DSYNC, O_APPEND every time.
Keep in mind that we support platforms without O_DSYNC. I am not
sure whether there are any that don't have O_SYNC either, but I am
fairly sure that we
Hannu Krosing [EMAIL PROTECTED] writes:
The writer process should just issue a continuous stream of
aio_write()'s while there are any waiters and keep track which waiters
are safe to continue - thus no guessing of who's gonna commit.
This recipe sounds like eat I/O bandwidth whether we need
Manfred Koizar [EMAIL PROTECTED] writes:
And one last thought: There are applications out there that are not
written for one specific database backend. Having to replace
CURRENT_TIMESTAMP by PG-specific now('statement') is just one more
pain in trying to be portable across different
Tom Lane [EMAIL PROTECTED] writes:
In practice I am not sure there is a problem. The local man page for
sync() says
The writing, although scheduled, is not necessarily complete upon
return from sync.
Now if scheduled means will occur before any subsequently-commanded
write
It seems that the Hackers list isn't in the list to
subscribe/unsubscribe at http://developer.postgresql.org/mailsub.php
Just an FYI.
-Mitch
Computers are like Air Conditioners, they don't work when you open
Windows.
---(end of broadcast)---
Doug McNaught [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
In practice I am not sure there is a problem. The local man page for
sync() says
The writing, although scheduled, is not necessarily complete upon
return from sync.
Now if scheduled means will occur before any
Curtis Faith wrote:
The advantage to aio_write in this scenario is when writes cross track
boundaries or when the head is in the wrong spot. If we write
in reasonable blocks with aio_write the write might get to the disk
before the head passes the location for the write.
Consider a
En Fri, 04 Oct 2002 17:58:06 -0400
Tom Lane [EMAIL PROTECTED] escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm looking at implementing the btree reorganizer described in On-line
reorganization of sparsely-..., ACM SIGMOD proceedings 1996, by Zou and
Salzberg.
The title is On-line
Yes, I agree with you Manfred, but more people _don't_ want it to
change, and like it the way it is, so we will just keep it and add
now(string).
Added to TODO:
* Add now(transaction|statement|clock) functionality
I have attached an SGML patch that explains the issues with
So, you are saying that we may get back aio confirmation quicker than if
we issued our own write/fsync because the OS was able to slip our flush
to disk in as part of someone else's or a general fsync?
I don't buy that because it is possible our write() gets in as part of
someone else's
Curtis Faith wrote:
So, you are saying that we may get back aio confirmation quicker than if
we issued our own write/fsync because the OS was able to slip our flush
to disk in as part of someone else's or a general fsync?
I don't buy that because it is possible our write() gets in as
On Sat, 2002-10-05 at 20:32, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
The writer process should just issue a continuous stream of
aio_write()'s while there are any waiters and keep track which waiters
are safe to continue - thus no guessing of who's gonna commit.
This
No question about that! The sooner we can get stuff to the WAL buffers,
the more likely we will get some other transaction to do our fsync work.
Any ideas on how we can do that?
More like the sooner we get stuff out of the WAL buffers and into the
disk's buffers whether by write or
Curtis Faith wrote:
No question about that! The sooner we can get stuff to the WAL buffers,
the more likely we will get some other transaction to do our fsync work.
Any ideas on how we can do that?
More like the sooner we get stuff out of the WAL buffers and into the
disk's buffers
Alvaro Herrera [EMAIL PROTECTED] writes:
It seems to me I'll have to add some amount of lock types
in the lock manager. Does that bother you?
Such as?
There are three new lock modes: R, RX and RS (Reorganizer, Reorganizer
Exclusive and Reorganizer Shared). Actually, they are not new
Hannu Krosing [EMAIL PROTECTED] writes:
Or its solution ;) as instead of the predicting we just write all data
in log that is ready to be written. If we postpone writing, there will
be hickups when we suddenly discover that we need to write a whole lot
of pages (fsync()) after idling the disk
I spent a little time reviewing the xlog.c logic, which I hadn't looked
at in awhile. I see I made a mistake earlier: I claimed that only when
a backend wanted to commit or ran out of space in the WAL buffers would
it issue any write(). This is not true: there is code in XLogInsert()
that will
I do not think the situation for ganging of multiple commit-record
writes is quite as dire as has been painted. There is a simple error
in the current code that is easily corrected: in XLogFlush(), the
wait to acquire WALWriteLock should occur before, not after, we try
to acquire WALInsertLock
Curtis Faith [EMAIL PROTECTED] writes:
What about splitting out parsing, optimization and plan generation from
execution and having a separate pool of exececutor processes.
As an optimizer finished with a query plan it would initiate execution
by grabbing an executor from a pool and passing
34 matches
Mail list logo
