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 found --
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 five
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 xxx, because
wanted language not must be always same as locale setting.
In the
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 use
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. How do
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-critical time.
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
numeric
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
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 to
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/
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 one
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 of
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, since there
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
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
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 the full
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, tom
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 here.
I tried
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.
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? The OS
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
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" however,
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
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 POSIX
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 may be
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
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 transaction
"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 to
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() and
"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 file may
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
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 the SQL
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 seems
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
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 BIXBY 484
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
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 actually
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,
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.
Can you
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
$ 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 iterate
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 test
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 add
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
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 now
"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've seen
$ 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 time
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
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
"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 are
"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
51 matches
Mail list logo
