On Saturday 10 March 2001 08:41, Tom Lane wrote:
> More numbers, these from a Powerbook G3 laptop running Linux 2.2:
Eeegghhh. Sorry... But where did you get O_DSYNC on Linux?
Maybe here?
bits/fcntl.h: # define O_DSYNC O_SYNC
There is no any O_DSYNC in the kernel... Even in the latest
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Ok, I've made changes in xlog.c and run tests:
Could you send me your diffs?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL P
> > So seems we can use O_DSYNC without losing log write performance
> > comparing with write() + fsync. Though, we didn't tested write() +
> > fdatasync() yet...
>
> Good point, we should check fdatasync() too --- although I have no
> machines where it's different from fsync().
I've tested it o
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> $ gcc -Wall -O -DINIT_WRITE -DUSE_DSYNC -DBLOCKS=1 tfsync.c
> ^^^
> You should use -DUSE_OSYNC to test O_SYNC.
Ooops ... let's hear it for cut-and-paste, and for sharp-eyed readers!
Just for completeness, here
> Starting to look like we should just use ODSYNC where available, and
> forget about dumping more per write ...
I'll run these tests on RedHat 7.0 tomorrow.
Vadim
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregist
More numbers, these from a Powerbook G3 laptop running Linux 2.2:
[tgl@g3 tmp]$ uname -a
Linux g3 2.2.18-4hpmac #1 Thu Dec 21 15:16:15 MST 2000 ppc unknown
[tgl@g3 tmp]$ gcc -Wall -O -DINIT_WRITE -DUSE_DSYNC -DBLOCKS=1 tfsync.c
[tgl@g3 tmp]$ time ./a.out
real0m32.418s
user0m0.020s
sys
> $ gcc -Wall -O -DINIT_WRITE -DUSE_DSYNC -DBLOCKS=1 tfsync.c
^^^
You should use -DUSE_OSYNC to test O_SYNC.
So you've tested N * write() + fsync(), exactly what I've asked -:)
> So I also see that there is no benefit to writing more than
> one block at a ti
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Tom, could you run this test for different block sizes?
> Up to 32*8k?
>>
>> You mean changing the amount written per write(), while holding the
>> total file size constant, right?
> Yes. Currently XLogWrite writes 8k blocks one by one. From what I'
Mark Bixby <[EMAIL PROTECTED]> writes:
> Is it possible to re-run failing regression tests individually?
I believe so, but it's not very convenient in the "runcheck" mode, since
that normally wants to make a fresh install and start a temporary
postmaster. Instead, do a real install, start a real
Tom Lane wrote:
> > But now runcheck dies during the install of PL/pgSQL, with createlang
> > complaining about a missing lib/plpgsql.sl.
>
> > I did do an MPE implementation of dynloader.c, but I was under the dim
> > impression this was only used for user-added functions, not core
> > functio
Mark Bixby <[EMAIL PROTECTED]> writes:
> So why is there a backend/global1.bki.source *and* a
> backend/catalog/global1.bki.source?
You don't want to know ;-) ... it's all cleaned up for 7.1 anyway.
I think in 7.0 you have to run make install in src/backend to get the
.bki files installed.
> But
Assume a configuration problem that causes standalone backends to fail
without doing anything. (I happened across this by tweaking global.bki
in such a way that the superuser name entered into pg_shadow was
different from what getpwname returns. I don't have a real-world
example, but I'm sure th
In article <[EMAIL PROTECTED]>, "Bruce Momjian"
<[EMAIL PROTECTED]> wrote:
> The problem I see with the shared memory idea is that some of the
> information needed may be quite large. For example, query strings can
> be very long. Do we just allocate 512 bytes and clip off the rest. And
> as I
Mark Bixby wrote:
> It seems that plpgsql.sl didn't get built. Might be an autoconf issue, since
> quite frequently config scripts don't know about shared libraries on MPE. I
> will investigate this further.
Ah. I found src/Makefile.shlib and added the appropriate stuff.
Woohoo! We have te
Tom Lane wrote:
> Oh, of course: foo.bar is not a single token to the boot scanner.
> It needs to be in quotes. Try this patch (line numbers are for 7.1
> but probably OK for 7.0.*)
>
...snip...
> --- src/include/catalog/pg_shadow.h Fri Mar 9 16:57:53 2001
...snip...
> ! DATA(insert OID =
> $ gcc -Wall -O -DINIT_WRITE tfsync.c
> $ time a.out
>
> real1m15.11s
> user0m0.04s
> sys 0m32.76s
>
> Note the large amount of system time here, and the fact that the extra
> time in INIT_WRITE is all system time. I have previously
> observed that fsync() on HPUX 10.20 appears to
> I tried this on HPUX 10.20, which has not only O_SYNC but also O_DSYNC
> (defined to do the equivalent of fdatasync()), and got truly
> fascinating results. Apparently, on this platform these flags change
> the kernel's buffering behavior! Observe:
Solaris 2.6 fascinates even more!!!
> $ gcc
Tom Lane wrote:
>
> Mark Bixby <[EMAIL PROTECTED]> writes:
> > I just hacked src/test/regress/run_check.sh to invoke initdb with
> > --show. The user name/id is behaving "correctly" for an MPE machine:
>
> > SUPERUSERNAME: MGR.BIXBY
> > SUPERUSERID:484
>
> Okay, so much for that theory.
Mark Bixby <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> But none of these fully explain Mark's problem. If we knew where the
>> "syntax error 25 : -> ." came from, we'd be closer to an answer.
> After scanning the source for "syntax error", line 126 of
> backend/bootstrap/bootscanner.l seems
Now you're talking about i18n, maybe someone could think about input and
output of dates in local language.
As fas as I can tell, PostgreSQL will only use English for dates, eg January,
February and weekdays, Monday, Tuesday etc. Not the local name.
--
Kaare Rasmussen--Linux, spil,-
Tom Lane <[EMAIL PROTECTED]> writes:
> We just bought back almost all the system time. The only possible
> explanation is that this way either doesn't keep the buffers from prior
> blocks, or does not scan them for dirtybits. I note that the open(2)
> man page is phrased so that O_SYNC is actua
Tom Lane wrote:
> But none of these fully explain Mark's problem. If we knew where the
> "syntax error 25 : -> ." came from, we'd be closer to an answer.
After scanning the source for "syntax error", line 126 of
backend/bootstrap/bootscanner.l seems to be the likely culprit.
--
[EMAIL PROTECT
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> cat "$GLOBAL" \
> | sed -e "s/POSTGRES/$POSTGRES_SUPERUSERNAME/g" \
> -e "s/PGUID/$POSTGRES_SUPERUSERID/g" \
> | "$PGPATH"/postgres $BACKENDARGS template1
> For some reason the line probably ends up being
> insert OID = 0 ( MGR BIX
Jeff Lu writes:
> $ make intrasend
> gcc -o /c/inetpub/wwwroot/cgi-bin/intrasend.exe intrasend.c
> intrautils.c -I/usr/
> local/pgsql/include -L/usr/local/pgsql/lib
-lpq
> intrautils.c:7: warning: initialization makes integer from pointer without a
> cas
> t
> /c/TEMP/ccXES02E.o(.text+0x32c):in
Mark Bixby writes:
> Creating global relations in /blah/blah/blah
> ERROR: pg_atoi: error in "BIXBY": can't parse "BIXBY"
> ERROR: pg_atoi: error in "BIXBY": can't parse "BIXBY"
> syntax error 25 : -> .
I'm curious about that last line. Is that the shell complaining?
The offending command se
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Well, SQL defines these. Do we want to make our own list? However,
> numeric codes also have the advantage that some hierarchy is possible.
> E.g., the "22" in "2200G" is actually the category code "data exception".
> Personally, I would stick to th
Tom Lane writes:
> I object to writing "2200G" however, because that has no mnemonic value
> whatever, and is much too easy to get wrong. How about
>
> elog(ERROR, ERR_TYPE_MISMATCH, "type mismatch in argument %d of function %s,
> expected %s, got %s", ...);
>
> where ERR_TYPE_MISMATCH is #
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> True. But at least the write is (hopefully) being done at a
>> non-performance-critical time.
> There is no such hope: XLogWrite may be called from XLogFlush
> (at commit time and from bufmgr on replacements) *and* from XLogInsert
> - ie new log fi
Mark Bixby <[EMAIL PROTECTED]> writes:
> I just hacked src/test/regress/run_check.sh to invoke initdb with
> --show. The user name/id is behaving "correctly" for an MPE machine:
> SUPERUSERNAME: MGR.BIXBY
> SUPERUSERID:484
Okay, so much for that theory.
Can you set a breakpoint at elog()
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Seems that my Solaris has fdatasync, so I'll test different approaches...
A Sun guy told me that Solaris does this just the same way that HPUX
does it: fsync() scans all kernel buffers for the file, but O_SYNC
doesn't, because it knows it only needs
> > But needed if we want to get rid of vacuum and have savepoints.
>
> Hmm. How do you implement savepoints ? When there is rollback
> to savepoint do you use xlog to undo all changes which the particular
> transaction has done ? Hmmm it seems nice ... these resords are locked by
> such trans
> The reason I'm inclined to question this is that what we want
> is not an fsync per write but an fsync per transaction, and we can't
> easily buffer all of a transaction's XLOG writes...
WAL keeps records in WAL buffers (wal-buffers parameter may be used to
increase # of buffers), so we can m
> > Even with true fdatasync it's not obviously good for
> > performance - it takes too long time to write 16Mb files
> > and fills OS buffer cache with trash-:(
>
> True. But at least the write is (hopefully) being done at a
> non-performance-critical time.
There is no such hope: XLogWrite ma
Tom Lane wrote:
>
> Mark Bixby <[EMAIL PROTECTED]> writes:
> > MPE is a proprietary OS with a POSIX layer on top. The concept of
> > POSIX uids and gids has been mapped to the concept of MPE usernames
> > and MPE accountnames. An example MPE username would be "MGR.BIXBY",
> > and if you do a
On Fri, Mar 09, 2001 at 12:05:22PM -0500, Tom Lane wrote:
> > Gettext takes care of this. In the source you'd write
>
> > elog(ERROR, "2200G", gettext("type mismatch in CASE expression (%s vs %s)"),
> > string, string);
>
> Duh. For some reason I was envisioning the localization su
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Let's say "type mismatch error", code 2200G acc. to SQL. At one place in
> > the source you write
> > elog(ERROR, "2200G", "type mismatch in CASE expression (%s vs %s)", ...);
Tom Lane <[EMAIL PROTECTED]> spake:
> I object to writing "2200G" how
Mark Bixby <[EMAIL PROTECTED]> writes:
> MPE is a proprietary OS with a POSIX layer on top. The concept of
> POSIX uids and gids has been mapped to the concept of MPE usernames
> and MPE accountnames. An example MPE username would be "MGR.BIXBY",
> and if you do a POSIX getpwuid(getuid()), the c
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> I attach my modified version of Andreas' program. Note I do not
>> believe his assertion that close() implies fsync() --- on the
>> machines I've used, it demonstrably does not sync.
> Ok, I am not sure, but essentially do we need it to sync
Hi pgsql-hackers,
I'm currently porting 7.0.3 to the HP MPE/iX OS to join my other ports of
Apache, BIND, sendmail, Perl, and others. I'm at the point where I'm trying to
run the "make runcheck" regression tests, and I've just run into a problem
where I need to seek the advice of psql-hackers.
> >> This seems odd. As near as I can tell, O_SYNC is simply a command to do
> >> fsync implicitly during each write call. It cannot save any I/O unless
> >> I'm missing something significant. Where is the performance difference
> >> coming from?
>
> > Yes, odd, but sure very reproducible her
> > > Of course we would need to buffer >= 1 xlog page before write (or commit)
> > > to gain the full advantage.
> >
> > > prewrite 0 + write and fsync: 60.4 sec
> > > sparse file + write with O_SYNC: 37.5 sec
> > > no prewrite + write with O_SYNC: 36.8 sec
> > > p
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> This seems odd. As near as I can tell, O_SYNC is simply a command to do
>> fsync implicitly during each write call. It cannot save any I/O unless
>> I'm missing something significant. Where is the performance difference
>> coming from?
> Y
> > A short test shows, that opening the file O_SYNC, and thus avoiding fsync()
> > would cut the effective time needed to sync write the xlog more than in half.
> > Of course we would need to buffer >= 1 xlog page before write (or commit)
> > to gain the full advantage.
>
> > prewrite 0 + write
OK, I have finished the first version of my performance monitor. You
can get the TCL code at:
ftp://candle.pha.pa.us/pub/postgresql/pgtop.tcl
Once people like it, I will add it to CVS /contrib. It probably will
only work only *BSD and Linux right now. It tries to find the USER and
COM
Boulat Khakimov <[EMAIL PROTECTED]> writes:
> I'm wondering how safe it is to pass an uninitialized conn to
> PQfinish
You can pass a NULL pointer to PQfinish safely, if that's what you
meant. Passing a pointer to uninitialized memory seems like a bad
idea.
regards,
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> A short test shows, that opening the file O_SYNC, and thus avoiding fsync()
> would cut the effective time needed to sync write the xlog more than in half.
> Of course we would need to buffer >= 1 xlog page before write (or commit)
> to gain th
> > Even with true fdatasync it's not obviously good for performance - it takes
> > too long time to write 16Mb files and fills OS buffer cache
> with trash-:(
> >>
> >> True. But at least the write is (hopefully) being done at a
> >> non-performance-critical time.
>
> > So you have non criti
Hi,
I'm wondering how safe it is to pass an uninitialized conn to
PQfinish
I have set a SIGALRM handler that terminates my daemon and closes
connection
to Postgres if time-out happens. However, Im setting the alarm few times
before the connection to Postgres was established... which means th
Richard Poole <[EMAIL PROTECTED]> writes:
> [ snip a bunch of commentary about optimizer statistics ]
> Can someone who really knows this stuff (Tom?) step in if what I've
> just said is completely wrong?
Looked good to me.
>> select domain from history_entries group by domain;
>>
>> To me, sin
Karel Zak writes:
> For transaltion to other languages I not sure with gettext() stuff on
> backend -- IMHO better (faster) solution will postgres system catalog
> with it.
elog(ERROR, "cannot open message catalog table");
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Let's say "type mismatch error", code 2200G acc. to SQL. At one place in
> the source you write
> elog(ERROR, "2200G", "type mismatch in CASE expression (%s vs %s)", ...);
> Elsewhere you'd write
> elog(ERROR, "2200G", "type mismatch in argument %d o
Tom Lane writes:
> I guess I don't understand what you have in mind, because this seems
> self-contradictory. If "client programs can look at the code only",
> then how can the error message text be chosen independently of the code?
Let's say "type mismatch error", code 2200G acc. to SQL. At o
Christopher Kings-Lynne writes:
> In case anyone cares, there is a bug in pg_dump in 7.0.3 when using the bit
> fields.
There are no bit fields in 7.0, at least no officially. 7.1 does support
them.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> That's exactly what I was trying to avoid. You'd still be allowed to
> choose the error message text freely, but client programs will be able to
> make sense of them by looking at the code only, as opposed to parsing the
> message text. I'm trying t
Tom Lane writes:
> There's a difficult tradeoff to make here, but I think we do want to
> distinguish between the "official error code" --- the thing that has
> translations into various languages --- and what the backend is actually
> allowed to print out. It seems to me that a fairly large fra
Nathan Myers writes:
> > elog(ERROR, "XYZ01", gettext("stuff happened"));
>
> Similar approaches have been tried frequently, and even enshrined
> in standards (e.g. POSIX catgets), but have almost always proven too
> cumbersome. The problem is that keeping programs that interpret the
> numer
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Even with true fdatasync it's not obviously good for performance - it takes
> too long time to write 16Mb files and fills OS buffer cache with trash-:(
>>
>> True. But at least the write is (hopefully) being done at a
>> non-performance-criti
> > Pros: upper layers can think thet buffers are always safe/logged and
> > there is no special handling for indices; very simple/fast redo
> > Cons: can't implement undo - but in non-overwriting is not needed (?)
>
> But needed if we want to get rid of vacuum and have savepoints.
Hmm. Ho
> > BTW, what means "bummer" ?
>
> Sorry, it means, "Oh, I am disappointed."
thanks :)
> > But for many OSes you CAN control when to write data - you can mlock
> > individual pages.
>
> mlock() controls locking in physical memory. I don't see it controling
> write().
When you mmap, you don't
> For transaltion to other languages I not sure with gettext() stuff on
> backend -- IMHO better (faster) solution will postgres system catalog
> with it.
>
> May be add new command too: SET MESSAGE_LANGUAGE TO , because
> wanted language not must be always same as locale setting.
In the multi
> > Even with true fdatasync it's not obviously good for performance - it takes
> > too long time to write 16Mb files and fills OS buffer cache with trash-:(
>
> True. But at least the write is (hopefully) being done at a
> non-performance-critical time.
So you have non critical time every fiv
On Thu, Mar 08, 2001 at 09:00:09PM -0500, Tom Lane wrote:
> > On Thu, Mar 08, 2001 at 11:49:50PM +0100, Peter Eisentraut wrote:
> >> I really feel that translated error messages need to happen soon.
>
> Agreed.
Yes, error codes is *very* wanted feature.
>
> ERROR: Attribute "foo" not fo
62 matches
Mail list logo
