Nathan Myers wrote:
> On Mon, Apr 23, 2001 at 03:09:53PM -0300, The Hermit Hacker wrote:
> >
> > Anyone thought of implementing this, similar to how sendmail does it? If
> > load > n, refuse connections?
> > ...
> > If nobody is working on something like this, does anyone but me feel that
> > it
Hi,
I just got trapped by one of my own features in the
referential integrity area.
The problem is, that the trigger run on the FK row at UPDATE
allways checks and locks the referenced PK, even if the FK
attributes didn't change. That's because if there'd be an
Bruce Momjian wrote:
> > A different approach that's been discussed on pghackers is to make use
> > of btree indexes for columns that have such indexes: we could scan the
> > indexes to visit all the column values in sorted order. I have rejected
> > that approach because (a) it doesn't help for
Philip Warner wrote:
> At 08:42 19/04/01 -0500, Jan Wieck wrote:
> [...]
> >and the required
> >feature to correctly restore the tgconstrrelid is already in
> >the backend, so pg_dump should make use of it
>
> No problem there - just tell me how...
Philip Warner wrote:
> At 16:25 18/04/01 -0400, Joel Burton wrote:
> >
> >Do we know if the problem is in pg_dump, or is there no way
> >to pass the tgconstrrelid value in the CREATE CONSTRAINT TRIGGER
> >statement?
> >
>
> It's because pg_dump is not designed to dump these constraints *as*
> cons
Bruce Momjian wrote:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > FYI, the WU-FTPD code (2.6.0 or better) has a couple of more platforms
> > > including UnixWare. The UnixWare code will need /dev/kmem permission to
> > > change it's stuff, so I don't know whether we want to do this or not
Bruce Momjian wrote:
> I have talked to Jan over the phone, and he has convinced me that UDP is
> the proper way to communicate stats to the collector, rather than my
> shared memory idea.
>
> The advantages of his UDP approach is that the collector can sleep on
> the UDP socket rather than having
Bruce Momjian wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Only shared memory gives us near-zero cost for write/read. 99% of
> > > backends will not be using stats, so it has to be cheap.
> >
> > Not with a circular buffer it's not cheap, because you need interlocking
> > on writes.
Tom Lane wrote:
> Samuel Sieb <[EMAIL PROTECTED]> writes:
> > Just as another suggestion, what about sending the data to a different
> > computer, so instead of tying up the database server with processing the
> > statistics, you have another computer that has some free time to do the
> > processi
Philip Warner wrote:
> At 13:49 16/03/01 -0500, Jan Wieck wrote:
> >
> >Similar problem as with shared memory - size. If a long
> >running backend of a multithousand table database needs to
> >send access stats per table - and had accessed them all
Jan Wieck wrote:
> Tom Lane wrote:
> > Now this would put a pretty tight time constraint on the collector:
> > fall more than 4K behind, you start losing data. I am not sure if
> > a UDP socket would provide more buffering or not; anyone know?
>
> Looks like Li
Tom Lane wrote:
> Now this would put a pretty tight time constraint on the collector:
> fall more than 4K behind, you start losing data. I am not sure if
> a UDP socket would provide more buffering or not; anyone know?
Looks like Linux has something around 16-32K of buffer space
for UDP
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Does a pipe guarantee that a buffer, written with one atomic
> > write(2), never can get intermixed with other data on the
> > readers end?
>
> Yes. The HPUX man page for write(2) sez
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Uh - not much time to spend if the statistics should at least
> > be half accurate. And it would become worse in SMP systems.
> > So that was a nifty idea, but I think it'd cause much mo
Alfred Perlstein wrote:
> * Jan Wieck <[EMAIL PROTECTED]> [010316 08:08] wrote:
> > Philip Warner wrote:
> > >
> > > But I prefer the UDP/Collector model anyway; it gives use greater
> > > flexibility + the ability to keep stats past backend termination,
Philip Warner wrote:
>
> But I prefer the UDP/Collector model anyway; it gives use greater
> flexibility + the ability to keep stats past backend termination, and,as
> you say, removes any possible locking requirements from the backends.
OK, did some tests...
The postmaster can create a
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > What about a collector deamon, fired up by the postmaster and
> > receiving UDP packets from the backends. Under heavy load, it
> > might miss some statistic messages, well, but that's not
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > What about a collector deamon, fired up by the postmaster and
> > receiving UDP packets from the backends. Under heavy load, it
> > might miss some statistic messages, well, but that's not
Michael Meskes wrote:
> Is anyone on this list in Hannover for CeBit? Maybe we could arrange a
> meeting.
Looks pretty much that I'll be still in Hamburg by then. What
are the days you planned?
Jan
--
#==#
# It's easi
Bruce Momjian wrote:
>
> Yes, it seems storing info in shared memory and having a system table to
> access it is the way to go.
Depends,
first of all we need to know WHAT we want to collect. If we
talk about block read/write statistics and such on a per
table base, which
Tom Lane wrote:
> Pam Withnall <[EMAIL PROTECTED]> writes:
> > in my java code I am creating 3 temporary tables, then calling a stored
> > procedure which calls another stored procedure.
> > then I drop the temporary tables.
> > the first time around , eveything is OK , then when repeating the ac
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > I like this one - except for the OID which should IMHO read
> > INSERTED_OID.
>
> I just committed changes that make it RESULT_OID, but if you like
> INSERTED_OID better, we could change it...
Philip Warner wrote:
>
> Unfortunately, I don't have an awful lot of free time at the moment, so I
> won't be able to look at this for at *least* as week.
I'll do it as soon as we decided about the final syntax and
keywords.
Jan
--
#==
Tom Lane wrote:
> Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > fdatasync() is available on Tru64 and according to the man-page behaves
> > as Tom expects. So it should be a win for us.
>
> Careful ... HPUX's man page also claims that fdatasync does something
> useful, but it doesn't. I'd recom
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Quoting a recent message by Jan Wieck <[EMAIL PROTECTED]>:
> > :Do a
> > :
> > :GET DIAGNOSTICS SELECT PROCESSED INTO ;
> > :
> > :directly after an INSERT, UPDATE or
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> Hmm, that's definitely what SQL99 uses for the syntax. I wonder where
> >> Jan got the SELECT INTO syntax --- did he borrow it from Oracle?
>
> > Sadly, we made it up.
>
> Ah so. Well, friendliness aside, I'd go with the spec's syn
Philip Warner wrote:
>
> P.S. Is Jan around? He's been very quiet recently...
He is,
just a little quiet. I can live with it either way. The main
problem, as said, is that we need to allow some keywords as
identifiers in PL/pgSQL like in the main parser. Actually we
added RES
Josh Berkus wrote:
> Tom, Jan, Michael,
>
> > While I have not looked closely, I seem to recall that plpgsql handles
> > INTO by stripping that clause out of the statement before it's passed to
> > the SQL engine. Evidently that's not happening in the EXECUTE case.
> >
> > Jan, do you agree this
Tom Lane wrote:
> I have looked a little bit at what it'd take to make SELECT INTO inside
> an EXECUTE work the same as it does in plain plpgsql --- that is, the
> INTO should reference plpgsql variables, not a destination table.
> It looks to me like this is possible but would require some nontri
Stephan Szabo wrote:
>
> On Mon, 5 Feb 2001, Christopher Kings-Lynne wrote:
>
> > Just a quick question, when a column of a table is defined to be a foreign
> > key, is it implicitly indexed, or does one still need to explicitly CREATE
> > INDEX?
>
> The foreign key columns are not currently impli
Hi,
headed for LinuxWorld now. Will be back on the lists on
Monday 5th. Take care.
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.
Jaruwan Laongmal wrote:
[Charset windows-874 unsupported, skipping...]
> Dear Sir,
>
> I will highly appreciated if anyone could inform me how to solve the following
>problems in Postgres.
> Specifically, sometimes there are the following messages informed by postgres.
>
> -
Olivier PRENANT wrote:
> Hi Bruce,
>
> Any idea when it's due for??
> I've been thining about writing a user function; But I'll get stuck with
> permission as a user function is running under the "postgres" or whatever
> user instead of the calling user.
>
> Also, what kind of binary interface are
Bruce Momjian wrote:
> > Hi Bruce,
> >
> > Any idea when it's due for??
>
> When? Probably not until 7.2, which is a pain.
We cannot use TOAST as is for BLOB/CLOB storage with a binary
IO interface over fastpath.
The reason is that you cannot force a column to be moved off
anyw
KuroiNeko wrote:
> > Huh? This would only be true if all operations inside plpgsql are
> > executed as superuser, which they are not. Seems to me the existing
> > defense against non-superuser using COPY is sufficient.
>
> Sorry if I missed the point, but if I got it right, Pl/Pgsql EXECUTE will
Bruce Momjian wrote:
>
> I would LOVE to see it in a minor 7.1.X release.
It's *feature* with alot necessary coding in core
functionality below heap access methods. Not a good candidate
for a bugfix release.
Jan
>
>
> > Bruce,
> >
> > Thanks for replying (I know you're
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > the new EXECUTE command in PL/pgSQL is a security hole.
> > PL/pgSQL is a trusted procedural language, meaning that
> > regular users can write code in it. With the new EXECUTE
>
Damn,
the new EXECUTE command in PL/pgSQL is a security hole.
PL/pgSQL is a trusted procedural language, meaning that
regular users can write code in it. With the new EXECUTE
command, someone could read and write arbitrary files under
the postgres UNIX-useri
Peter Eisentraut wrote:
> Jan Wieck writes:
>
> > Exactly the way you want it to do (open(2) and close(2) of a
> > UNIX domain socket) was what I had to do to get an old
> > Mach3-4.3BSD combo into a kernel-panic.
>
> The lock file is an ordinary
Bruce Momjian wrote:
> Here is another bug:
>
> test=> begin;
> BEGIN
> test=> INSERT INTO primarytest2 VALUES (5,5);
> INSERT 18757 1
> test=> UPDATE primarytest2 SET col2=1 WHERE col1 = 5 AND col2 = 5;
> ERROR: deferredTriggerGetPreviousEvent: event for tuple (0,10) not
> found
Schema?
J
Ross J. Reedstrom wrote:
> On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote:
> > > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock
> > > file after the server has run 6 days. This will be a problem.
> > >
> > > We could touch (open) the file once every time
Bruce Momjian wrote:
> Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> ---
>
> FreeBSD locale bug
> Reorder INSERT firing in rules
I don't recall why this is wanted. AFAIK there's no reason
N
Tim Perdue wrote:
> I thought the hackers team would be interested in knowing that SourceForge, as
> of Friday evening, is running on Postgres. Some 95,000 users and 12,500 Open
> Source projects are depending on your stuff, so I hope it's going to be stable
> for us. ;-)
Tim,
the PG core
Tom Lane wrote:
> "Steve Howe" <[EMAIL PROTECTED]> writes:
> > create rule blah_update as
> > on update to blah
> >do
> > notify TestEvent;
>
> > UPDATE blah SET n1=n1+1; -- Won't crash the connection
> > UPDATE blah SET n1=2 WHERE var_field='aaa' AND n1=1 AND n2=2 AND arr_str IS
> > NU
Sinuhi Arroyo wrote:
> I`mtrying to make a select which envolves two tables with in a
> functionif the query is written this way: (this is just an example,
> not my query)
>
> a := (select count(*) from xx);
>
> it works fine, but if I type the query like this
>
> select count(*) from xx;
>
>
Tom Lane wrote:
> Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> > Has anyone any input to offer on adding an arbitrary locking feature?
>
> > Where
> > GETLOCK "string" will lock on "string", the lock being only released at the
> > end of a transaction.
>
> > Any comments, suggestions or tips would b
Tom Lane wrote:
> backend/commands/command.c has a routine is_view() that tests for
> view-ness by scanning pg_rewrite (all of it) to see if the given
> relation has any ON SELECT rules.
>
> This is only used to disallow AlterTableAddConstraint and
> LockTableCommand on views. While I don't care
Tom Lane wrote:
> The way that heap_update() and heap_delete() are currently coded, they
> hold the buffer context lock on the buffer containing the old tuple
> while they invoke heap_tuple_toast_attrs(). This strikes me as at least
> inefficient and at worst a source of deadlock. Is it possible
Bruce Momjian wrote:
> > Bruce Momjian writes:
> >
> > > ERROR: triggered data change violation on relation "primarytest2"
> >
> > We're getting this report about once every 48 hours, which would make it a
> > FAQ. (hint, hint)
> >
>
>
> First time I heard of it. Does anyone know more details?
Mikheev, Vadim wrote:
> > > So, I've run simple test (below) to check this. Seems that 7.1
> > > is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> > > triggers is quite bad for performance.
> > > Also, we should add new TODO item: implement dirty reads
> > > and use them in RI tri
Don Baccus wrote:
>
> ...
> I expect TOAST to work even better). Users will still be able change to
> larger blocksizes (perhaps a wise thing to do if a large percentage of their
> data won't fit into a single PG block). Users using the default will
> be able to store rows of *awesome* length,
Mikheev, Vadim wrote:
> > I'm about 99.67% sure that the lock type choosen in the
> > FOR UPDATE case (line 511 of parse_relation.c) should be
> > RowExclusiveLock instead of RowShareLock. Actually I get
> > "Deadlock risk" debug messages when selecting FOR UPDATE
Hi,
I'm about 99.67% sure that the lock type choosen in the
FOR UPDATE case (line 511 of parse_relation.c) should be
RowExclusiveLock instead of RowShareLock. Actually I get
"Deadlock risk" debug messages when selecting FOR UPDATE and
then really UPDATE.
Adam Haberlach wrote:
>In any case, can we create pgsql-politics so we don't have to go over
> this issue every three months? Can we create pgsql-benchmarks while we
> are at it, to take care of the other thread that keeps popping up?
pgsql-yawn, where any of them can happen as often and
Jan Wieck wrote:
> Hi,
>
> I'd like make some changes on the 7.1 (to be) libpgtcl.
>
> 1. Make the large object access null-byte safe, when
> libpgtcl is compiled against a 8.0 or higher version of
> Tcl.
>
> This would
Hi,
I'd like make some changes on the 7.1 (to be) libpgtcl.
1. Make the large object access null-byte safe, when
libpgtcl is compiled against a 8.0 or higher version of
Tcl.
This would cause that a libpgtcl.so built on a system
with Tcl 8.0
Stephan Szabo wrote:
>
>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.
Isn't that (delete and r
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
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > Where would you store the value if not in pg_database?
>
> No other ideas at the moment. I was just wondering whether there was any
> way to delete it entirely, but seems like we want to have the value for
> template0 available. The
Tom Lane wrote:
>
> Do we still need the lastsysoid column in pg_database if we do things
> this way? Seems like what you really want is to suppress all the
> objects that are in template0, so you really only need one lastsysoid
> value, namely template0's. The other entries are useless AFAICS.
Tom Lane wrote:
> We've hacked up pg_dump so that it won't dump objects inherited from
> template1. Unfortunately I have realized there are a couple of serious
> problems:
>
> 1. What if the inherited object is a table or a sequence? Its state may
> no longer be the same as it was in template1 (
Tom Lane wrote:
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> > Required frequency of *successful* vacuum over *all* tables.
> > We would have to remember something in pg_class/pg_database
> > and somehow force vacuum over "too-long-unvacuumed-tables"
> > *automatically*.
>
> I don't think this
Bruce Momjian wrote:
> Also, seems like it is hidden enough in /contrib for it to stay. While
> I would not have added it myself, I do not feel strongly enough to
> remove Jan's commit. However, I am not going to mention it in the 7.0.3
> release notes.
>
> I want it removed from 7.1 /contrib.
Tom Lane wrote:
> Jeff Hoffmann <[EMAIL PROTECTED]> writes:
> > my question is whether i should change the function to use the new fmgr
> > type of definition or if it's only for internal functions.
>
> Up to you. If you need any of the new features (like clean handling
> of NULLs) then convert.
Mikheev, Vadim wrote:
> Try this for both FK tables:
>
> create table tmp2(idx2 int4, col2 int4, constraint
> tmpcon2 foreign key(col2) references tmp1(idx) INITIALLY DEFERRED);
>
> This will defer constraint checks till transaction commit...
> though constraint triggers should use SnapshotDirty i
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > After careful consideration, I have decided to accept a job with Great
> > Bridge.
>
> Whatever happened to this:
>
> Date: Tue, 09 May 2000 15:19:48 -0400
> From: Tom Lane <[EMAIL PROTECTED]>
> To: Ross J. Reedstrom <[EMAIL PROTECTED]>
> Cc: P
Matthew Hagerty wrote:
> Greetings,
>
> Well, it seems that the numeric issue I was having has nothing to do with
> the precision and scale being set the same, it has to do with the input
> data. The precision has to be at least 2 greater than the biggest number
> you need to enter, i.e.
>
> equi
Stephan Szabo wrote:
>
> On Sun, 1 Oct 2000, Peter Eisentraut wrote:
>
> > Stephan Szabo writes:
> >
> > > With that, I do have a general question though. Are referential actions
> > > supposed to be limited by the permissions of the user executing the query?
> > > So, if you for example have writ
The Hermit Hacker wrote:
>
> *rofl* now that wasn't rigged or nothing ... I could see us second to
> MySQL, or third to Oracle/Informix, depending on how it was evaluated, but
> fourth to all three?
Hey, look at the headline:
Linux Magazine's Editor's Choice Awards
by The Edi
901 - 970 of 970 matches
Mail list logo
