David Fetter skrev:
As far as big missing features go, here's a short list:
* Windowing functions
If we are to wish for things the window functions and a proper
collation/locale support is what I miss the most.
/Dennis
---(end of broadcast)
All,
Aren't I, the marketing geek, supposed to be the one whining about
this?
Seriously, PostgreSQL has the fastest release cycle of any RDBMS project in
the world. The request I'm hearing from large production users is to release
*less* often. So I don't find it a problem that this release
David,
On 8/3/06 11:02 PM, "David Fetter" <[EMAIL PROTECTED]> wrote:
> * Splitting queries among CPUs--possibly even among machines--for OLAP
> loads
>
> * In-place upgrades (pg_upgrade)
>
> * Several varieties of replication, which I believe we as a project
> will eventually endorse and sh
Ühel kenal päeval, R, 2006-08-04 kell 00:46, kirjutas Bruce Momjian:
> 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
On Fri, Aug 04, 2006 at 12:37:10AM -0400, 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... ] Fi
+1
UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, then
we'd be able to claim "complete" support for partitioning, but this is a big
deal improvement.
- Luke
On 8/3/06 9:30 PM, "Gavin Sherry" <[EMAIL PROTECTED]> wrote:
> A lot of the things on Tom's list are new bits o
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, the
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
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
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
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
couldn
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 cl
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.
>
[ 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.
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
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 majorit
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 InsertStm
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
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
-
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
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
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]
Enterprise
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
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 tha
On Thu, Aug 03, 2006 at 05:04:47PM -0400, Tom Lane wrote:
> Martijn van Oosterhout 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 differ
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 us
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 ) columns
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 using the i
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 backen
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.
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 eli
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 i
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 specifi
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?
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
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 b
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 aft
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
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_
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 t
"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 pg_
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 U
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 -- i
Martijn van Oosterhout 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 artifact tha
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 pgsq
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?
Y
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 neg
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?
rega
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).
It seems to work here, feels harmless to me (an easy ifdef to
check if it's there), and seems it would theoretically help,
though I don't notice a consis
Martijn van Oosterhout 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.
> Also, there's the
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.
Stil
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 "postgr
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" user.
The file (currently) is created at the temp folder.
This
> 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 o
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
> > "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
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
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 a
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 bu
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
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
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()"
>
> "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 version
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?
http:/
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
>
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 sig
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_termi
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
f
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 t
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? M
> "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
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
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 wit
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
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
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
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 .
/ \ -
-
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 repl
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
n
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,
[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
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 La
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 wri
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 sho
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.
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?
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 lan
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
> 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
user
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, w
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 gener
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
> > c
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
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 sti
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 t
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 (De|C
"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,
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 broadcast
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 ple
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
1 - 100 of 101 matches
Mail list logo