> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Other backend will see they are not the lowest
> > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > so they can then continue, knowing their data was synced.
>
> How will they wait? Without a semaphore involved, your answer
>> 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 t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Other backend will see they are not the lowest
> WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> so they can then continue, knowing their data was synced.
How will they wait? Without a semaphore involved, your answer must
be eit
> > sleep(3) should conform to POSIX specification, if anyone has the
> > reference they can check it to see what the effect of sleep(0)
> > should be.
>
> Yes, but Posix also specifies sched_yield() which rather explicitly
> allows a process to yield its timeslice. No idea how well that is
>
> > sleep(3) should conform to POSIX specification, if anyone has the
> > reference they can check it to see what the effect of sleep(0)
> > should be.
>
> Yes, but Posix also specifies sched_yield() which rather explicitly
> allows a process to yield its timeslice. No idea how well that is
>
Grant Finnemore <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 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...
> Yes, I am running WAL enabled.
OK, I put back the BufferSync call. Sorry '
Nathan Myers <[EMAIL PROTECTED]> writes:
>> * Oliver Elphick <[EMAIL PROTECTED]> [001117 16:41] wrote:
could the socket location be made a configurable parameter
in 7.1?
> /tmp is a bad place for this stuff anyway.
There have been *very long* discussions of this issue in the past,
see
The 7.1 code will the socket location configurable.
> At present the Unix socket's location is hard-coded as /tmp.
>
> As a result of a bug report, I have moved it in the Debian package to
> /var/run/postgresql/. (The bug was that tmpreaper was deleting it and
> thus blocking new connections.)
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> In PostgreSQL,'lock table' acquires a AccessExclusiveLock by default.
> IMHO ExclusiveLock is sufficient for ordinary purpose.
People who want that kind of lock can get it with LOCK TABLE IN
EXCLUSIVE MODE. I do not think it's a good idea to change t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Is there a reason why the conversion from CHAR to CHAR(1) is done in
> analyze.c:transformColumnType rather than right in the
> grammar?
Well, transformColumnType does database access, which is verboten during
the grammar phase. (The grammar has to
On Fri, Nov 17, 2000 at 04:49:43PM -0800, Alfred Perlstein wrote:
> * Oliver Elphick <[EMAIL PROTECTED]> [001117 16:41] wrote:
> > At present the Unix socket's location is hard-coded as /tmp.
> >
> > As a result of a bug report, I have moved it in the Debian package to
> > /var/run/postgresql/.
* Oliver Elphick <[EMAIL PROTECTED]> [001117 16:41] wrote:
> At present the Unix socket's location is hard-coded as /tmp.
>
> As a result of a bug report, I have moved it in the Debian package to
> /var/run/postgresql/. (The bug was that tmpreaper was deleting it and
> thus blocking new connect
At present the Unix socket's location is hard-coded as /tmp.
As a result of a bug report, I have moved it in the Debian package to
/var/run/postgresql/. (The bug was that tmpreaper was deleting it and
thus blocking new connections.)
I suppose that we cannot assume that /var/run exists across a
Hey Guys,
do you know of any intermediate to advanced
Postgres Courses in the UK prefereably in London and if not would anyone with
advanced knowledge be interested in setting some up.
Thanks,
Abe
> Bruce Momjian wrote:
> >
> > > I didn't want to do this during development, but now that there are no
> > > more old-style internal functions left, I suppose you could make a good
> > > argument that this is worth doing for old-style dynamically loaded
> > > functions. Will put it on the to-do
> > For that matter, I think past version updates haven't even forced
> > recompiles of user-defined functions, at least not ones that didn't poke
> > into system innards. We can't get away with requiring a source code
> > change --- people will scream about it.
>
> imho that is *not* sufficient
Bruce Momjian wrote:
>
> > I didn't want to do this during development, but now that there are no
> > more old-style internal functions left, I suppose you could make a good
> > argument that this is worth doing for old-style dynamically loaded
> > functions. Will put it on the to-do list.
> >
>
> For that matter, I think past version updates haven't even forced
> recompiles of user-defined functions, at least not ones that didn't poke
> into system innards. We can't get away with requiring a source code
> change --- people will scream about it.
imho that is *not* sufficient to keep fro
> -Original Message-
> From: Zeugswetter Andreas SB
>
> Since I see, that Tom has implemented the "keep a AccessShareLock
> lock until
> transaction end" philisophy I would like to state a protest.
>
> This is a fundamental change in behavior and I would like to see
> a vote on this.
Nathan Myers <[EMAIL PROTECTED]> writes:
> Why declare a function instead of a static struct?
Well, two reasons. One is that a function provides wiggle room if we
later decide that the library needs to do some computation before
handing back the function info struct. For example, Philip suggest
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I would support a single symbol to mark the entire object file. In
> fact, I would require old-style functions to add a symbol, and have
> new-style functions left alone.
That won't fly.
> There are not that many functions out there, are there? Peopl
On Fri, Nov 17, 2000 at 09:43:28PM +1100, Philip Warner wrote:
> At 10:39 16/11/00 +0100, Zeugswetter Andreas SB wrote:
> >
> >Has anybody had time to look at how this is done in DB/2, Oracle ? Philip ?
> >
>
> Don't know about Oracle or DB2, but Dec/RDB has:
>
Well, I don't know 'nuthing about
* Bruce Momjian <[EMAIL PROTECTED]> [001117 11:39]:
> > * Bruce Momjian <[EMAIL PROTECTED]> [001117 11:23]:
> > > > > sleep(3) should conform to POSIX specification, if anyone has the
> > > > > reference they can check it to see what the effect of sleep(0)
> > > > > should be.
> > > >
> > > > Y
> * Bruce Momjian <[EMAIL PROTECTED]> [001117 11:23]:
> > > > sleep(3) should conform to POSIX specification, if anyone has the
> > > > reference they can check it to see what the effect of sleep(0)
> > > > should be.
> > >
> > > Yes, but Posix also specifies sched_yield() which rather explicit
* Bruce Momjian <[EMAIL PROTECTED]> [001117 11:23]:
> > > sleep(3) should conform to POSIX specification, if anyone has the
> > > reference they can check it to see what the effect of sleep(0)
> > > should be.
> >
> > Yes, but Posix also specifies sched_yield() which rather explicitly
> > allow
> I didn't want to do this during development, but now that there are no
> more old-style internal functions left, I suppose you could make a good
> argument that this is worth doing for old-style dynamically loaded
> functions. Will put it on the to-do list.
>
> Are people satisfied with the no
> > sleep(3) should conform to POSIX specification, if anyone has the
> > reference they can check it to see what the effect of sleep(0)
> > should be.
>
> Yes, but Posix also specifies sched_yield() which rather explicitly
> allows a process to yield its timeslice. No idea how well that is
>
> > Just successfully loading an old-style C function doesn't
> > guarantee that it works anyway. I pointed out before that the
> > changes due to TOAST require each function that takes
> > arguments of varlen types to expect toasted values.
>
> Couldn't the functi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Couldn't the function handler detoast the values before handing them to
> the function? That would be slower, but it would allow people to continue
> to use the "simpler" interface.
This would be a moderately expensive thing to do --- not impossible
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> On what grounds do you claim that behavior is incorrect?
> Because SQL says so:
> ::=
> CHARACTER []
> | CHAR []
> | CHARACTER VARYING
> | CHAR VARYING
>
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Would it be reasonable to label these fields for their likely 7.2
> functionality, rather than labeling them as they are now? Since this is
> the first time they are appearing, it would be nice to not have to
> change the names later...
I don't have a
Jan Wieck writes:
> Just successfully loading an old-style C function doesn't
> guarantee that it works anyway. I pointed out before that the
> changes due to TOAST require each function that takes
> arguments of varlen types to expect toasted values.
Couldn't the
> > More to the point, I think we have to assume old-style interface if we
> > see ... LANGUAGE 'C' with no other decoration, because any other
> > assumption is guaranteed to break all existing user-defined functions.
>
> Just successfully loading an old-style C function doesn't
> g
Tom Lane wrote:
> To bring this back from future nice solutions to the reality of what
> to do today, do people like the "template0" solution for now (7.1)?
> I can work on it if so.
Go for it.
Jan
--
#==#
# It's easier t
Tom Lane wrote:
>
> More to the point, I think we have to assume old-style interface if we
> see ... LANGUAGE 'C' with no other decoration, because any other
> assumption is guaranteed to break all existing user-defined functions.
Just successfully loading an old-style C function doesn't
> 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...
Yes, I too am running with WAL enabled.
- Thomas
Since I see, that Tom has implemented the "keep a AccessShareLock lock until
transaction end" philisophy I would like to state a protest.
This is a fundamental change in behavior and I would like to see
a vote on this.
The one example we already know is:
session1
At 10:39 16/11/00 +0100, Zeugswetter Andreas SB wrote:
>
>Has anybody had time to look at how this is done in DB/2, Oracle ? Philip ?
>
Don't know about Oracle or DB2, but Dec/RDB has:
Create Function [Stored Name Is ] (...) Returns ;
[ External Name ] [ Location ]
[Langu
> Also, the grammar clause "LANGUAGE C" is actually part of the standard, so
> naming it "LANGUAGE stdC" will make it *less* standard. (Not that I buy
> Informix as being a "standard".)
I only quoted Informix, because it is the only one where I know how it works.
It might even be, that the Orac
> > >> 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 because people not wrapping
> > >large amounts of inserts/updates with transactio
Tom Lane wrote:
> 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 ag
41 matches
Mail list logo
