Earlier, Vadim was talking about arranging to share fsyncs of the WAL
log file across transactions (after writing your commit record to the
log, sleep a few milliseconds to see if anyone else fsyncs before you
do; if not, issue the fsync yourself). That would offer less-than-
My solution would be to use INT_MIN for all ports, which has the advantage
that the above problematic comparison can be converted to !=,
since no integer will be smaller than INT_MIN.
I agree. When I was looking at this code this morning, I was wondering
what INT_MIN was supposed to
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
I agree. When I was looking at this code this morning, I was wondering
what INT_MIN was supposed to represent anyway, if NOSTART_ABSTIME is
INT_MIN + 1. I think someone messed this up between 4.2 and Postgres95.
Has there been any consensus
On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote:
On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote:
Create Module foo_mod from library 'path-to-lib';
Phil - be careful with the nomenclature. We've got another naming collision,
here. SQL9[29] talk about
At 05:51 PM 11/16/00 +0200, 'Marko Kreen' wrote:
On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote:
On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote:
Create Module foo_mod from library 'path-to-lib';
Phil - be careful with the nomenclature. We've got another
Marko Kreen [EMAIL PROTECTED] writes:
This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'".
Main difference is that the TYPE=0 means the old 'C' interface
and TYPE=1 means 'newC' interface. Default is 1.
This improves matters how, exactly? As far as I can see, this
Marko Kreen [EMAIL PROTECTED] writes:
This mostly like the current "CREATE FUNCTION .. LANGUAGE 'C'".
Main difference is that the TYPE=0 means the old 'C' interface
and TYPE=1 means 'newC' interface. Default is 1.
This improves matters how, exactly? As far as I can see,
Is there any guidelines on the formatting of the C code in
PG? As I was working on guc-file.l yesterday, I noticed
some things with LONG lines (I broke some of them up).
I was wondering if there were formal standards?
Also, do we care about extraneous #include's?
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this. I think a sleep(0) just before
the flush would be the best. It
* Don Baccus [EMAIL PROTECTED] [001116 13:46]:
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this. I think a
* Bruce Momjian [EMAIL PROTECTED] [001116 14:02]:
This sounds like an interesting approach, yes.
Question: Is sleep(0) guaranteed to at least give up control?
The way I read my UnixWare 7's man page, it might not, since alarm(0)
just cancels the alarm...
Well, it certainly
I have committed changes to keep reference counts for system cache entries.
This should eliminate the issues we've had with cache entries sometimes
getting dropped while still in use. Some notes:
1. The routine formerly called SearchSysCacheTuple is now SearchSysCache().
It increments the
At 12:59 16/11/00 -0800, Nathan Myers wrote:
- Keep the name 'C' for both old-style and new-style module declarations.
- Require that new-style modules define a distinguished symbol, such as
"int __postgresql_call_7_1;".
The module loader can look for symbols that start with
On Thu, Nov 16, 2000 at 08:06:30PM -0500, Tom Lane wrote:
Nathan Myers [EMAIL PROTECTED] writes:
- Keep the name 'C' for both old-style and new-style module declarations.
- Require that new-style modules define a distinguished symbol, such as
"int __postgresql_call_7_1;".
I was
Larry Rosenman [EMAIL PROTECTED] writes:
Is there any guidelines on the formatting of the C code in
PG? As I was working on guc-file.l yesterday, I noticed
some things with LONG lines (I broke some of them up).
I was wondering if there were formal standards?
Brace layout, comment
Philip Warner [EMAIL PROTECTED] writes:
I'd be inclined to define a macro that creates the signal object,
so that you'd write something like
PG_FUNCTION_API_V2(foo);
This sounds perfect. Would you generate an 'info' function to return a list
of entry points, or just use dummy object
Can someone tell me where we are on this? Tatsuo, I think you said you
wanted to apply this fix.
I wanted to apply the fix after Chih-Chang Hsieh tested it out. But he
said he couldn't becuase no test data was available for it. However I
and he now are in the same opinion that the fix seems
At 21:08 16/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
I'd be inclined to define a macro that creates the signal object,
so that you'd write something like
PG_FUNCTION_API_V2(foo);
...
What I was thinking was that the macro would expand either to
int
Philip Warner [EMAIL PROTECTED] writes:
For possible future compatibility, can you also do something like:
PG_FUNCTION_API_V2;
PG_FUNCTION_V2(foo);
PG_FUNCTION_V2(bar);
...
Where
PG_FUNCTION_API_V2 expands to:
int pg_fmgr_api_version(void) { return 2; }
And
At 22:10 16/11/00 -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
For possible future compatibility, can you also do something like:
PG_FUNCTION_API_V2;
PG_FUNCTION_V2(foo);
PG_FUNCTION_V2(bar);
...
Where
PG_FUNCTION_API_V2 expands to:
int
I did a CVS checkout today, and the following database creation fails.
In psql:-
You are now connected to database template1 as user postgres.
template1=# select version();
version
Is it just me?
I'm pretty sure I saw something similar on a newly initialized database.
The sequence was:
initdb
postmaster -i -o -F
createdb
psql
(database "thomas" not found)
psql template1
\d
(see "thomas")
psql
(database "thomas" found just fine)
- Thomas
Thomas Lockhart [EMAIL PROTECTED] writes:
Is it just me?
I'm pretty sure I saw something similar on a newly initialized database.
Are you guys running with WAL enabled? If so, this is probably the
BufferSync issue that Hiroshi thought I broke a couple days ago.
Let me know...
At 09:32 AM 11/16/00 -0800, Alfred Perlstein wrote:
* Bruce Momjian [EMAIL PROTECTED] [001116 08:59] wrote:
Ewe, so we have this 1/200 second delay for every transaction. Seems
bad to me.
I think as long as it becomes a tunable this isn't a bad idea at
all. Fixing it at 1/200 isn't
At 09:32 AM 11/16/00 -0800, Alfred Perlstein wrote:
* Bruce Momjian [EMAIL PROTECTED] [001116 08:59] wrote:
Ewe, so we have this 1/200 second delay for every transaction. Seems
bad to me.
I think as long as it becomes a tunable this isn't a bad idea at
all. Fixing it at 1/200 isn't so great
Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
incorrectly interpreted as VARCHAR(infinity). Any reason for that,
besides the fact that it of course makes much more sense than VARCHAR(1)?
Additionally, neither CHAR nor VARCHAR seem to bark on too long input,
they just
* Bruce Momjian [EMAIL PROTECTED] [001116 11:59] wrote:
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this.
In OS kernel design, you try to avoid process herding bottlenecks.
Here, we want them herded, and giving up the CPU may be the best way to
do it.
Yes, but if everyone yeilds you're back where you started, and with
128 or more backends do you really want to cause possibly that many
Bruce Momjian writes:
The way I read my UnixWare 7's man page, it might not, since alarm(0)
just cancels the alarm...
Well, it certainly is a kernel call, and most OS's re-evaluate on kernel
call return.
In glibc, sleep(0) just does "return 0;", so if the compiler has a good
day the
Alfred Perlstein [EMAIL PROTECTED] writes:
It might make more sense to keep a private copy of the last time
the file was modified per-backend by that particular backend and
a timestamp of the last fsync shared globally so one can forgo the
fsync if "it hasn't been dirtied by me since the last
* Tom Lane [EMAIL PROTECTED] [001116 13:31] wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
It might make more sense to keep a private copy of the last time
the file was modified per-backend by that particular backend and
a timestamp of the last fsync shared globally so one can forgo the
* Bruce Momjian [EMAIL PROTECTED] [001116 12:31] wrote:
In OS kernel design, you try to avoid process herding bottlenecks.
Here, we want them herded, and giving up the CPU may be the best way to
do it.
Yes, but if everyone yeilds you're back where you started, and with
128 or
You are going to kernel call/yield anyway to fsync, so why
not try and if someone does the fsync, we don't need to do it.
I am suggesting re-checking the need for fsync after the return
from sleep(0).
It might make more sense to keep a private copy of the last time
the file was
No. Checkpoints are to speedup after crash recovery and
to remove/archive log files. With WAL server doesn't write
any datafiles on commit, only commit record goes to log
(and log fsync-ed). Dirty buffers remains in memory long
Ok, so with CHECKPOINTS, we could move the offline
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this. I think a sleep(0) just before
the flush would be the best.
Peter Eisentraut [EMAIL PROTECTED] writes:
Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
incorrectly interpreted as VARCHAR(infinity). Any reason for that,
besides the fact that it of course makes much more sense than VARCHAR(1)?
On what grounds do you claim that
36 matches
Mail list logo
