On Wed, 2004-12-01 at 15:54 -0500, Tom Lane wrote:
> This seems like it might work. Instead of copying the result into the
> aggcontext on every cycle, we could copy it only when we intend to reset
> the working context.
Right.
> This is
> problematic since the source tuple will go away on the n
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
we could also check errno for SIGPIPE rather than calling sigpending.
He has a concern about an application that already blocked SIGPIPE and
has a pending SI
This recent change to readline/libedit selection isn't quite right.
http://archives.postgresql.org/pgsql-committers/2004-11/msg00330.php
It doesn't link in libtermcap with libedit which leads to:
checking for readline.h... no
configure: error: readline header not found
If you have libedit alrea
On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
> Neil, where are we on this? Should we add comments? Add a TODO? A patch?
I'm not sure what the right resolution is. As I said, I don't think it's
wise to apply a patch that could have a significant impact on
performance without (a) testi
Tom Lane wrote:
> "Thomas F.O'Connell" <[EMAIL PROTECTED]> writes:
> > So why not have VACUUM FULL FREEZE just do what you propose: VACUUM
> > FULL then VACUUM FREEZE.
>
> The objective is to make it more safe, not less so. Doing that would
> require rewriting a whole bunch of code, which I am n
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Rod Taylor wrote:
> >> Anyway, it shows a situation where it would be nice to differentiate
> >> between statement_timeout and lock_timeout OR it demonstrates that I
> >> should be using userlocks...
>
> > Wouldn't a LOCK NOWAIT be a
On 12/1/2004 1:35 PM, Brett Schwarz wrote:
--- Jan Wieck <[EMAIL PROTECTED]> wrote:
On 12/1/2004 9:23 AM, Jan Wieck wrote:
> On 12/1/2004 4:27 AM, Richard Huxton wrote:
>
>> Thomas Hallgren wrote:
>>> Richard Huxton wrote:
>>>
Can I make some counter-proposals?
1. Wrap each functio
On Wed, Dec 01, 2004 at 08:10:24PM -0700, Michael Fuhr wrote:
> Don't know about Solaris 9/sparc yet -- the whole dance takes over
> an hour on my (t)rusty ol' Ultra 1.
Solaris 9/sparc passes all tests.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---(end of broadcast)--
On Wed, 2004-12-01 at 19:34 +0100, [EMAIL PROTECTED] wrote:
> I regard performance testing as an essential part of the
> release process of any performance critical software. Most earlier beta
> releases were fixing functional problems and now the focus has moved to
> performance related issues.
I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Yes, that is the logic in my patch, except that I don't check errno, I
> just call sigpending().
No, that's wrong: if there is a pending SIGPIPE that belongs to the
outer app, you'd clear it.
> There are a few writes and it seemed impossible
> to check
Tom Lane wrote:
If the C library does support queued signals then we will read the
existing SIGPIPE condition and leave our own signal in the queue. This
is no problem to the extent that one pending SIGPIPE looks just like
another --- does anyone know of platforms where there is additional info
ca
On Wed, Dec 01, 2004 at 08:35:40PM -0500, Tom Lane wrote:
> Okay, I committed some tweaks to reduce platform dependencies. I get
> passes now on all three platforms I have handy.
It passes on my FreeBSD 4.10-STABLE box.
Don't know about Solaris 9/sparc yet -- the whole dance takes over
an hour
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I've raised this before, but would like to suggest again that there might be
> virtue in branching earlier in the dev cycle - maybe around the time of the
> first beta.
Given the amount of patching that's gone on, branching 8.1 earlier would
have mean
Neil Conway <[EMAIL PROTECTED]> writes:
> The attached patch invokes the transition function in the current memory
> context. I don't think that's right: a memory leak in an aggregate's
> transition function would be problematic when we're invoked from a
> per-query memory context, as is the case w
Manfred Spraul wrote:
> >This seems workable as long as we document the possible gotchas.
> >
> >
> >
> Is that really worthwhile? There are half a dozend assumption about the
> C library and kernel internal efficiency of the signal handling
> functions in the proposal. Adding a PQinitLib funct
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am seeing the following regression failures with CVS head and
> > inheritance tests. They look like sort order problems:
>
> Does it go away if you initdb? I suspect the size of pg_class is a
> factor in the choice of plan for tha
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Does it go away if you initdb? I suspect the size of pg_class is a
> >> factor in the choice of plan for that query. You seem to still be
> >> getting the old plan ...
>
> > An initdb does not change the regress
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
> > we could also check errno for SIGPIPE rather than calling sigpending.
>
> > He has a concern about an application that already blocked SIGPIPE and
> > has a
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Is that really worthwhile? There are half a dozend assumption about the
> C library and kernel internal efficiency of the signal handling
> functions in the proposal. Adding a PQinitLib function is obviously a
> larger change, but it solves the proble
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Hmph. I'm unsure why there's a platform dependency there, but we should
>> probably just add an ORDER BY to suppress it. Will do.
> Why did it just appear? Optimizer changes in the past few days?
I did just change the planner, but
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Does it go away if you initdb? I suspect the size of pg_class is a
>> factor in the choice of plan for that query. You seem to still be
>> getting the old plan ...
> An initdb does not change the regression failure. Sorry.
Hmph. I
Neil, where are we on this? Should we add comments? Add a TODO? A patch?
---
Neil Conway wrote:
> On Wed, 2004-11-24 at 23:30 -0500, Tom Lane wrote:
> > It is not a 100% solution because it does not
> > cover the case whe
Antti Salmela <[EMAIL PROTECTED]> writes:
> Index is used incorrectly if constant part of the string ends with \d,
Yeah, you're right --- that code predates our use of the new regexp
engine, and it didn't know that escapes aren't simply quoted characters.
Now that I look at it, it's got a multiby
Neil Conway said:
> On Wed, 2004-12-01 at 11:08 -0300, Alvaro Herrera wrote:
>
>> There's real development waiting only for release to happen ...
>
> There is real development being done as we speak, that will be landed
> to 8.1 when it branches :)
>
I've raised this before, but would like to sugg
You will be glad to know that 8.0 will use a different implementation
for thread handling of SIGPIPE, though your asynchronous handling of
SIGPIPE will still cause problems.
---
Jim Seymour wrote:
> Hi,
>
> I'm kind of wond
Neil Conway <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> I am seeing the following regression failures with CVS head and
>> inheritance tests. They look like sort order problems:
> I see regression test failures in both inheritence and join (after a
> fresh initdb).
On Wed, 2004-12-01 at 11:08 -0300, Alvaro Herrera wrote:
> When would the experimentation end, and 8.0 be finally released?
As I said, this is work for 8.1; I don't think it ought to affect the
release schedule of 8.0 (perhaps in some marginal way because Tom might
spend some time discussing issue
Neil Conway <[EMAIL PROTECTED]> writes:
> I see regression test failures in both inheritence and join (after a
> fresh initdb). Attached is the regression.diffs, gzip'ed.
Yeah, so do I on a Linux machine. It looks like the dynamic size
estimates are highlighting some platform dependencies, such a
On Wed, 2004-12-01 at 17:22 -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am seeing the following regression failures with CVS head and
> > inheritance tests. They look like sort order problems:
>
> Does it go away if you initdb? I suspect the size of pg_class is a
> f
Index is used incorrectly if constant part of the string ends with \d,
probably also with other escapes.
foo=# explain select count(*) from loc where url ~
'^http://www\\.7-eleven\\.com/newsroom/articles\\.asp\\?p=\\d+'; QUERY PLAN
Aggregate (cost=3.46..3.46 rows=1 width=0)
-> Index Scan
Bruce Momjian wrote:
Comments? This seems like our only solution.
This would be a transparent solution. Another approach would be:
- Use the old 7.3 approach by default. This means perfect backward
compatibility for single-threaded apps and broken multithreaded apps.
- Add a new PQinitDB(int d
On Wed, Dec 01, 2004 at 02:02:41AM -0600, Bruno Wolff III wrote:
> On Mon, Nov 29, 2004 at 12:49:46 +,
> Chris Green <[EMAIL PROTECTED]> wrote:
> >
> > This is a perpetual problem, if people all used the same MUA and
> > (assuming it has the capability) all used the 'reply to list' command
>
Richard Huxton,
It feels more distinct to me. I'll grant you I'm only a sample size of
1 though.
Perhaps more distinct, but:
- Using savepoints together with try/catch is not exactly an unknown
concept. Try Google and you'll see a fair amount of examples advocating
the approach that I suggest.
-
Bruce Momjian said:
>
> Uh, what was the TODO here? I forgot.
>
>
John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
code. If there's a TODO it would be to investigate the possibility, as I am
very far from certain that there is a simple way to do it safely right now.
Maybe
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Uh, what was the TODO here? I forgot.
I think we already did what we decided was safe there.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following regression failures with CVS head and
> inheritance tests. They look like sort order problems:
Does it go away if you initdb? I suspect the size of pg_class is a
factor in the choice of plan for that query. You seem to still
Uh, what was the TODO here? I forgot.
---
John Hansen wrote:
> > I think it is *way* too late in the dev cycle to be proposing this.
> > Maybe it should be a TODO item - I at least don't have time even to
> > think about
I am seeing the following regression failures with CVS head and
inheritance tests. They look like sort order problems:
---
*** ./expected/inherit.out Wed Dec 1 16:53:51 2004
--- ./results/inherit.out Wed Dec 1
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I don't currently have the resources to clean this up properly. The
> > attached patch tries to make clear in a comment what the code is doing,
> > and also initializes these variables to NULL. If someone wants to take a
> > stab a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> His idea of pthread_sigmask/send/sigpending/sigwait/restore-mask. Seems
> we could also check errno for SIGPIPE rather than calling sigpending.
> He has a concern about an application that already blocked SIGPIPE and
> has a pending SIGPIPE signal waiti
On K, 2004-12-01 at 18:28, Cason, Kenny wrote:
> In postgres, how do I find out how many connections are allowed per
> user? Where those connections are stored? Who has the connections? Etc.
You can start from:
show all;
select * from pg_stat_activity;
-
Hannu
-
Bruce Momjian wrote:
[... SIGPIPE suppression in libpq ...]
Linux also has MSG_NOSIGNAL as a send() flag that might be useful. It
suppresses generation of SIGPIPE for just that call. No, it doesn't work
for SSL and it's probably not very portable, but it might be a good
platform-specific optimiz
Robert Treat wrote:
> On Wed, 2004-12-01 at 11:47, Bruce Momjian wrote:
> > David Parker wrote:
> > > How difficult would it be to make the combination
> > >
> > >log_statement = all
> > >log_duration = true
> > >
> > > just put the duration on the same line as the statement? Then
> > > l
Alvaro Herrera <[EMAIL PROTECTED]> wrote on 01.12.2004, 15:08:11:
> On Wed, Dec 01, 2004 at 10:03:40AM +, Simon Riggs wrote:
>
> > Please shave 20% off everybody's aggregation queries, ugly or not.
> > You'll see a lot of happy people.
>
> When would the experimentation end, and 8.0 be final
--- Jan Wieck <[EMAIL PROTECTED]> wrote:
> On 12/1/2004 9:23 AM, Jan Wieck wrote:
>
> > On 12/1/2004 4:27 AM, Richard Huxton wrote:
> >
> >> Thomas Hallgren wrote:
> >>> Richard Huxton wrote:
> >>>
> Can I make some counter-proposals?
>
> 1. Wrap each function body/call (same th
On Wednesday 01 December 2004 04:12, Thomas Hallgren wrote:
> Richard Huxton wrote:
> > Can I make some counter-proposals?
> >
> > 1. Wrap each function body/call (same thing here afaict) in a
> > sub-transaction. An exception can be caught within that function, and
> > all the spi in that function
On Wednesday 01 December 2004 03:38, Simon Riggs wrote:
> On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote:
> > David Parker wrote:
> > > I've been using "log_min_duration_statement = 0" to get durations on
> > > all SQL statements for the purposes of performance tuning, because this
> > > logs the
On Wed, 2004-12-01 at 11:47, Bruce Momjian wrote:
> David Parker wrote:
> > How difficult would it be to make the combination
> >
> >log_statement = all
> >log_duration = true
> >
> > just put the duration on the same line as the statement? Then
> > log_min_duration_statement could be use
David Parker wrote:
> How difficult would it be to make the combination
>
>log_statement = all
>log_duration = true
>
> just put the duration on the same line as the statement? Then
> log_min_duration_statement could be used to
> do the desired log-at-threshold behavior, which certainly
On 12/1/2004 9:23 AM, Jan Wieck wrote:
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
al
How difficult would it be to make the combination
log_statement = all
log_duration = true
just put the duration on the same line as the statement? Then
log_min_duration_statement could be used to
do the desired log-at-threshold behavior, which certainly seems
valuable. You'd need a way to
In postgres, how do I find out how many connections are allowed per
user? Where those connections are stored? Who has the connections? Etc.
Kenny Cason
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Simon Riggs wrote:
> On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote:
> > David Parker wrote:
> > > I've been using "log_min_duration_statement = 0" to get durations on all
> > > SQL statements for the purposes of performance tuning, because this logs
> > > the duration on the same line as the sta
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >Comments? This seems like our only solution.
> >
> >
> >
> This would be a transparent solution. Another approach would be:
> - Use the old 7.3 approach by default. This means perfect backward
> compatibility for single-threaded apps and broken
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> It is also possible for mailing list software to handle this
> preference for you (by not sending copies to addresses on the list
> that appear in the recipient headers), but I don't know if the
> software in use has that capability.
That's a good poin
Jan Wieck wrote:
This all would mean that however deeply nested a function call tree,
it would unwind and rollback everything up to the outermost catch. If
there is no catch used, no subtransactions are created and the
unwinding goes all the way up to the statement. If catch is used but
no spi
On Wed, Dec 01, 2004 at 09:33:18 +,
Chris Green <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 01, 2004 at 02:02:41AM -0600, Bruno Wolff III wrote:
> > On Mon, Nov 29, 2004 at 12:49:46 +,
> > Chris Green <[EMAIL PROTECTED]> wrote:
> > >
> > > This is a perpetual problem, if people all used t
On 12/1/2004 4:27 AM, Richard Huxton wrote:
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then roll
On Wed, Dec 01, 2004 at 10:03:40AM +, Simon Riggs wrote:
> Please shave 20% off everybody's aggregation queries, ugly or not.
> You'll see a lot of happy people.
When would the experimentation end, and 8.0 be finally released?
There's real development waiting only for release to happen ...
I
On Wed, 01 Dec 2004 10:29:17 +0100, Thomas Hallgren
<[EMAIL PROTECTED]> wrote:
> Richard Huxton wrote:
>
> > But is the problem not that forgetting to use SAVEPOINT can get us in
> > trouble with clearing up after an exception?
>
> I fail to see how that's different from forgetting to use pgtry i
On Wed, 2004-12-01 at 08:37, Neil Conway wrote:
> On Wed, 2004-12-01 at 08:25 +, Simon Riggs wrote:
> > I'd be a little twitchy about new memory contexts at this stage of beta,
> > but if the code is fairly well isolated that could be good.
>
> This would be for 8.1 anyway.
>
> > Would it pos
Thomas Hallgren wrote:
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
It feels more distinct to me. I'll grant you I'm only a
Richard Huxton wrote:
But is the problem not that forgetting to use SAVEPOINT can get us in
trouble with clearing up after an exception?
I fail to see how that's different from forgetting to use pgtry instead
of try.
Regards,
Thomas Hallgren
---(end of broadcast)---
Thomas Hallgren wrote:
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least it's
Richard Huxton wrote:
Can I make some counter-proposals?
1. Wrap each function body/call (same thing here afaict) in a
sub-transaction. An exception can be caught within that function, and
all the spi in that function is then rolled back. This is rubbish, but
at least it's predictable and allows
alex yap wrote:
Hi,
recently i need to use pg in my project. everything going ok till
when i want to createdb it appear this :
Warning : could not remove database directory
"/var/postgresql/data/base/17147" Detail: Failing system command was
: rm -rf '/var/postgresql/data/base/17147' Error: could n
Tom Lane wrote:
Wrapping each individual SPI command in a subtransaction IN NO WAY
prevents us from adding programmer-controllable savepoint features
to the PL languages later.
Ah good - I was coming to the conclusion savepoints/exception handling
were both separately necessary.
> It simply ensu
On Tue, 2004-11-30 at 19:32, Bruce Momjian wrote:
> David Parker wrote:
> > I've been using "log_min_duration_statement = 0" to get durations on all
> > SQL statements for the purposes of performance tuning, because this logs
> > the duration on the same line as the statement. My reading of this TO
On Wed, 2004-12-01 at 08:25 +, Simon Riggs wrote:
> I'd be a little twitchy about new memory contexts at this stage of beta,
> but if the code is fairly well isolated that could be good.
This would be for 8.1 anyway.
> Would it possible to differentiate between well-known builtin functions
>
On Wed, 2004-12-01 at 02:48, Neil Conway wrote:
> I noticed that we have a bottleneck in aggregate performance in
> advance_transition_function(): according to callgrind, doing datumCopy()
> and pfree() for every tuple produced by the transition function is
> pretty expensive. Some queries bare thi
70 matches
Mail list logo