[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 comm
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 broadcast)--
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 to
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
"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 WALIn
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 tr
>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 man
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 tabl
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 com
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 commi
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 LogWri
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_sibli
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 su
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 n
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 ba
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-command
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)---
T
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 "wi
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 sc
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
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
CURRENT_
> 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
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() get
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.
>
> 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 aio_wri
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 buf
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 ar
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
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 t
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 an
"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 p
34 matches
Mail list logo
