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...
> 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
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
PostgreS
On Thu, 16 Nov 2000, Alfred Perlstein wrote:
> * Larry Rosenman <[EMAIL PROTECTED]> [001116 12:09] wrote:
> > * 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?
> > >
Philip Warner <[EMAIL PROTECTED]> writes:
> So long as the version is always in the first bytes of the struct, we are
> covered for compatibility.
Right ...
> I'd still argue for a PG_FUNCTION_API_V2 macro for the reasons above. What
> the fmgrs needs to do is:
> - call pg_fmgr_api_version() to
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:
>>
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 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
>
> 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
> > BTW I would not recommend "SET CLIENT_ENCODING TO 'BIG5'" to do an
> > on-the-fly encoding changes. Since in this way, frontend side has no
> > idea what the client encoding is. 7.0.x overcome this problem by
> > introducing new \encoding command. For 6.5 or before I would recommend
> > to use
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 o
> 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
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;".
>
At 20:06 16/11/00 -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 thinking along
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 "__postg
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 thinking along the same lines myself. I'd want to do it on a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
> incorrectly interpreted as VARCHAR(). 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 behavior i
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 layo
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 refere
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> A long ago you, Bruce, made me gift - book about transaction processing
> (thanks again -:)). This sleeping before fsync in commit is described
> there as standard technique. And the reason is cleanest.
> Men, cost of fsync is very high! { write (64 b
Alfred Perlstein <[EMAIL PROTECTED]> writes:
>> That's the hard way to do it. We just need to keep track of the
>> endpoint of the log as of the last fsync.
> Well that breaks when you move to a overwriting storage manager,
No, because the log is just a series of records written sequentially --
> > > > 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
> > 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
* 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 wit
* 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
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
> > BUT, do we know for sure that sleep(0) is not optimized in
> > the library to just return?
>
> We can only do our best here. I think guessing whether other backends
> are _about_ to commit is pretty shaky, and sleeping every time is a
> waste. This seems the cleanest.
A long ago you, Bruc
On Thu, Nov 16, 2000 at 11:20:58AM -0500, Tom Lane wrote:
> I don't have any great love for the names 'C' and 'newC' either, but
> unless we are willing to break backward-compatibility of function
> declarations in 7.1, I think we are stuck with those names or ones
> isomorphic to them.
>
> In th
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 t
> * 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...
> >
* Larry Rosenman <[EMAIL PROTECTED]> [001116 12:09] wrote:
> * 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 migh
> > 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 m
> * 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
* 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 T
* 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 cer
> 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
* 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.
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.
> 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 i
There's a message on -general about a possible
problem in the deferred RI constraints. He was doing a
sequence like:
begin
delete
insert
end
and having it fail even though the deleted key was back in
place at the end.
My understanding of the spec is that that sequence should
I've been wondering the difference in varchar and TEXT in the aspect of
length and indexing - what would happen if you tried to index a
varchar(BLCKSZ) ? I know you can index smaller portions of text (at least it
appears you can) so why not larger alphanumeric data? (I'm not complaining,
just tryi
Bruce Momjian writes:
> OK, lets call the old style "stdC" and the new one "C".
The old style has the be 'C' because otherwise you break every old script,
including dumps for upgrades, and Lamar will *really* be on your case this
time. ;-)
Also, the grammar clause "LANGUAGE C" is actually part
Currently, CHAR is correctly interpreted as CHAR(1), but VARCHAR is
incorrectly interpreted as VARCHAR(). 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 truncate silen
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
[ Charset ISO-8859-1 unsupported, converting... ]
>
> > But we have very few Informix functions moving to PostgreSQL.
>
> I do not understand this comment.
> What you imho forget here is that a definition for an interface will eventually be
> included in the SQL standard.
> And it will be what
> But we have very few Informix functions moving to PostgreSQL.
I do not understand this comment.
What you imho forget here is that a definition for an interface will eventually be
included in the SQL standard.
And it will be what Oracle or DB/2 (maybe even Informix) does.
I conclude from prev
* Bruce Momjian <[EMAIL PROTECTED]> [001116 08:59] wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > > > > 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 m
[ Charset ISO-8859-1 unsupported, converting... ]
>
> > > Actually my proposal would be to not advertise "newC" in 7.1 and do
> > > some more research in that area until we have a solid and
> > maybe compatible
> > > interface that also makes the missing features possible
> > > (multiple column
> > Actually my proposal would be to not advertise "newC" in 7.1 and do
> > some more research in that area until we have a solid and
> maybe compatible
> > interface that also makes the missing features possible
> > (multiple columns and rows for return, enter the function
> more than once
>
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?
(src/backend/parser/scansup.c
On Thu, Nov 16, 2000 at 11:20:58AM -0500, Tom Lane wrote:
> 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
> 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 c
> Actually my proposal would be to not advertise "newC" in 7.1 and do
> some more research in that area until we have a solid and maybe compatible
> interface that also makes the missing features possible
> (multiple columns and rows for return, enter the function more than once
> to retrieve onl
[ Charset ISO-8859-1 unsupported, converting... ]
> > > > 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
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
On Thu, Nov 16, 2000 at 05:51:07PM +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 nom
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 go
Situation:
7.1 has a new backend interface for loadable modules. (but it
supports old 7.0 interface too)
Now the problem:
How do you tell the backend with what interface to use for
particular function? At the moment 7.1-cvs uses 'newC' instead
of 'C' in the LANGUAGE part.
But this no
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 abou
On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote:
>
> and possibly,
>
> Create Module foo_mod from library 'path-to-lib';
>
> The idea being to only store whe function signature and enough details to
> get to the info-function. If 'Create Module' were allowed, then it would
> a
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 co
> > 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 supp
> > To answer another misconception that I saw in this thread:
> >
> > : The old language names "internal" and "C" will continue to refer to
> > : functions with the old calling convention. We should deprecate
> > : old-style functions because of their portability problems, but the
> > : suppor
> > 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-
> >
64 matches
Mail list logo
