Mark Butler <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>
> > Interesting. What advantages would there be?
>
> As any one who has ever attempted to build a C++ parser using Yacc or Bison
> can attest, it is very difficult to get an LALR based parser to correctly
> parse a sophisticated
"Henryk Szal" <[EMAIL PROTECTED]> writes:
> YES, I DO! My transaction can't wait.
> If parser on planner is blocked, then i want to abort my transaction.
What are your actual timing constraints? Is the constraint ``no
database table access may take longer than 10 seconds?'' Or is it
``no datab
mean,
what real world constraints do you need to satisfy? You aren't
putting in a timeout for your health. You are doing it to acheive
some goal. What is that goal?
I gave three sample goals, still below. Is one of them correct? Or
do you have a different one entirely?
Ian
> Ian Lance T
Tom Lane <[EMAIL PROTECTED]> writes:
> On Linux and BSD it seems to be more common to put /dev/kmem into a
> specialized group "kmem", so running postgres as setgid kmem is not so
> immediately dangerous. Still, do you think it's a good idea to let an
> attacker have open-ended rights to read yo
Jan Wieck <[EMAIL PROTECTED]> writes:
> IIRC the patch only provides the syntax for CURSOR to
> PL/pgSQL. Not real cursor support on the SPI level. So it's
> still the same as before, the backend will try to suck up the
> entire resultset into the SPI tuple table (that's
Jan Wieck <[EMAIL PROTECTED]> writes:
> I don't object if we can be sure that it's implementing the
> syntax a final version with *real* cursor support will have.
> Can we?
I don't know, and I don't know what the decision criteria are.
I intentionally implemented the Oracle curso
`make depend' is broken in the CVS sources. I've only tested it when
using a build directory which is different from the source directory,
but frankly it looks broken anyhow.
This is what I get:
make -C backend depend
make[1]: Entering directory `/home/ian/pgsql-objdir/src/backend'
for i in acc
This patch adds support for %TYPE in CREATE FUNCTION argument and
return types.
%TYPE is already supported by PL/pgSQL when declaring variables.
However, that does not help with the argument and return types in
CREATE FUNCTION.
Using %TYPE makes it easier to write a function which is independent
Tom Lane <[EMAIL PROTECTED]> writes:
> No. I'm not sure whether or not I believe the comment about Unix
> accounts; Postgres does not care about Unix accounts, and never has
> to my knowledge. But it has always used the usesysid as owner
> identification for database objects (tables etc). If t
Tom Lane <[EMAIL PROTECTED]> writes:
> Unfortunately "cvs log" isn't all that great about distinguishing
> branches from tags --- it calls 'em all "symbolic names".
Minor addition to this: you can distinguish branches and tags by using
`cvs status -v'.
(Historical note: CVS was originally imple
Tom Lane <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > If you want to make it more complicated, it would be more useful to
> > be able to set the value lower for runtime environments where PG is
> > competing for OS resources with another daemon that deserves higher
In this bit of code in src/pl/plpgsql/src/gram.y in the current CVS
sources, curname_def is defined as PLpgSQL_expr * but it is is
allocated the space required for a PLpgSQL_var. This looks like a
bug.
Ian
| decl_varname K_CURSOR decl_cursor_args decl_is_from
K_
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> >There could be DELETE operations for the tuple
> >from other backends also and the TID may disappear.
> >Because FULL VACUUM couldn't run while the cursor
> >is open, it could neither move nor remove the tuple
> >but I
Oracle PL/SQL supports a very convenient feature in which you can say
something like
DECLARE
CURSUR cur IS SELECT * FROM RECORD;
BEGIN
OPEN cur;
UPDATE record SET field = value WHERE CURRENT OF cur;
CLOSE cur;
END
We have cursors in the development version of PL/pgSQL, but t
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> > > My question now is: if there is no OID, is there any comparable way to
> > >
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > > > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > > > > Anyhow, I see that there is a move afoot to eliminate mandatory OIDs.
> > > > > My question now is: if there is no OID, is there any c
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> An Oracle compatibility mode wouldn't be a bad idea, but at what cost
> and at how much effort?
That is why I focused on the relatively minor changes to Postgres
required to hook in an alternate parser. I personally would not
expect the mainline Pos
Jan Wieck <[EMAIL PROTECTED]> writes:
> If we want to have both parsers available at runtime we need
> to replace the YY (case-insensitive) prefix in the generated
> files per parser and call the right one from tcop. Now for
> some flex/bison combo's at least the prefix switc
Alex Avriette <[EMAIL PROTECTED]> writes:
> Dont beat yourself up, guys, over making postgres a drop-in replacement for
> Oracle. The people that would benefit from actually "dropping in" postgres
> into an Oracle install will have already eased the burden on themselves by
> being responsible in
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > ... most of the cost will be paid by the people who care about
> > it. (Not all of the cost, because some communication will be required
> > when the parse tree nodes are c
Tom Lane <[EMAIL PROTECTED]> writes:
> Another bug report complaining of include file name conflicts came in
> just now. The only solution I can see is to rename config.h to
> something more project-specific. Should we do this, or keep ignoring
> the problem?
I would vote for renaming it. I'v
Jan Wieck <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
> > We do currently use $1 for params, so allowing dollar in the middle
> > seems better. However, I need to see multiple people who need it before
> > I would say OK. If we go adding things because _one_ person wants it,
> > we will
Lamar Owen <[EMAIL PROTECTED]> writes:
> Mailing lists don't scale well to large numbers of subscribers. I see this
> delay constantly,on multiple lists. The bigger the list gets, the slower the
> list gets (and the more loaded the server gets, right Marc? :-)).
Note that the postgresql.org
Tom Lane <[EMAIL PROTECTED]> writes:
> All the delay seems to be in transferring the message from
> postgresql.org to webmail.postgresql.org ... which are the same
> machine, or at least the same IP address. What's up with that?
You are seeing sendmail's poorly designed queuing behaviour in act
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> If it was a sendmail issue, by all means, but it isn't so no :)
Both qmail and postfix radically outperform sendmail for large mailing
list delivery on identical hardware. It seems strange to me to say
that there is no sendmail issue when sendmai
"Dwayne Miller" <[EMAIL PROTECTED]> writes:
> Well, for one I have no idea what cygwin is, or what it does to
> your system, or what security vulnerabilities it might add to your
> system. It comes with alot of stuff that I may or may not need, but
> what components I need to run Postgres
"Ken Hirsch" <[EMAIL PROTECTED]> writes:
> > (To be honest, the idea of worrying about security vulnerabilities on
> > Windows seems odd to me. If you are honestly worried about security
> > on your database server, the first step is to stop running Windows.)
>
> That's just a cheap shot. I've
Tom Lane <[EMAIL PROTECTED]> writes:
> > And no, "use syslog" doesn't count.
>
> Why not?
The standard implementations of syslog lose log entries under heavy
load, because they rely on a daemon which reads from a named pipe with
a limited buffer space. This is not acceptable in a production
sy
There seems to be a problem with the setup of the new anoncvs server.
I can not run `cvs update' on subdirectories after having done a
checkout.
I did this:
cvs -d :pserver:[EMAIL PROTECTED]:/projects/cvsroot co pgsql
Now I can do this:
cd pgsql
cvs update -l .
but I can not do this:
"D. Hageman" <[EMAIL PROTECTED]> writes:
> > you have a newer kernel scheduled implementation, then you will have the same
> > scheduling as separate processes. The only thing you will need to do is
> > switch your brain from figuring out how to share data, to trying to figure
> > out how to isol
Justin Clift <[EMAIL PROTECTED]> writes:
> Did anyone ever figure out why Solaris boxes had those random failures
> during the regression tests?
It should be better now that listen() is being called with a larger
number. The basic problem is that Solaris actually honors the
listen() backlog arg
I can't do `cvs update -d -P'. I get the following error:
cvs server: failed to create lock directory for
`/projects/cvsroot/pgsql/contrib/pgcrypto/expected'
(/projects/cvsroot/pgsql/contrib/pgcrypto/expected/#cvs.lock): Permission denied
cvs server: failed to obtain dir lock in repository
`/
Date: Fri, 1 Dec 2000 01:54:23 -0500 (EST)
From: Alex Pilosov <[EMAIL PROTECTED]>
On Thu, 30 Nov 2000, Nathan Myers wrote:
> After a power outage on an active database, you may have corruption
> at low levels of the system, and unless you have enormous redundancy
> (and actuall
by Ian Lance Taylor, [EMAIL PROTECTED], for use with
Taylor UUCP. */
#include "uucp.h"
#include "prot.h"
/* First, the polynomial itself and its table of feedback terms. The */
/* polynomial is */
/* X^32+X^26+X^23+X^22+X
Date: Sun, 17 Dec 2000 22:47:55 -0500
From: Tom Lane <[EMAIL PROTECTED]>
BUT: I think there's a race
condition here, at least on systems where errno is not saved and
restored around a signal handler. Consider the following scenario:
Postmaster is waiting at the select(
Date: Mon, 18 Dec 2000 10:41:47 -0500
From: Tom Lane <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Nathan Myers) writes:
> Sounds like a TODO list item: eliminate syscalls from signal handlers.
After looking at it some more, I think that's a lot easier said than
done. We could try wr
Date: Mon, 18 Dec 2000 13:18:26 -0500
From: Tom Lane <[EMAIL PROTECTED]>
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>Any thoughts on a cleaner solution?
> One way to avoid this race condition is to set a timeout on the
> select. What is the maximum
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> That would probably work, but I'm kind of hesitant to create an empty
> input file in cvs just to serve this marginal feature. (It wouldn't take
> /dev/null because it tries to use .//dev/null.) Moreover, the likely
> candidate name stamp-h.in is s
Does the SPI interface support recursion? That is, can a function
use SPI to make a query which involves calling another function which
uses SPI?
The documentation suggests not, saying that if a function which uses
SPI calls another function which uses SPI, it won't work, and calling
that ``bad
[EMAIL PROTECTED] (Nathan Myers) writes:
> An fprintf returning 0 is a suspicious event; it's easy to imagine
> cases where it makes sense, but I don't think I have ever coded one.
> Probably >N (where N is the smallest reasonable output, defaulting
> to 1) may be a better test in real code.
O
Tom Lane <[EMAIL PROTECTED]> writes:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> > I'm referring to the actual commit messages.
>
> It *would* be awfully nice if the pgsql-committers traffic were one
> message per commit, instead of one per directory touched per commit.
> This has been su
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The Hermit Hacker writes:
>
> > Done ... just tried adding white space to three files, in three
> > directories, and it seems to go through as one commit ...
> >
> > let's see what happens next time Tom makes a big change :)
>
> When Peter makes a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > > /home/projects/pgsql/cvsroot/CVSROOT/log_accum: not found
> >
> > Odd that it would work once.
> >
> > Is log_accum listed in the CVSROOT/checkoutlist file?
>
&g
Cursors are not supported in PL/pgSQL. I don't see a TODO item to fix
this.
Fixing the syntax to support cursors is easy. The problem then is
that PL/pgSQL uses SPI, and SPI does not support cursors. In spi.c
there is a bit of code for cursor support, with the comment
/* Don't work cur
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Interestingly, we have very few non-gcc ASM entries in s_lock.h. The
> only non-gcc one I see are Univel/i386, and I didn't touch that. Isn't
> the semicolon the standard command terminator for all gcc assemblers?
No.
It is for most, but not for the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > I believe the formatting problem was that some code had
> > > "command;command; : lkjasfd : asldfk" while some had them spread over
> > > separate lines, and others used \n\, all very randomly. Now at l
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> More importantly, you *should* *not* do these tests in configure because
> these tests will be unreliable in a cross-compilation situation.
> Cross-compilation in this context does not only mean compiling between
> completely different platforms, but
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > An approach I've followed in the past is to use three-way logic. If
> > configuring for a native system, compile and run a program which
> > provides a yes or no answer. When
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > This would seem to be the right answer, but unfortunately Autoconf is not
> > > smart enough to detect marginal cross-compilation cases in all situations.
> > > Someone had zlib installed in a location where gcc would find it (compiles
> > > okay
Frank Joerdens <[EMAIL PROTECTED]> writes:
> I just typed
>
> $ mount
>
> and I get
>
> /tmp on swap read/write/setuid on Mon Jan 22 16:39:32 2001
>
> for the /tmp directory, which looks distinctly odd to me. What kind of
> device is swap (I know what swap is normally but I didn't know you co
I wrote a patch to add cursor support to PL/pgSQL. I sent it to
pgsql-patches earlier, and Bruce said he would consider it after the
7.1 release.
I would be interested in getting feedback on it, so for now I have put
the patch up on the web:
http://www.airs.com/ian/pgsql-cursor.html
If you
[EMAIL PROTECTED] (Nathan Myers) writes:
> So now the question is, why did they write splogger?
``They'' didn't write splogger. Dan Bernstein did. It's part of the
qmail distribution. Unfortunately, the license probably precludes
including it with Postgres. Fortunately, it's only 72 lines lo
Tom Lane <[EMAIL PROTECTED]> writes:
> > Since mmap() is how everybody implements shared libraries,
>
> Now *there's* a sweeping generalization. Documentation of this
> claim, please?
I've seen a lot of shared library implementations (I used to be the
GNU binutils maintainer), and Nathan is ap
Tom Lane <[EMAIL PROTECTED]> writes:
> After thinking about this for a little, it seems to me that XID
> assignment should be handled more like OID assignment: rather than
> handing out XIDs one-at-a-time, varsup.c should allocate them in blocks,
> and should write an XLOG record to reflect the a
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > I think your example demonstrates something slightly different. I
> > think it demonstrates that Postgres must flush the XLOG entry to disk
> > before it flushes any buffe
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > I described myself unclearly. I was suggesting an addition to what
> > you are suggesting. The worst case can not be worse.
>
> Then I didn't (and still don't)
Tom Lane <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I wonder if the new Tips at the bottom of email messages can be enabled
> > for users during their first 30 days of mailing list subscription, then
> > not appear?
>
> I'm pretty durn tired of 'em, and it's not
"Vadim Mikheev" <[EMAIL PROTECTED]> writes:
> I feel that the fact that
>
> WAL can't help in the event of disk errors
>
> is often overlooked.
This is true in general. But, nevertheless, WAL can be written to
protect against predictable disk errors, when possible. Failing to
write a couple
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > > I feel that the fact that
> > >
> > > WAL can't help in the event of disk errors
> > >
> > > is often overlooked.
> >
> > This is true in general. But, nevertheless, WAL can be written to
> > protect against predictable disk errors, when poss
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> If fsync may return before data *actually* flushed then you may have
> unlogged data page changes which breakes WAL rule and means corrupted
> (inconsistent) database without ANY ABILITY TO RECOVERY TO CONSISTENT
> STATE. Now please explain me how sa
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > But we need it regardless --- if you didn't want a fully-allocated WAL
> > file, why'd you bother with the original seek-and-write-1-byte code?
>
> I considered this mostly as hint for OS about how log file should be
> allocated (to decrease fragm
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Let the actual method of allocating error codes be irrelevant for now,
> although the ones in the SQL standard are certainly to be considered for a
> start. Essentially, instead of writing
>
> elog(ERROR, "disaster struck");
>
> you'd write
>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>
> > I've suggested a couple of times that since we include install-sh in our
> > distro anyway, it's pointless and unnecessarily risky to go looking for
> > a platform-supplied install program. However, I could never quite get
>
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
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I understand the formalistic problem, and maybe I overstated its
> formality, but it seems it would be good to maintain a list for two
> reasons:
In projects like gcc and the GNU binutils, we use a MAINTAINERS file.
Some people have blanket write privi
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > In projects like gcc and the GNU binutils, we use a MAINTAINERS file.
> > Some people have blanket write privileges. Some people have write
> > priviliges to certain areas o
Tom Lane <[EMAIL PROTECTED]> writes:
> > Additionally, C99 (and GCC for a while) would allow filling in the
> > function name automatically.
>
> We could probably treat the function name as something that's optionally
> added to the file/line error report info if the compiler supports it.
>
> B
Tom Lane <[EMAIL PROTECTED]> writes:
> If you look closely, the configure test is not simply checking whether
> LL is accepted, it is checking whether we can construct an acceptable
> constant by macroized token-pasting. That's a slightly larger
> assumption, but it's the one the code must actua
Tom Lane <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > A safe way to construct a long long constant is to do it using an
> > expression:
> > uint64) 0xdeadbeef) << 32) | (uint64) 0xfeedface)
> > It's
Tom Lane <[EMAIL PROTECTED]> writes:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql/doc/src/sgml'
> > cd sgml && tar -cf ../programmer.tar --exclude=Makefile
> > --exclude='*.sgml' --exclude=ref *.html -C `cd . && pwd`/graphics
> > catalogs.gi
[EMAIL PROTECTED] (Nathan Myers) writes:
> Since the actual instruction sequence is probably lifted from the
> MIPS manual, it's probably much freer than GPL. For the paranoid,
> the actual instructions, extracted, are just
>
>1:
> ll %0,%3
> bnez %0,2f
> li %1,1
>
Date: Thu, 26 Oct 2000 20:49:22 -0400
From: Tom Lane <[EMAIL PROTECTED]>
Right. Also, I believe it's possible that such a grammar will behave
differently depending on which yacc you process it with, which would be
bad. (We have not yet taken the step of insisting that pgsql's gra
72 matches
Mail list logo
