I just checked the md5 signature against the one that is online, and they
are exactly the same ... what is at the URL you present is *exactly* the
same as the one that is on ftp.postgresql.org ...
On Fri, 26 Jan 2001, Sasha Pachev wrote:
> On Friday 26 January 2001 19:04, The Hermit Hacker wr
On Sat, 27 Jan 2001, Bruce Momjian wrote:
>
> Oleg, do you want this in /contrib for 7.1?
yes, if it's possible.
btw, is there way to specify default ops for index ?
We have two methods of index creation for intarrays and
would like to define which should be used by default
>
> > Mark,
> >
> >
Lincoln Yeoh <[EMAIL PROTECTED]> writes:
> I'm wondering if TOAST is going to be efficient enough for me to plonk
> multimegabyte email attachments into the database.
Should work. The main limitation on TOAST is that it wants to treat
each datum as a unit, ie you must fetch or store the whole v
At 10:02 AM 1/25/01 -0500, you wrote:
>> When Postgresql 6.5 came out it, it was VERY MUCH better ( many many
>thanks
>> to the developers and all involved). And I'm waiting for a solid 7.1 to
>fix
>> that <8KB issue.
>
>Technically..
>
><= BLCKSZ (can be up to 32k)
>
>I've been using PostgreSQL
Tim Perdue <[EMAIL PROTECTED]> writes:
> Do we need to do a bunch of testing on Beta3 before deployment or is it
> so much more stable that it absolutely will have no problems?
Well, it's more stable than any pre-beta snapshot is likely to be ...
> We haven't had any problems with the ~Nov 17 sn
I now remember that we decided that it was too late in 7.1 to fix this:
reorder INSERT firing in rules
Added to TODO:
Evaluate INSERT rules at end of query, rather than beginning
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
On Fri, Jan 26, 2001 at 05:06:24PM -0500, Jan Wieck wrote:
> So the crazy-temp-vacuum-cleaner on linux doesn't touch the
> sockets?
The tmpwatch program that comes with many Linux distributions will only
unlink regular files and empty directories by default.
--
Bruce Guenter <[EMAIL PR
Here are the open items for 7.1. Much shorter:
Reorder INSERT firing in rules
JDBC LargeObject short read return value missing
LAZY VACUUM
JDBC setMaxRows() is global variable affecting other objects
Fix for pg_dump of bad system tables
ODBC not disconnecting properly?
Magnus Hagander ODBC issue
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, added to TODO:
> > * Allow NOTIFY in rules
> >>
> >> Uh, what does that have to do with the problem? It's certainly not
> >> an accurate rendering of either the current or proposed status ...
>
> > Oops, can you give me a line. What was the i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, added to TODO:
> * Allow NOTIFY in rules
>>
>> Uh, what does that have to do with the problem? It's certainly not
>> an accurate rendering of either the current or proposed status ...
> Oops, can you give me a line. What was the issue?
"Allow NO
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Because I don't know details about trigger stuff, I may be
> misunderstanding. As far as I see, KEY_CHANGED stuff
> requires to log every event about logged tuples.
I just realized that myself. The code was still doing it the hard
way (eg, logging
I wrote:
> Are there cases where we must log an event anyway, and if so what are
> they? It didn't look to me like the deferred event executor would do
> anything with a logged event that has no triggers ...
Oops, I missed the uses of deferredTriggerGetPreviousEvent(). Fixed
now.
Oleg, do you want this in /contrib for 7.1?
> Mark,
>
> we prepared new version of contrib-intarray -
> index support for 1-D integer arrays using GiST.
>
> Changes:
>
>
> - Improved regression test
> - Current implementation provides index support for one-dimensional
>array of int4's
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > OK, added to TODO:
> > * Allow NOTIFY in rules
>
> Uh, what does that have to do with the problem? It's certainly not
> an accurate rendering of either the current or proposed status ...
Oops, can you give me a line. What was the issue?
--
> I said:
> > Yes, there are lots of systems that will clean /tmp --- and since the
> > lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
> > is going to decide to remove it. I think that I had intended to insert
> > a periodic touch of the lockfile and forgot to.
>
> Done
> 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 the ServerLoop() runs
>
> It would require only very minor changes in the main backend code to
> eliminate entirely the hard-wired upper bound MAXBACKENDS. This would
> be nice since there'd never be any need to recompile in order to
> increase the soft limit MaxBackends (-N). However I see that the
> SysV-semaphore em
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > ISTM commands/trigger.c is broken.
> > The behabior seems to be changed by recent changes made by Tom.
>
> Hm. I changed the code to not log an AFTER event unless there is
>
> Hi all,
>
> Re-posting this to -hackers. Will PQprint() remain/disappear/be replaced
> in the future?
No idea. We are not sure who uses it.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a
> Do we need to do a bunch of testing on Beta3 before deployment or is it
> so much more stable that it absolutely will have no problems?
>
> We haven't had any problems with the ~Nov 17 snapshot, so we figure why mess
> with a good thing.
Well, seeing as we never tested the Nov 17 snapshot, and
Need more information ... specifically what OS are you running? I *just*
built PgSQL 7.0.3 on my freshly installed FreeBSD 4.2-RELEASE box, and it
compiled cleanly ...
On Fri, 26 Jan 2001, Sasha Pachev wrote:
> Hello, guys:
>
> I am working on adding Postgre support to our multi-threaded benc
On Thu, Jan 25, 2001 at 10:13:29PM -0500, Tom Lane wrote:
> Frank Joerdens <[EMAIL PROTECTED]> writes:
> > I just did that and ran make check 4 times. 3 times went completely
> > smoothly, once I had random fail. This is the same behaviour that I saw
> > when running make installcheck (76 successf
At 14:56 24/01/01 -0500, Rod Taylor wrote:
>pg_dump -c database
>
>The \connect is after the DROP TABLE statements where I believe it
>should come first. (Gotta connect as the right user before dropping
>everything).
>
You're right - I'll let you know when it's fixed.
---
Do we need to do a bunch of testing on Beta3 before deployment or is it
so much more stable that it absolutely will have no problems?
We haven't had any problems with the ~Nov 17 snapshot, so we figure why mess
with a good thing.
Tim
On Thu, Jan 25, 2001 at 08:23:30PM -0500, Jeff Duffy wrote:
Guys,
Thomas said he won't look into GPL'ed code for ideas.
Well, I re-read GPL and found that it's up to author whether is to allow or not
to use code for using in programs with another open-source license. So this isn't
a problem - you may use my program and include code to your without limit
Hello, guys:
I am working on adding Postgre support to our multi-threaded benchmarking
tool, which currenlty only support MySQL, and was wondering which version of
pg you would recommend that I use for benchmarks, as well as any special
performance considerations for pg-sql I need to be aware
[EMAIL PROTECTED] wrote:
> Bruce Momjian writes:
>
> > > 1. Add options to use unixODBC in the configure.in file, the mainly consists of
>finding the root of the unixODBC install prefix, and adding
> > > -I /unixODBC/path/include and -L /unixODBC/path/lib to the driver build
>
> --with-includes,
[EMAIL PROTECTED] wrote:
> Nick Gorham writes:
>
> > Well because the driver does not know where to get the config info
> > from,
>
> Then the driver should be fixed to do that, with or without unixODBC.
Well yes, but again, using the Windows situation as a model (not that
I would normally sugge
pg_dump -c database
The \connect is after the DROP TABLE statements where I believe it
should come first. (Gotta connect as the right user before dropping
everything).
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what really happened.
BEGIN:V
Okay, okay, complaint withdrawn. Peter, would you commit that
permission check?
regards, tom lane
I said:
> Yes, there are lots of systems that will clean /tmp --- and since the
> lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
> is going to decide to remove it. I think that I had intended to insert
> a periodic touch of the lockfile and forgot to.
Done now.
[ Charset ISO-8859-1 unsupported, converting... ]
> > > What about DoS attacks? What would be the effect of
> > > someone's setting off an infinite loop of CHECKPOINTs?
> >
> > Don't we have bigger DoS attacks? Certainly SELECT cash_out(1) is a
> > much bigger one.
>
> I've missed point - cas
> > What about DoS attacks? What would be the effect of
> > someone's setting off an infinite loop of CHECKPOINTs?
>
> Don't we have bigger DoS attacks? Certainly SELECT cash_out(1) is a
> much bigger one.
I've missed point - cash_out(1) is bug that should be fixed.
Any reason to add yet anot
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If a second postmaster is started on a data directory and the second one
> uses the -S option it will not print a message but simply exit and not
> start a background process. The exit status is 0.
On closer inspection, it's clear that the postmaste
> Tom Lane wrote:
> >Peter Eisentraut <[EMAIL PROTECTED]> writes:
> >> Mikheev, Vadim writes:
> >>> Yes, there should be permission checking - I'll add it later (in 7.1)
> >>> if no one else.
> >
> >> Should be simple enough. Is this okay:
> >
> >Actually, I think a more interesti
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> ISTM commands/trigger.c is broken.
> The behabior seems to be changed by recent changes made by Tom.
Hm. I changed the code to not log an AFTER event unless there is
actually a trigger of the relevant type, thus suppressing what I
considered a very s
> -Original Message-
> From: Bruce Momjian
>
> > Bruce Momjian wrote:
> > > Here is another bug:
> > >
ISTM commands/trigger.c is broken.
The behabior seems to be changed by recent changes made by Tom.
* Check if we're interested in this row at all
* --
> 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
> > fo
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 file.
So the crazy-temp-
> > Conditional variables seem to be more portable
>
> Really? Which standard are they specified in?
POSIX - they are in pthread library (eg man pthread_cond_init).
For sem_init I see in man (on Solaris and AIX):
ENOSYS The sem_init() function is not supported
what is exactly I've got on AIX
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
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> If we have to do it, let's make it an #ifdef __linux__ option.
> What does Linux have to do with it? FreeBSD does the same thing, only
> every three days. I dont' know whether it's not enabled on a fresh
> install, but it's
I was woundering if any of you have seen this problem.
I have been running a system using a postgres 6.5 database. After a while
I realized the system wasn't very active so I looked into it. I tryed to view
all the tables in the database using the \d command, but it return:
- Couldn't find any t
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> What I'd like to look at sometime soon is using POSIX semaphores
>> instead of SysV semaphores. But we need stateful semaphores,
>> not signals.
> Conditional variables seem to be more portable
Really? Which standard are they specified in?
I hav
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>>
>> A well known issue, and I've asked multiple times how exactly
>> we want to define the behaviour for deferred constraints. Do
>> foreign keys reference just to a key v
> Bruce Momjian writes:
>
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> You're certainly not going to want to fix this now after having stared at
> it for a year? It's not trivial.
Moved to TODO.
>
> > Usernames limited in length
>
> Yeah, they are. ;-)
>
> I
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
> Bruce Momjian wrote:
> > > Bruce Momjian writes:
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> SELECT cash_out(1) crashes all backends
>>
> OK, removed from 'open' list and added to TODO. Actually, I can't get
> the crash to happen except with cash_out. Is there another *out
> function you can get to fail.
Any pass-by-reference type; also mos
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, added to TODO:
> * Allow NOTIFY in rules
Uh, what does that have to do with the problem? It's certainly not
an accurate rendering of either the current or proposed status ...
regards, tom lane
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If a second postmaster is started on a data directory and the second one
> uses the -S option it will not print a message but simply exit and not
> start a background process. The exit status is 0.
Since the whole point of -S is to throw away stdout
Bruce Momjian writes:
> If we have to do it, let's make it an #ifdef __linux__ option.
What does Linux have to do with it? FreeBSD does the same thing, only
every three days. I dont' know whether it's not enabled on a fresh
install, but it's there, you only need to flip the switch. I doubt /t
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> > SELECT cash_out(1) crashes all backends
>
OK, removed from 'open' list and added to TODO. Actually, I can't get
the crash to happen except with cash_out. Is there another *
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 file.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.
* Peter Eisentraut <[EMAIL PROTECTED]> [010126 12:11] 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 the ServerLoop() runs
> around. It's not pe
Ross J. Reedstrom writes:
> Hmm, multiple processors, and lots of IPC: I've got a bad feeling
> about this.
Although I'm not absolutely certain, the systems on which I had this
problem were not multi-processor, they were just plain-old workstations in
a university computer lab. At the time (7.0
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
> > Would be something for a STATEMENT trigger. We don't have 'em
> > yet and I'm not sure what kind of information they will
> > receive if we finally implement them. But the number of rows
> > affected by the statement is a good candidate.
>
> That's no help for a 7.1 sol
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 the ServerLoop() runs
> > around.
[ Charset ISO-8859-1 unsupported, converting... ]
> Quoting Bruce Momjian <[EMAIL PROTECTED]>:
>
> > Here are my open 7.1 items. Thanks for shrinking the list so far.
> >
> > ---
> >
> > FreeBSD locale bug
> > Reorder INSE
> 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 the ServerLoop() runs
> around. It's not perfect but it should work in practice.
If we have to do it, l
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 the ServerLoop() runs
around. It's not perfect but it should work in practice.
--
Peter Eisentraut [EMAIL
If a second postmaster is started on a data directory and the second one
uses the -S option it will not print a message but simply exit and not
start a background process. The exit status is 0.
This seems to have gotten lost in the changes postmaster.c rev. 1.195,
global lock file changes by tgl
Jan Wieck <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Reorder INSERT firing in rules
> I don't recall why this is wanted. AFAIK there's no reason
> NOT to do so, except for the actual state of beeing far too
> close to a release candidate.
I think I've been the main pe
Jan Wieck <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The problem here is that the query rewriter tries to hang the query's
>> qualification (WHERE clause) onto the rule's action query, so that
>> the action query won't be done unless the query finds at least one
>> row to update.
>> NOTIFY c
> > Did you ever consider remove per-backend semaphores at all?
> > We use them to sleep waiting for lock (ie when someone awake
> > us by changing our semaphore) - why don't use sigpause and
> > some signal?
>
> That'll fail if the signal arrives before the sigpause(), no?
Ops, you're right.
>
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> A well known issue, and I've asked multiple times how exactly
> we want to define the behaviour for deferred constraints. Do
> foreign keys reference just to a key value and are happy with
> it's existan
> > FOREIGN KEY INSERT & UPDATE/DELETE in transaction "change violation"
>
> A well known issue, and I've asked multiple times how exactly
> we want to define the behaviour for deferred constraints. Do
> foreign keys reference just to a key value and are happy with
> it's exista
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Did you ever consider remove per-backend semaphores at all?
> We use them to sleep waiting for lock (ie when someone awake
> us by changing our semaphore) - why don't use sigpause and
> some signal?
That'll fail if the signal arrives before the sigpa
> I'm not thinking about getting this done in time for 7.1, but I think
> it'd be a nice cleanup for 7.2.
>
> Bruce, a TODO item please:
> * Remove compile-time upper limit on number of backends
> (MAXBACKENDS)
Did you ever consider remove per-backend semaphores at all?
We use them to sleep w
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
> Actually, I think a more interesting question is "should CHECKPOINT
> have permission restrictions? If so, what should they be?"
>
> A quite relevant precedent is that Unix systems (at least the ones
> I've used) do not restrict who can call sync().
Checkpoints 1. affect entire system, 2. inc
> > Yes, there should be permission checking - I'll add it
> > later (in 7.1) if no one else.
>
> Should be simple enough. Is this okay:
I think yes - please apply.
Vadim
On Fri, Jan 26, 2001 at 11:15:45AM -0500, Tom Lane wrote:
> Frank Joerdens <[EMAIL PROTECTED]> writes:
> > Now I get:
>
> > select_distinct_on ... FAILED
> > select_implicit ... FAILED
> > random ... failed (ignored)
> > portals ... FAILED
> >
On Fri, Jan 26, 2001 at 05:03:13PM +0100, Frank Joerdens wrote:
>
> There is no load at all on this server at the moment. The sysadmin and
> myself are currently the only people accessing a brand new UltraSPARC with 3
> CPUs and 3/4 GB of RAM to install stuff.
Hmm, multiple processors, and lots
It would require only very minor changes in the main backend code to
eliminate entirely the hard-wired upper bound MAXBACKENDS. This would
be nice since there'd never be any need to recompile in order to
increase the soft limit MaxBackends (-N). However I see that the
SysV-semaphore emulation co
Frank Joerdens <[EMAIL PROTECTED]> writes:
> Now I get:
> select_distinct_on ... FAILED
> select_implicit ... FAILED
> random ... failed (ignored)
> portals ... FAILED
> test misc ... FAILED
Reporting a regression failure this
On Fri, Jan 26, 2001 at 03:29:59PM +, Patrick Welche wrote:
> On Thu, Jan 25, 2001 at 10:13:29PM -0500, Tom Lane wrote:
> > Frank Joerdens <[EMAIL PROTECTED]> writes:
> > > I just did that and ran make check 4 times. 3 times went completely
> > > smoothly, once I had random fail. This is the s
Hiroshi Inoue writes:
> What does this item mean ?
> Is it the following ?
>
> begin;
> insert into pk (id) values (1);
> update(delete from) pk where id=1;
> ERROR: triggered data change violation on relation pk"
>
> If so, isn't it a simple bug ?
Depends on the definit
Peter Eisentraut writes:
> Frank Joerdens writes:
>
> > > I have experienced before that Unix sockets will cause random
> > > connection abortions on Solaris [ . . . ]
> >
> > Isn't that _really_ bad? Random connection abortions when going
> > over Unix sockets?? My app does _all_ the conn
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
> Here are my open 7.1 items. Thanks for shrinking the list so far.
>
> ---
>
> FreeBSD locale bug
> Reorder INSERT firing in rules
> Philip Warner UPDATE crash
> JDBC LargeObject
80 matches
Mail list logo
