Tom Lane wrote:
I just noticed that rewriteHandler.c contains a subroutine orderRules()
that reorders the rules for a relation into the order
non-instead rules
qualified instead rules
unqualified instead rules
This conflicts with the feature we'd added to 7.3 to
Bruce Momjian wrote:
Alessio Bragadini wrote:
On Sat, 2002-10-12 at 11:37, Gavin Sherry wrote:
I cannot think of any reason why changing column order should be
implemented in Postgres. Seems like a waste of time/more code bloat for
something which is strictly asthetic.
Rod Taylor wrote:
On Fri, 2002-10-11 at 09:20, Antti Haapala wrote:
Check out:
http://www.mysql.com/doc/en/MySQL-PostgreSQL_features.html
MySQL AB compares MySQL with PostgreSQL.
I wouldn't look too far into these at all. I've tried to get
' as identifier quote (ANSI SQL) '
Curtis Faith wrote:
The current transaction/user state seems to be stored in process
global space. This could be changed to be a sointer to a struct
stored in a back-end specific shared memory area which would be
accessed by the executor process at execution start. The backend
would destroy
Tom Lane wrote:
What is the reason for maintaining separate rscale and dscale values in
numeric variables?
I am finding that this arrangement leads to some odd results, for
example this:
regression=# select (exp(ln(2.0)) - 2.0);
?column?
-
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
What is the reason for maintaining separate rscale and dscale values in
numeric variables?
You need to carry around a decent number of digits when you divide
already. Exposing them in a manner that numericcol(15,2
Curt Sampson wrote:
On Wed, 25 Sep 2002, Jan Wieck wrote:
With the number of screws our product has, there are so many
possible combinations that don't work, why worry about one more
or less?
That's just silly, so I won't even bother replying.
Curt,
it might sound silly on first
Bruce Momjian wrote:
Because the new 7.3 SSL code doesn't work (per Peter), and the author is
not responding, I am about to yank out that code. Peter suggests
ripping out all the new code rather than try to pick around and remove
just the broken parts.
Agreed. I allways wondered what SSL
Curt Sampson wrote:
On Tue, 24 Sep 2002, Jan Wieck wrote:
And AFAICS it is scary only because screwing that up will simply corrupt
your database. Thus, a simple random number (okay, and a timestamp of
initdb) in two files, one in $PGDATA and one in $PGXLOG would be a
totally
scott.marlowe wrote:
Having a FILE called pg_xlog isn't the fix here, it's the result of the
fix, which is to take all the steps of moving the pg_xlog directory and
put them into one script file the user doesn't need to understand to do it
right. I.e. idiot proof the system as much as
scott.marlowe wrote:
[...]
But, I have a few more questions about the signature file solution. Is
the signature file going to be updated by date or something everytime the
database is started up and shut down? If not, then it's quite possible
that someone could copy the pg_xlog dir
Bruce Momjian wrote:
scott.marlowe wrote:
On Wed, 25 Sep 2002, Jan Wieck wrote:
So, should we take out seatbelts from cars, safeties from guns, and have
everyone run about with sharp sticks too? :-) I know that the second we
make something more idiot proof, someone will make a better
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
You don't :vote: on stuff like this ...
Why not, exactly?
I wasn't aware that any of core had a non-vetoable right to apply
any patch we liked regardless of the number and strength of the
objections. AFAIK, we resolve
Tom Lane wrote:
I have noticed a change in behavior following the recent changes for
casting of numeric constants. In prior releases, we got
regression=# select log(10.1);
log
--
1.00432137378264
(1 row)
CVS tip gives
regression=# select log(10.1);
we can discuss that a while.
Jan
---
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
One problem is, that division already has an inherently inexact
result. Do you intend to rip that out too while
Mike Mascari wrote:
instead of fopen(). I'm not sure about ME, but I suspect it
behaves similarly to 95/98.
I just checked with Katie and the good news (tm) is that the Win32 port
we did here at PeerDirect doesn't support 95/98 and ME anyway. It does
support NT4, 2000 and XP. So don't bother.
Michael Paesold wrote:
Michael Meskes wrote:
Hi,
is a pl/pgSQL function completely parsed once? Or is only the next
statement parsed as with many interpreters? If it's the latter it would
mean one has to run each branch just to see if the syntax is correct. Is
that true?
Bruce Momjian wrote:
Dave Page wrote:
Which in this case is what puzzles me. We are only talking about a
simple GUC variable after all - I don't know for sure, but I'm guessing
it's not a huge effort to add one?
Can we get agreement on that? A GUC for pg_xlog location? Much cleaner
Nigel J. Andrews wrote:
However, how is that going to work if tablespaces are introduced in 7.4. Surely
the same mechanism for tablespaces would be used for pg_xlog. As the tablespace
mechanism hasn't been determined yet, as far as I know, wouldn't it be best to
see what happens there before
Bruce Momjian wrote:
Jan Wieck wrote:
We should surely keep this on a much more technical level and avoid any
personal offendings. To do so, please explain to me why you think that
triggers and constraints are out of focus here? What is the difference
between a trigger, a rule
Steve Howe wrote:
Hello all,
PostgreSQL *still* has a bug where PQcmdStatus() won't return the
number of rows updated. But that is essential for applications, since
without it of course we don't know if the updates/delete/insert
commands succeded. Even worst, on interfaces like
Steve Howe wrote:
Hello Bruce,
Friday, September 6, 2002, 9:52:18 PM, you wrote:
BM I am not any happier about it than you are. Your report is good because
BM it is the first case where returning the wrong value actually breaks
BM software. You may be able to justify adding a fix
Steve Howe wrote:
Hello Bruce,
Friday, September 6, 2002, 10:58:13 PM, you wrote:
BM Well, there was a big discussion, and I did bring up the issue in early
BM August to see if I could get a resolution to it and was told no
BM conclusion could be made.
BM I suggest you read the TODO
Christopher Kings-Lynne wrote:
Anyone else think we should add some more pins to the developer map? At the
moment, it looks like we have very few developers!
We might as well refresh that thing a bit. I haven't been to Hamburg
since April 2001! Vince already has my ... er ... rather old
Vince Vielhaber wrote:
Still don't know where Peter's going to be so his pin may end up
in Dresden. I've had zero success in getting that tcl tool to work
which is the current holdup but I do have all the updates I know of
that are needed.
You mean that Tcl/Tk application that manages the
Steve Howe wrote:
Hello Jan,
Monday, September 9, 2002, 11:15:47 AM, you wrote:
JW So please, proper behavior is not allways what your favorite tool
JW expects. And just because you cannot fix your tool doesn't make that
JW behavior any more proper.
Do you have any word more
Justin Clift wrote:
Hi Mark,
Mark Pritchard wrote:
[...]
Finally, question the due dilligence process that selects an ISP partner who
would leave a database open to the world, even if they run unbreakable
Oracle :)
This is the one point of yours I don't feel you've quite got
Dann Corbit wrote:
[...]
What I am saying is that there is nothing that could possibly be more
important than fixing this, except some other known problem that could
also cause billions of dollars worth of damage. Are there any such
problems besides the buffer overrun problems?
And what
Matthew T. O'Connor wrote:
Hello, I'm playing with creating an auto vacuum daemon, but it is my first
time inside the pg source code and I'm a bit lost.
I have gotten as far as having a vacuum daemon created on postmaster startup.
It's just a fork from the postmaster, cribbed mostly from
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Allow PL/PgSQL functions to return sets
Is anyone working on this? We will get beaten up if we don't have this
for 7.3 and it is available in other languages.
That's true. I think I have to do this one
Marc G. Fournier wrote:
Something to maybe add to the TODO list, if someone has the
time/inclination to work on it ...
The problem with the current auth system, as I see it, is that you can't
easily have seperate user lists and passwords per database ... its shared
across the system ...
Joe Conway wrote:
The problem is that you would still need to keep a copy of your view
around to recreate it if you wanted to drop and recreate a table it
depends on. I really like the idea about keeping the original view
source handy in the system catalogs.
This has been the case all the
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
Hi,
Would it be possible to add a new attribute to pg_views that stores the
original view definition, as entered via SQL?
This would make the lives of those of us who make admin interfaces a lot
easier...
We actually reverse
Tom Lane wrote:
Auto reconstruction of a view based on its original textual definition
is still potentially interesting, but I submit that it won't necessarily
always give the right answer.
Sure, it's another bullet to shoot yourself into someone elses foot.
Jan
--
In reply to Hannu Krosing
Iavor Raytchev wrote:
How hard will the migration from MySQLzilla to PostgreSQLzilla be ?
Is this a rhetoric question?
I have no idea.
A posting I saw (by one of the Bugzilla guys, I think) required something to
be done in PostgreSQL before they can migrate
Christopher Kings-Lynne wrote:
The Bugzilla project plans to support PostgreSQL in one of their future
releases, but this requires functionality in PostgreSQL, that is not
even scheduled for 7.3. So the availability of a supported PostgreSQL
port of Bugzilla is unpredictable at this
Oliver Elphick wrote:
The current upgrade process for PostgreSQL is founded on the idea that
people build from source. With binary distributions, half the users
wouldn't know what to do with source; they expect (and are entitled to
expect) that an upgrade will progress without the need for
Lamar Owen wrote:
[replying to myself]
On Tuesday 09 July 2002 07:34 pm, Lamar Owen wrote:
if you do this. Already RPM can rollback the transaction being done on the
RPM database (it's a db3 database system), but rolling back the filesystem
is a little different.
As a note of
Iavor Raytchev wrote:
Hello everybody,
I want to apologise for inflating all lists (as Chris noticed) with
insignificant discussions. I would like to invite all pgaccess involved
people to restrict their postings to [EMAIL PROTECTED], unless there
is a good reason for doing it
Lamar Owen wrote:
On Wednesday 10 July 2002 03:24 am, Jan Wieck wrote:
The problem why this conflicts with these package managers is,
because they work package per package, instead of looking at the
big picture. Who said you can replace package A before running
the pre-upgrade script
Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 10 Jul 2002, Tom Lane wrote:
DROP TABLE foo RESTRICT;
Should this succeed? Or should it be necessary to say DROP CASCADE to
get rid of the foreign-key reference to foo?
I think the above should fail. If someone was
Rod Taylor wrote:
However, is there an easy way of obtaining the list of columns (and their
types/indexes/etc) in a table, so that we can recreate table a with just
that column missing? One which won't break when the underlying pg_* schema
changes?
I see. No, not that I know of.
Zeugswetter Andreas SB SD wrote:
No, what I envisioned was a standalone dumper that can produce dump output
without having a backend at all. If this dumper knows about the various
binary formats, and knows how to get my data into a form I can then restore
reliably, I will be satisfied.
Iavor Raytchev wrote:
Hello,
As of today, a Bugzilla has been made available at -
bugzilla.pgaccess.org
This is a pretty straight forward installation of Bugzilla 2.14.2
It is currently empty. There are even no components so the first bug
submissions can be either request for
Christopher Kings-Lynne wrote:
It would all work out of the box and would do wonderful things for the
Postgres community.
I like this idea, but let me just bring one little issue to note: are you
going to handle upgrades, and if so, how? How are you going to
do a major
version
Lamar Owen wrote:
[...]
And if having a working, usable, Win32 native port gets the subject of good
upgrading higher up the priority list, BY ALL MEANS LET'S SUPPORT WIN32
NATIVELY! :-) (and I despise Win32)
Hehehe :-)
[...]
Martin O has come up with a 'pg_fsck' utility that, IMHO,
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
So, when we review patches, we shouldn't be turning up our noses at
imperfect solutions if the solution meets needs of our users.
I think our standards have gone up over the years, and properly so.
The fact that we put in hacks
Jonah H. Harris wrote:
Who originally did the TPC-C benchmarks? Is the source available for them?
Great Bridge once ran some sort of (what they thought it would be) TPC-C
benchmark. They used the proprietary Benchmark Factory software for
doing so.
While working there I had some time to
Hackers,
as some of you figured already, Katie Ward and I are working fulltime on
PostgreSQL and are actually doing a native Win32 port. This port is not
based on CygWIN, Apache or any other compatibility library but uses 100%
native Windows functionality only.
We already have it far enough to
Rod Taylor wrote:
For some reason a view with a select distinct, an order and an exception
by will cause pg_dump to output a double order by -- one for each select
which of course is bad SQL.
I think views should not have ORDER BY clauses at all in the first
place.
Jan
--
Marc G. Fournier wrote:
On Thu, 20 Jun 2002, Bruce Momjian wrote:
This line bothers me. With multiple people working on Win32, I would
like us to decide how we would _like_ such a port to be implemented. I
think this will assist those working on the project to _know_ that their
work
Dann Corbit wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 17, 2002 6:20 PM
To: Dann Corbit
Cc: Jan Wieck; Peter Eisentraut; PostgreSQL-development
Subject: Re: [HACKERS] Roadmap for a Win32 port
Dann Corbit wrote
Lamar Owen wrote:
On Monday 10 June 2002 04:11 pm, Tom Lane wrote:
I think our develop mode/beta mode pattern has done a great deal to
contribute to the stability of our releases. If we go over to the same
approach that everyone else uses, you can bet your last dollar that our
releases
Jason Tishler wrote:
On Sun, Jun 02, 2002 at 09:33:57PM -0400, mlw wrote:
Bruce Momjian wrote:
mlw wrote:
Like I told Marc, I don't care. You spec out what you want and I'll write
it for Windows.
That being said, a SysV IPC interface for native Windows would be kind of
with Jan Wieck (next office). I know
there is
a reluctance to modify the code base to support native win32, and I
realize
that no decision has yet been made. However, ...
A few of the identifier names used in postgres collide with WIN32 or MFC
names.
To keep my working copy
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
How hard would it be to _not_ include nulls in indexes
as they are not used anyway.
Seems to me that would be a step backwards.
It would cause multi-key indexes beeing unusable for partial
key lookup. Imagine you have a key
Shra wrote:
hi,
can v define our own datatype n use it in PostgreSQL tables?
Shra
u can
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote:
While I agree that it might be handy to save this bit for future use,
I do not see any value in increasing the max key length from 8k,
I'm not sure if it applies here,
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Also, in btree haven't we had some problems with index page
splits when using entries large enought so that not at least
3 of them fit on a page?
Right, that's why I said that the limit would only go up to ~10K anyway
Tom Lane wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Although this config file stuff is small potatoes compared to the
Win32 stuff as recently discussed. And for that, please understand
that most of the developers here consider Win32 an inferior server
platform. In fact, Win32 _is_ an
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
I have a little patch that actually allows SPI_prepare() to
use UNKNOWN_OID in the passed in parameter type array and
put's the choosen datatypes Oid back into there.
The parser treats those parameters like
Hiroshi Inoue wrote:
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Of cource it is nice to have a complete solution
immediately but it doesn't seem easy. My patch is
only a makeshift solution but fixes the most
siginificant case(typical updatable views).
I would
Tom Lane wrote:
Hiroshi Inoue [EMAIL PROTECTED] writes:
Of cource it is nice to have a complete solution
immediately but it doesn't seem easy. My patch is
only a makeshift solution but fixes the most
siginificant case(typical updatable views).
I would like to devise a complete solution
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
There are DB interfaces that allow a generic application to
get a description of the result set (column names, types)
even before telling the data types of all parameters.
Our ODBC driver for example has it's
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Hmm. So your vision of PREPARE would allow the backend to reply
with a list of parameter types. How would you envision that working
exactly?
I guess there's some sort of statement identifier you use to
refer to something
Scott Marlowe wrote:
There are some issues that the whole idea of a win32 port should bring up.
One of them is whether or not postgresql should be rewritten as a
multi-threaded app.
Please, don't add this one to it.
I'm all for the native Windows port, yes, but I've discussed
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I think, and I know people are probably sick of me spouting
opinions, that if you want a Windows presence for PostgreSQL, then
we should write a real Win32 version.
The crucial wrong word is the word we.
If _you_ want a Windows
Paul Ramsey wrote:
mlw wrote:
No matter what steps you take, cygwin will not be seen by Windows users as
anything but a sloppy/messy/horrible hack. It is a fact of life. You are
welcome to disagree, but I assure you it is true.
Just to clarify here: is it confirmed that having the
Joel Burton wrote:
Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al). We'd
need the dll, sh, rm, and few other things. I'm not sure if it would need to
be in the standard cygwin file structure; I know that you can reconfigure
this when you use cygwin (I used to). In any
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
nconway= prepare q2 as select $1;
ERROR: Parameter '$1' is out of range
(You'll see the same parse error with simply select $1;)
You need to tell the parser the number of parameters to expect and their
datatypes. This is what the
Tom Lane wrote:
I said:
But the backends would only have the socket open, they'd not be actively
listening to it. So how could you tell whether anyone had the socket
open or not?
Oh, I take that back, I see how you could do it: the postmaster opens
the socket *for writing*, but never
mlw wrote:
Marc G. Fournier wrote:
BTW, I think PostgreSQL does _not_ need any mission statement.
Nope, it doesn't ... never did before, don't know why it does suddenly ...
do any other open source projects have one? Its kinda fun to see what ppl
banter around, but I can't see it
[EMAIL PROTECTED] wrote:
mlw [EMAIL PROTECTED] writes:
Just out of curiosity, does PostgreSQL have a mission statement?
Nope. Given the wide variety of views among the developer community,
I think we'd have a tough time agreeing on a mission statement, unless
it was so generic as to
Marc G. Fournier wrote:
What happens inside of a nested transaction, assuming we do have those
evenually ... ?
Folks,
I don't really get it. We had a voting and I think I saw a
clear enough result with #1, transactional behaviour, as the
winner.Maybe I missed
Curt Sampson wrote:
On Fri, 26 Apr 2002, Marc G. Fournier wrote:
NOTE that I *do* think that #1 is what *should* happen, but there should
be some way of turning off that behaviour so that we don't screw up ppl
expecting Oracles behaviour ...
I don't think this follows. If it's only for
Bruce Momjian wrote:
Marc G. Fournier wrote:
On Thu, 25 Apr 2002, Bruce Momjian wrote:
Marc is suggesting we may want to match Oracle somehow.
I just want to have our SET work on a sane manner.
Myself, I wonder why Oracle went the route they went ... does anyone have
access
Bruce Momjian wrote:
So you do see a difference between SET and DROP TABLE because the second
is a utility command. OK, I'll buy that, but my point was different.
My point was that we don't match Oracle for DROP TABLE, so why is
matching for SET so important?
Good point, I never
Sander Steffann wrote:
What about a SET variable that controls the behaviour of
SET variables :-)
Or two commands for the same thing:
- a SET command that behaves as it does now
- a TSET command that is transaction-aware
Ouch... :-)
Sander
Naw, that's far too easy. I got
Hiroshi Inoue wrote:
Tom Lane wrote:
Right offhand, I am not seeing anything here for which there's a
compelling case not to roll it back on error.
In fact, I have yet to hear *any* plausible example of a variable
that we would really seriously want not to roll back on error.
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
I voted not only ? but also 2 and 3.
And haven't I asked twice or so if it's a vote ?
Yes, it is a vote, and now that we see how
Hiroshi Inoue wrote:
Sure should it! You gave an example for the need to roll
back, because
otherwise you would end up with an invalid
search path foo.
What's wrong with it ? The insert command after *rollback*
would fail. It seems the right thing to me.
1
SET should follow transaction semantics and rollback.
Jan
Bruce Momjian wrote:
OK, would people please vote on how to handle SET in an aborted
transaction? This vote will allow us to resolve the issue and move
forward if needed.
In the case of:
SET x=1;
No problem with that. Good idea IMHO.
Jan
Tom Lane wrote:
Currently, the name of the ON SELECT rule for a view is defined to be
'_RET' || viewname
truncated if necessary to fit in a NAME.
I've just committed fixes to make rule names be per-relation instead
of global, and it
Marc G. Fournier wrote:
[...]
Oh, and, of course, its running on v7.2.1 now, which means that VACUUMs no
longer lock up the search ... last night, I had something like 367
indexers pounding away at the database *and* a VACUUM running *and* did a
search in 2 minutes (considering that is 367
Bruce Momjian wrote:
Jan Wieck wrote:
I missed some of the discussion, because I considered the
1,000 digits already beeing complete nonsense and dropped the
thread. So could someone please enlighten me what the real
reason for increasing our precision
Bruce Momjian wrote:
Well, our regression tests are not intended to test every possible
NUMERIC combination, just a resonable subset. As it is now, I often
think the regression tests have hung because numeric takes so much
longer than any of the other tests. We have had this code in there
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
Well, our regression tests are not intended to test every possible
NUMERIC combination, just a resonable subset. As it is now, I often
think the regression tests have hung because numeric takes so much
longer than any
Bruce Momjian wrote:
Jan Wieck wrote:
You forgot who wrote that code originally. I feel alot
better WITH the tests in place :-)
And if it's merely to make sure the install worked, man who
is doing source installations these days and runs
Bruce Momjian wrote:
Sorry I couldn't understand your point.
It seems the simplest and the most certain way is to call
'SET QUERY_TIMEOUT per query. The way dosen't require
RESET at all. Is the overhead an issue ?
What about psql and libpq. Doing a timeout before every
Tom Lane wrote:
Karel Zak [EMAIL PROTECTED] writes:
Is there some problem implement SET ... ON ROLLBACK UNSET ?
Yes. See my previous example concerning search_path: that variable
MUST be rolled back at transaction abort, else we risk its value being
invalid. We cannot offer the user a
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Is an invalid search path really that critical (read security
issue)?
It's not a security issue (unless the OID counter wraps around soon
enough to let someone else get assigned the same OID for a namespace).
But it could
Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Could we get out of this by defining that timeout is
automatically reset at next statement end?
I was hoping to avoid that, because it seems like a wart. OTOH,
it'd be less of a wart than the global changes of semantics
Justin Clift wrote:
Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
Would it be an idea to have pg_dump append an ANALYZE; command to the end of
its dumps to assist newbies / inexperienced admins?
I do not think this is
Christopher Kings-Lynne wrote:
Yeah, although it'd still be a good idea probably to convert the dump form
to ALTER TABLE in any case. The one downside that was brought up in the
past was the time involved in checking dumped (presumably correct) data
when the constraint is added to very
Rod Taylor wrote:
2) re-check any constraint inserted into the database
There should not be any if it was accepted, however if it's a new
constraint it doesn't get applied to data that already exists. A dump
and restore will ignore these as well (with good reason).
Please don't make
Tom Lane wrote:
Jessica Perry Hekman [EMAIL PROTECTED] writes:
My other question was how to send the timeout value to the backend.
I would imagine that the most convenient way to handle it would be as
a SET variable:
SET query_timeout = n;
Establishes a time limit on subsequent
Christopher Kings-Lynne wrote:
File size limit exceeded (core dumped)
We suspect pg_dump. Is this true? Why would there be this limit in
pg_dump? Is it scheduled to be fixed?
Try piping the output of pg_dump through bzip2 before writing it to disk.
Or else, I think that pg_dump
Mario Weilguni wrote:
I've a severe problem with deadlocks in postgres, when using referential integrity
it's quite easy to trigger deadlocks. I think the may be a bug in ri_trigger.c
(discussed later). Here's some short example:
create table languages (
idinteger not null,
Rod Taylor wrote:
There was no deadlock in 7.2 with what was provided -- but the second
transaction was blocked from doing it's thing by the lock from the
first. Perhaps a deadlock is caused by 'do other stuff'?
I will agree that a FOR UPDATE is heavy. There is no intention to
update the
Bruce Momjian wrote:
I see in quote.c::do_quote_ident():
*cp2++ = '';
while (len-- 0)
{
if (*cp1 == '')
*cp2++ = '';
if (*cp1 == '\\')
*cp2++ = '\\';
*cp2++ = *cp1++;
}
*cp2++ = '';
I am confused by the backslash
701 - 800 of 910 matches
Mail list logo
