On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
[I have an outstanding question on how to include LWlock support into
the archiver, required to flesh out the feature set, and of course
assuming these patches being accepted.]
The archiver is
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote:
The archiver is deliberately designed not to be connected to shared
memory. If you want to change that you'll have to make a very strong
case why we should give up the safety and security advantages of
Joe Conway [EMAIL PROTECTED] writes:
In transformExpr the comment implies that it should be safe to reapply
to an already transformed expression. What if we free the raw_parser
expression list/cells/nodes and replace it with the as-transformed one?
How are you going to do the replace bit? The
Andreas Pflug [EMAIL PROTECTED] writes:
utils/adt/misc.c says:
//* Disabled in 8.0 due to reliability concerns; FIXME someday *//
Datum
*pg_terminate_backend*(PG_FUNCTION_ARGS)
Well, AFAIR there were no more issues raised about code paths that don't
clean up correctly, so can we please
Yoon [EMAIL PROTECTED] writes:
It would be nice to know how each directories are related to each other
or at least a pointer to where I should look.
http://www.postgresql.org/docs/8.1/static/storage.html
regards, tom lane
---(end of
Joshua D. Drake [EMAIL PROTECTED] writes:
Well if an initdb was not required, I think that would be a huge feature
;) (I know it may not work release over release)
If someone had started working on pg_upgrade six months ago, we might
have that for 8.2 ...
regards, tom
Hi,
I just committed some changes by Joachim that should reduce the problems
and the differences by a large margin. Could you please rerun the test
and send us the regression.diff? Thanks a lot in advance.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot
Andrew Dunstan wrote:
Andreas Pflug wrote:
Since I have a stuck backend without client again, I'll have to kill
-SIGTERM a backend. Fortunately, I do have console access to that
machine and it's not win32 but a decent OS.
You do know that on Windows you can use pg_ctl to send a pseudo
Michael Meskes [EMAIL PROTECTED] writes:
I just committed some changes by Joachim that should reduce the problems
and the differences by a large margin. Could you please rerun the test
and send us the regression.diff? Thanks a lot in advance.
While init.pgc no longer fails outright, it still
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
utils/adt/misc.c says:
//* Disabled in 8.0 due to reliability concerns; FIXME someday *//
Datum
*pg_terminate_backend*(PG_FUNCTION_ARGS)
Well, AFAIR there were no more issues raised about code paths that don't
clean up
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
utils/adt/misc.c says:
//* Disabled in 8.0 due to reliability concerns; FIXME someday *//
Datum
*pg_terminate_backend*(PG_FUNCTION_ARGS)
Well, AFAIR there were no more issues raised about code paths that don't
clean up
On Thu, Aug 03, 2006 at 09:47:27AM -0400, Tom Lane wrote:
While init.pgc no longer fails outright, it still generates a pile of
unsightly compiler warnings, eg on Fedora 5 (gcc 4.1.1)
...
I find this really unacceptable. There is no other part of the Postgres
tree besides ecpg that generates
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, you have that backwards. The burden of proof is on those who want
it to show that it's now safe. The situation is not different than it
was before, except that we can now actually point to a specific bug that
did exist, whereas the
What I'm looking for is some concentrated testing. The fact that some
people once in a while SIGTERM a backend doesn't give me any confidence
in it.
Now wait a minute, is there some risk of lockup if I kill a backend ?
Cause I do that relatively often (say 20 times a day, when some web
users
On Thu, Aug 03, 2006 at 04:54:35PM +0200, Michael Meskes wrote:
diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.
Strange, works well on my Linux system. However, I tried correcting the
option but I'm unsure if it works for you now since both versions
Andreas Seltenreich [EMAIL PROTECTED] writes:
I think there's a call to pgstat_count_index_scan missing in GIN.
Currently, the idx_scan column of pg_stat_*_indexes is stuck at zero
for GIN indexes.
Patch attached.
Looks correct to me --- applied.
regards, tom lane
Joachim Wieland [EMAIL PROTECTED] writes:
diff: `-3' option is obsolete; omit it
diff: Try `diff --help' for more information.
This got introduced by Rocco's Makefile patch, it worked for me, so I
thought it's fine. Rocco, your AIX box will work with only diff -c as well,
won't it?
The
Csaba Nagy [EMAIL PROTECTED] writes:
Now wait a minute, is there some risk of lockup if I kill a backend ?
Cause I do that relatively often (say 20 times a day, when some web
users time out but their query keeps running). Should I rather not do it
?
statement_timeout is your friend.
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
On Wed, 2006-08-02 at 18:49 -0400, Tom Lane wrote:
The archiver is deliberately designed not to be connected to shared
memory. If you want to change that you'll have to make a very strong
case why we should give up the
PostgreSQL provides a way to load C extension modules with its internal
FMGR. Unfortunately there is no portable way for an extension module to
initialize (directly after the pg_dlopen() of the DSO) and to finish
(directly before the pg_dlclose() of the DSO). This way it is mostly
impossible to
On Tue, Aug 01, 2006 at 02:26:18PM -0700, [EMAIL PROTECTED] wrote:
Kenneth Marshall wrote:
On Fri, Jul 28, 2006 at 12:14:49PM -0500, Jim C. Nasby wrote:
On Thu, Jul 27, 2006 at 01:46:01PM -0400, Alvaro Herrera wrote:
Jim Nasby wrote:
On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
[EMAIL PROTECTED] (Tom Lane) writes:
Joshua D. Drake [EMAIL PROTECTED] writes:
Well if an initdb was not required, I think that would be a huge feature
;) (I know it may not work release over release)
If someone had started working on pg_upgrade six months ago, we might
have that for 8.2
Michael Fuhr [EMAIL PROTECTED] writes:
Set tg_trigtuple/tg_newtuple in AFTER triggers according to whether
old and new tuples were supplied rather than blindly setting them
according to the event type. Per discussion in pgsql-hackers.
Looks good, applied.
regards, tom
Rod Taylor írta:
For db restoration (pg_dump), how do you restore to the same values as
previously if it is always regenerated? By making ALWAYS a suggestion
for some users instead of always enforced and providing an override
mechanism for it. I assume it only works for relation owners but I've
Markus Schiltknecht wrote:
Hi,
Andrew Hammond wrote:
I can see value in documenting what replication systems are known to
work (for some definition of work) with a given release in the
documentation for that release. Five years down the road when I'm
trying to implement replication
unsubscribe
--
Wade Klaver
Wavefire Technologies Corporation
GPG Public Key at http://archeron.wavefire.com
/\ ASCII Ribbon Campaign .
\ / - NO HTML/RTF in e-mail .
X - NO Word docs in e-mail .
/ \ -
You didn't answer the original question: is killing SIGTERM a backend
known/suspected to be dangerous ? And if yes, what's the risk (pointers
to discussions would be nice too).
statement_timeout is your friend.
I know, but unfortunately I can't use it. I did try to use
statement_timeout and it
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, you have that backwards. The burden of proof is on those who want
it to show that it's now safe.
If the backend's stuck, I'll have to SIGTERM it, whether there's
pg_terminate_backend or not.
Stuck? You have not shown us a case
On Wed, Aug 02, 2006 at 09:04:11PM +0200, Ralf S. Engelschall wrote:
PostgreSQL provides a way to load C extension modules with its internal
FMGR. Unfortunately there is no portable way for an extension module to
initialize (directly after the pg_dlopen() of the DSO) and to finish
(directly
On Thu, 2006-08-03 at 18:10, Csaba Nagy wrote:
You didn't answer the original question: is killing SIGTERM a backend
^^^
Nevermind, I don't do that. I do 'kill backend_pid' without specifying
the signal, and I'm sufficiently unfamiliar
On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:
The spelling we've used for many years is
diff -w -C3
I found only -w, but will append -C3 as well.
Is there a reason to change from that?
No.
At least from my perspective, it would be good if there were a way to
run the
Stuck? You have not shown us a case where SIGTERM rather than SIGINT
is necessary or appropriate. It seems to me the above is assuming the
existence of unknown backend bugs, exactly the same thing you think
I shouldn't be assuming ...
I do know a case where a plain kill will seem to be
Joachim Wieland [EMAIL PROTECTED] writes:
On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:
At least from my perspective, it would be good if there were a way to
run the regression tests without any use of TCP ports.
Do you see a possibility to select what test should be run? Maybe no
Joachim Wieland [EMAIL PROTECTED] writes:
On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:
The spelling we've used for many years is
diff -w -C3
I found only -w, but will append -C3 as well.
Careful, there are two different usages: we use -C3 to generate the
pretty report to
Csaba Nagy [EMAIL PROTECTED] writes:
I do know a case where a plain kill will seem to be stucked: on vacuum
of a big table. I guess when it starts an index's cleanup scan it will
insist to finish it before stopping.
We've fixed a few cases of missing CHECK_FOR_INTERRUPTS lately, and will
fix
Tom Lane wrote:
Andreas Pflug [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, you have that backwards. The burden of proof is on those who want
it to show that it's now safe.
If the backend's stuck, I'll have to SIGTERM it, whether there's
pg_terminate_backend or not.
Csaba Nagy wrote:
On Thu, 2006-08-03 at 18:10, Csaba Nagy wrote:
You didn't answer the original question: is killing SIGTERM a backend
^^^
Nevermind, I don't do that. I do 'kill backend_pid' without specifying
the signal, and
Csaba Nagy [EMAIL PROTECTED] writes:
On Thu, 2006-08-03 at 18:10, Csaba Nagy wrote:
You didn't answer the original question: is killing SIGTERM a backend
^^^
Nevermind, I don't do that. I do 'kill backend_pid' without specifying
the
Bruce Momjian wrote:
I am not sure how you prove the non-existance of a bug. Ideas?
Would be worth at least the Nobel prize :-)
Regards,
Andreas
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
man kill says the default is SIGTERM.
OK, so that means I do use it... is it known to be dangerous ? I thought
till now that it is safe to use. What about select pg_cancel_backend()
?
Thanks,
Csaba.
---(end of broadcast)---
TIP 9: In versions
Csaba Nagy wrote:
man kill says the default is SIGTERM.
OK, so that means I do use it... is it known to be dangerous ? I thought
till now that it is safe to use.
Apparently you never suffered any problems from that; neither did I.
What about select pg_cancel_backend()
That's the
Andrew Hammond wrote:
How about what works with a given release at the time of the
release?
We just threw that idea out in the context of the procedural language
discussion because we do not have the resources to check what works.
Arguably, neither are most of the procedural languages in the
I am not sure how you prove the non-existance of a bug. Ideas?
I do that by deleting all of my code (usually by accident :-)
No code, no bugs!
-- Korry
There are a number of different approaches to solving the problem of
replication, each with strengths and weaknesses. As a result, there
are a number of different replication solutions available for
PostgreSQL. To find out more, please refer to the website.
Well, that's what I've been
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
Here is a patch to collect statistics of LWLocks.
This seems fairly invasive, as well as confused about whether it's an
#ifdef'able thing or not. You can't have system views and pg_proc
entries conditional on a compile-time #ifdef, so in a default
Simon Riggs [EMAIL PROTECTED] writes:
WIP archive_timeout.
All we need to do is add LWLock support to archiver.
Thoughts/ideas/hints welcome.
Hint: this isn't the archiver's problem, and so you don't need to get
the archiver involved in the solution. I'd suggest bgwriter as a
reasonably
On Thu, 2006-08-03 at 13:38 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
WIP archive_timeout.
All we need to do is add LWLock support to archiver.
Thoughts/ideas/hints welcome.
Hint: this isn't the archiver's problem, and so you don't need to get
the archiver involved in
or so timeframe ... but feel free to improve it if you can.
I'm not very familiar with yacc/bison, so pls, review attached patch. I may miss
something... It's based on ideas in previous discussions:
http://www.pgsql.ru/db/mw/msg.html?mid=1995063
http://www.pgsql.ru/db/mw/msg.html?mid=2091842
From: Joachim Wieland [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 03, 2006 11:23 AM
To: Tom Lane; Michael Meskes; Rocco Altier; PostgreSQL Hacker
Subject: Re: [HACKERS] ecpg test suite
On Thu, Aug 03, 2006 at 04:54:35PM +0200, Michael Meskes wrote:
diff: `-3' option is obsolete;
Hi James,
I just wanted to inform you all that I solvethe issue, it was indeed the nul device as James and Martijn mention.
I have change the source to redirect the output to a log file, to which I gave permission to the "postgres" user.
The file (currently) is created at the temp folder.
This
On Thu, Aug 03, 2006 at 06:49:31PM +, dror wrote:
Hi James,
I just wanted to inform you all that I solve the issue, it was indeed the nul
device as James and Martijn mention.
I have change the source to redirect the output to a log file, to which I
gave permission to the postgres
I'm surprised you got the patch so small. Mind you, you didn't do any
folding in the productions for NUMERIC and CHAR which in the long term
would probably need to be done. Also, there's the issue of converting
the arguments to a typmod, in the long term it'd have to be
user-defined per type.
Martijn van Oosterhout kleptog@svana.org writes:
I'm surprised you got the patch so small. Mind you, you didn't do any
folding in the productions for NUMERIC and CHAR which in the long term
would probably need to be done.
Yeah, the patch ought to be making the grammar smaller not bigger.
Ron Mayer [EMAIL PROTECTED] writes:
Would people be interested in a trivial patch that adds O_NOATIME
to open() for platforms that support it? (apparently Linux 2.6.8
and better).
Isn't that usually, and more portably, handled in the filesystem
mount options?
regards,
On Thu, Aug 03, 2006 at 04:18:53PM -0400, Tom Lane wrote:
Also, there's the issue of converting
the arguments to a typmod, in the long term it'd have to be
user-defined per type.
I think we could legislate that the stored typmod is the same as what
the user sees (and can't be negative).
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Would people be interested in a trivial patch that adds O_NOATIME
to open() for platforms that support it? (apparently Linux 2.6.8
and better).
Isn't that usually, and more portably, handled in the filesystem
mount options?
Yes to both.
On Thu, Aug 03, 2006 at 12:05:23PM -0400, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Set tg_trigtuple/tg_newtuple in AFTER triggers according to whether
old and new tuples were supplied rather than blindly setting them
according to the event type. Per discussion in
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Aug 03, 2006 at 04:18:53PM -0400, Tom Lane wrote:
I think we could legislate that the stored typmod is the same as what
the user sees (and can't be negative). The fact that it's different
for some of the built-in types is a historical
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
Isn't that usually, and more portably, handled in the filesystem
mount options?
Yes to both. I could imagine that for small systems/workstations
you might have some files that want access time, and others that
wanted NOATIME -- it seems
Michael Fuhr [EMAIL PROTECTED] writes:
Thanks. Alvaro made the following suggestion but didn't copy the
list -- shall I do what he suggested and submit the changes as
another patch?
Alvaro Herrera wrote:
I'd add an Assert() on the second hunk to make sure newtuple is only set
in UPDATE.
Ralf S. Engelschall [EMAIL PROTECTED] writes:
Hence I propose the patch below (applies to PostgreSQL 8.1.4) which
mimics the dlopen(3) and dlclose(3) behaviour of some Unix platforms
and resolves and calls _PG_init and _PG_fini functions of an extension
module right after/before the
Tom Lane wrote:
Ron Mayer [EMAIL PROTECTED] writes:
Tom Lane wrote:
Isn't that usually, and more portably, handled in the filesystem
mount options?
Yes to both. I could imagine that for small systems/workstations
you might have some files that want access time, and others that
wanted
On Thu, Aug 03, 2006 at 05:30:48PM -0400, Tom Lane wrote:
Ralf S. Engelschall [EMAIL PROTECTED] writes:
Hence I propose the patch below (applies to PostgreSQL 8.1.4)
which mimics the dlopen(3) and dlclose(3) behaviour of some Unix
platforms and resolves and calls _PG_init and _PG_fini
David Fetter [EMAIL PROTECTED] writes:
On Thu, Aug 03, 2006 at 05:30:48PM -0400, Tom Lane wrote:
One question I have is whether it really works as expected in all
cases. In particular what if the library is preloaded into the
postmaster?
I'm not sure quite what you mean here, but PL/PerlU
Tom Lane wrote:
Ralf S. Engelschall [EMAIL PROTECTED] writes:
Hence I propose the patch below (applies to PostgreSQL 8.1.4) which
mimics the dlopen(3) and dlclose(3) behaviour of some Unix platforms
and resolves and calls _PG_init and _PG_fini functions of an extension
module right
Here is my updated regression.diff.
Like Tom, I was running with my server configured to run on 5678,
instead of 5432, so it seems like the test is using a wrong port number
somewhere.
I changed my local pg_regress.sh to use -C3 on the diffs, until we
figure out what the final form of that will
On Thu, Aug 03, 2006 at 11:36:22AM -0400, Tom Lane wrote:
The spelling we've used for many years is
diff -w -C3
Is there a reason to change from that?
This was my fault. When I changed the options I mixed upper and
lowercase and used lowercase 'c' instead of uppercase 'C'. That should
be
Simon Riggs [EMAIL PROTECTED] writes:
Patch included to implement xlog switching, using an xlog record
processing instruction and forcibly moving xlog pointers.
Just to be clear --- does this fully supersede your draft patch of
27-July, or is that still on the table too?
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
No, you have that backwards. The burden of proof is on those who want
it to show that it's now safe. The situation is not different than it
was before, except that we can now actually point to a specific bug that
Katsuhiko Okano [EMAIL PROTECTED] writes:
(A) The algorithm which replaces a buffer is bad.
A time stamp does not become new until swapout completes
the swapout page.
If access is during swap at other pages, the swapout page will be
in the state where it is not used most,
It is again
Tom Lane wrote:
Also, if we do this we probably ought to remove the special-purpose
hack for preload_libraries to specify an init function --- it should
just happen by default. Any objections to simplifying that?
The original idea of using the init function with preload_libraries was
to
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
What I'm looking for is some concentrated testing. The fact that some
people once in a while SIGTERM a backend doesn't give me any confidence
in it.
OK, here is an opportunity for someone to run tests to get this into
8.2. The code
Thanks. Good plan.
---
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
What I'm looking for is some concentrated testing. The fact that some
people once in a while SIGTERM a backend doesn't
Hi,
next version follows. Changes:
- Supports OVERRIDING { USER | SYSTEM } VALUE syntax
not yet documented, I have doubts about USER variant
- UPDATES is forbidden entirely on GENERATED ALWAYS
AS IDENTITY columns, UPDATE tab SET col = DEFAULT is
allowed on GENERATED ALWAYS AS ( expr )
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
Also, if we do this we probably ought to remove the special-purpose
hack for preload_libraries to specify an init function --- it should
just happen by default. Any objections to simplifying that?
The original idea of
On Thu, Aug 03, 2006 at 05:04:47PM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Aug 03, 2006 at 04:18:53PM -0400, Tom Lane wrote:
I think we could legislate that the stored typmod is the same as what
the user sees (and can't be negative). The fact that
Tom Lane wrote:
If I thought that average users would have a need for LWLock statistics,
I'd be more sympathetic to expending effort on a nice frontend for
viewing the statistics, but this is and always will be just a concern
for hardcore hackers ...
That may be true of the output, but that's
Gavin Sherry [EMAIL PROTECTED] writes:
On Fri, 4 Aug 2006, Michael Glaesemann wrote:
On Aug 3, 2006, at 23:58 , Tom Lane wrote:
Should we give VALUES its own reference page? That doesn't quite
seem helpful either.
I think we should go for a separate reference page, as VALUES appears
to be
I am seeing two new warnings from ecpg:
dyntest.pgc:66: WARNING: nullable is always 1
dyntest2.pgc:72: WARNING: nullable is always 1
Are they to be expected? I looked at where they are being generated but
didn't understand it.
--
Bruce Momjian [EMAIL PROTECTED]
I'm not clear on why there's all this doom and gloom about how 8.2 will
be merely a performance-oriented release, with few new features, eg
http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php
Certainly there's been a ton of effort spent on high-end performance
issues. But a quick
My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.
---
Tom Lane wrote:
I'm not clear on why there's all this doom and gloom about how 8.2 will
On Fri, 4 Aug 2006, Bruce Momjian wrote:
My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.
It seems as though the majority of things on Tom's list are new things you
couldn't do (at all easily) before.
Gavin
Gavin Sherry wrote:
On Fri, 4 Aug 2006, Bruce Momjian wrote:
My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.
It seems as though the majority of things on Tom's list are new things you
couldn't do (at all
Tom Lane wrote:
The reason we could safely list_free inside transformInsertRow is that
we know all its callers have just built the passed-in list and so there
are no other pointers to it. That doesn't apply in the general case of
grammar output.
What about for the specific case of an
On Fri, 4 Aug 2006, Bruce Momjian wrote:
Gavin Sherry wrote:
On Fri, 4 Aug 2006, Bruce Momjian wrote:
My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.
It seems as though the majority of things on
Seems Pavel has submitted the patch now, and I place it in the patch
queue.
---
David Fetter wrote:
On Fri, Jul 28, 2006 at 10:42:49AM +0200, Pavel Stehule wrote:
Hello,
I miss better support OUT arguments in
[ Tom's include adjustment added.]
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Gavin Sherry wrote:
On Fri, 4 Aug 2006, Bruce Momjian wrote:
Gavin Sherry wrote:
On Fri, 4 Aug 2006, Bruce Momjian wrote:
My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.
It seems as
Bruce Momjian [EMAIL PROTECTED] writes:
To me new things are like PITR, Win32, savepoints, two-phase commit,
partitioned tables, tablespaces. These are from 8.0 and 8.1. What is
there in 8.2 like that?
[ shrug... ] Five out of your six items have no basis in the SQL spec.
So it's not clear
Bruce Momjian wrote:
Gavin Sherry wrote:
On Fri, 4 Aug 2006, Bruce Momjian wrote:
My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.
It seems as though the majority of things on Tom's list are new things you
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
To me new things are like PITR, Win32, savepoints, two-phase commit,
partitioned tables, tablespaces. These are from 8.0 and 8.1. What is
there in 8.2 like that?
[ shrug... ] Five out of your six items have no basis in the SQL
Joshua D. Drake wrote:
Bruce Momjian wrote:
Gavin Sherry wrote:
On Fri, 4 Aug 2006, Bruce Momjian wrote:
My outlook is that it isn't a lot of _new_ things that you couldn't do
before, but rather improvements of existing functionality.
It seems as though the majority of things on Tom's
Joe Conway [EMAIL PROTECTED] writes:
What about for the specific case of an InsertStmt? It seems that we
could at least get away with freeing the raw-expression list in that case.
Not sure ... what about rules, BETWEEN, yadda yadda?
In terms of freeing an entire arbitrary node, could we
It seems as though the majority of things on Tom's list are new things you
couldn't do (at all easily) before.
To me new things are like PITR, Win32, savepoints, two-phase commit,
partitioned tables, tablespaces. These are from 8.0 and 8.1. What is
there in 8.2 like that?
Well to be honest,
94 matches
Mail list logo
