Marc G. Fournier wrote:
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Are you using default values for autovacuum? Could you prove a
little more detail by setting pg_autovacuum debug with -d 2
Sure ... just restarted it with that setup ... btw ... I'm using -L
for logging ... what is the usual
Have you tried using cc_r for that compile line? Does that help?
---
Brad Nicholson wrote:
> Tried to install this on AIX 5.1, no luck (compiles fine without
> --enable-thread-safety though) .
>
> AIX 5.1
> gcc 3.3.2
>
On Fri, 2004-09-24 at 19:28, Neil Conway wrote:
> On Fri, 2004-09-24 at 05:52, Alvaro Herrera wrote:
> > I don't think we can do that in a standard function, at least not
> > without a lot of work.
>
> Can you elaborate on why this would be so difficult?
I never got a reply to this question -- so
On Thu, Sep 30, 2004 at 07:11:29PM -0400, Tom Lane wrote:
> More generally I think that invoking VACUUM processing from the bgwriter
> would be a serious violation of the module hierarchy, and would inflict
> more pain in the form of bugs and maintenance headaches than it could
> possibly be worth.
--On Donnerstag, September 30, 2004 16:32:48 -0700 Stephan Szabo
<[EMAIL PROTECTED]> wrote:
On Fri, 1 Oct 2004, Bernd Helmle wrote:
While having trouble extending the CREATE VIEW grammar i discovered this:
[EMAIL PROTECTED]:yomama #= CREATE VIEW vtest as SELECT * from abteilung
WITH; CREATE VIEW
On Fri, 1 Oct 2004, Bernd Helmle wrote:
> While having trouble extending the CREATE VIEW grammar i discovered this:
>
> [EMAIL PROTECTED]:yomama #= CREATE VIEW vtest as SELECT * from abteilung WITH;
> CREATE VIEW
I'm not sure what in particular you're getting at. Although technically
WITH is a re
While having trouble extending the CREATE VIEW grammar i discovered this:
[EMAIL PROTECTED]:yomama #= CREATE VIEW vtest as SELECT * from abteilung WITH;
CREATE VIEW
I can reproduce this on 8.0.0beta1 && beta3 and in a 7.4.2 production
database.
Bernd
---(end of broadcast)
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> One idea would be to vacuum the page if it can be determined that the
> relation doesn't have indexes. This information is generally not known,
... especially not by the page writer. You can't assume that you have
access to the relation descriptor ---
BTW, seems to be holding up pretty well so far, but I've also reduced, by
half, the baner ads on archives, so its not being hit near as much as it
used to be ...
du 17144
656217144
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
You say
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Are you using default values for autovacuum? Could you prove a little
more detail by setting pg_autovacuum debug with -d 2
Sure ... just restarted it with that setup ... btw ... I'm using -L for
logging ... what is the usual way of gettin git to go
On Thu, Sep 30, 2004 at 04:57:37PM -0500, Jim C. Nasby wrote:
> Heh, I was about to ask for the pages with dead tuples list to be added
> to the TODO, but it seems it's already there ('Maintain a map of
> recently-expired rows'). One thing that isn't there which I remember
> being discussed was ha
Zhenchang Xing wrote:
is it possible to output the branches before the detection of infinite
recursion when using connectby()?
It is possible if you patch the distributed source ;-)
Not heavily tested, but the attached patch against 7.4 seems to do the
trick for me. I'm not really sure I'd want t
While trying to fix a problem for David Fetter, I found this rather
obscure plperl bug. It occurs, I think, in these 2 lines in
plperl.c::plperl_get_elem():
if (hv_exists_ent(hash, eval_pv(key, TRUE), FALSE))
svp = hv_fetch(hash, key, strlen(key), FALSE);
This works except where key is
Tom Lane wrote:
I've been thinking more about Gaetano Mendola's report of a
FlushRelationBuffers failure during VACUUM FULL. I still don't see how
that could happen in 7.4, but I do see a real related risk in 8.0.
Just another information that could help your analysis.
The index's parent is a tabl
To answer Simon's earlier comment about if I was looking to start
hacking on PostgreSQL... I'm not. :) I might take a look at the TODO
again, but I seem to do a great job of finding things to put on my plate
as it is. I am interested in minimizing the impact of vacuum, which is
why I brought my ide
I've been getting some more flak lately about fixing the RPM-supplied
init scripts to avoid the problem where the postmaster fails to start
because there's a stale lockfile in the data directory. See for
instance https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134090
but it's hardly the first
On Thu, 30 Sep 2004, Tom Lane wrote:
> Date: Thu, 30 Sep 2004 16:36:02 -0400
>
> "Serguei A. Mokhov" <[EMAIL PROTECTED]> writes:
> > Comments are very welcome, especially _*CONSTRUCTIVE*_...
>
> This is fundamentally wrong, because you are assigning the storage
> manager functionality that it does
I posted a message to pgsql-hackers-win32 regarding a problem with libpq
exports on Win32 the other day, but have yet to receive any replies.
Magnus & I have discussed the problem over IM and we both believe it is
important to fix, but neither of us are fluent enough in make-ese to do
so.
Basicall
Greg Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
template1=# update baz set test = test--3;
template1-#
Here this system does not pick up the semi colon. I have to enter a second
semi colon to get the update to happen.
Everything after a -- to the end of a line is a comment in SQL.
Tried to install this on AIX 5.1, no luck (compiles fine without
--enable-thread-safety though) .
AIX 5.1
gcc 3.3.2
./configure --prefix=/opt/dbs/pgsql800b3-AIX51-2004-09-30
--with-includes=/opt/dbs/readline-5-AIX51-2004-09-29/include:/opt/dbs/zlib-121-AIX51-2004-09-29/include:/opt/dbs/gdb-621-
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Machine details:
> Solaris / 2.8
> regression diffs:
> *** ./expected/cube.out Tue Sep 28 15:25:33 2004
> --- ./results/cube.outTue Sep 28 15:55:16 2004
> ***
> *** 142,148
> SELECT '-1e-700'::cube AS cube;
>cube
>
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> template1=# update baz set test = test--3;
> template1-#
>
> Here this system does not pick up the semi colon. I have to enter a second
> semi colon to get the update to happen.
Everything after a -- to the end of a line is a comment in SQL.
--
g
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Or do you mean here?
>
> Both, but the multi-line case with two different indent levels is
> particularly strange.
>
> You're right that this particular code is new in 8.0. (Looks around...)
> struct f_smgr in smgr.c is a comparable
hi,
is it possible to output the branches before the detection of infinite
recursion when using connectby()? My work is about software evolution
analysis. One of the questions i am interested in is class usage. For
example, class A uses B, B uses C, C uses D, and finally D uses A. I know
conne
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> template1=# update baz set test = test--3;
> template1-#
> Here this system does not pick up the semi colon.
-- introduces a rest-of-the-line comment, per SQL standard.
regards, tom lane
---(end of b
Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
You say it's "*very* busy" is it possible there are hundreds or thousands of
tuples in there that are uncommitted or committed after this query starts?
More specifically, I bet there's a huge number of completely empty
pages, which woul
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Or do you mean here?
Both, but the multi-line case with two different indent levels is
particularly strange.
You're right that this particular code is new in 8.0. (Looks around...)
struct f_smgr in smgr.c is a comparable case, and it seems to have been
"Serguei A. Mokhov" <[EMAIL PROTECTED]> writes:
> Comments are very welcome, especially _*CONSTRUCTIVE*_...
This is fundamentally wrong, because you are assigning the storage
manager functionality that it does not have. In particular, the
storage manager knows nothing of the contents or format of
Greg Stark wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Its a *very* busy table ... and running on a 7.4.0 database ...
I wonder how many tuples are really in this table. Almost all of the 190ms is
spent in the two sequential scans of it. Which is an awful lot of time for a
32 tupl
Tom Lane wrote:
> I noticed that pgindent is doing weird things with function pointer
> declarations; see for example what it did with AnalyzeAttrFetchFunc
> and compute_stats in src/include/commands/vacuum.h. I don't recall
> that it was doing this before the latest run.
Or do you mean here?
Hello,
Consider:
template1=# create table baz (test numeric);
CREATE TABLE
template1=# insert into baz values (5);
INSERT 17259 1
template1=# insert into baz values (5);
INSERT 17260 1
template1=# insert into baz values (5);
INSERT 17261 1
template1=# insert into baz values (5);
INSERT 17262 1
temp
Tom Lane wrote:
> I noticed that pgindent is doing weird things with function pointer
> declarations; see for example what it did with AnalyzeAttrFetchFunc
> and compute_stats in src/include/commands/vacuum.h. I don't recall
> that it was doing this before the latest run.
You mean here?
void
On Thu, 30 Sep 2004, Tom Lane wrote:
Greg Stark <[EMAIL PROTECTED]> writes:
You say it's "*very* busy" is it possible there are hundreds or thousands of
tuples in there that are uncommitted or committed after this query starts?
More specifically, I bet there's a huge number of completely empty
page
I've been thinking more about Gaetano Mendola's report of a
FlushRelationBuffers failure during VACUUM FULL. I still don't see how
that could happen in 7.4, but I do see a real related risk in 8.0.
The problem is that in many situations we assume that a lock on an
index's parent table is sufficien
Hello dear all,
[Please CC your replies to me as I am on the digest mode]
Here's finally a very high-level design proposal of the pg_upgrade feature
I was handwaiving a couple of weeks ago. Since, I am almost done with the
moving, I can allocate some time for this for 8.1/8.2.
If this topic is o
Joe Conway <[EMAIL PROTECTED]> writes:
> I have been trying to troubleshoot a PL/R related issue on-and-off for a
> few weeks now, but this morning ran into what appears to be a more
> general issue related to 7.4.5 on x86_64. A full backtrace is below, and
> in it you can see that PL/R is never
Greg Stark <[EMAIL PROTECTED]> writes:
> You say it's "*very* busy" is it possible there are hundreds or thousands of
> tuples in there that are uncommitted or committed after this query starts?
More specifically, I bet there's a huge number of completely empty
pages, which would be read by a seqs
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
I'm running postgres 7.4.5 on a linux box, this morning I got this error on my logs:
WARNING: FlushRelationBuffers("exp_provider", 1836): block 1460 is referenced
(private 0, global 1)
ERROR: FlushRelationBuffers returned -2
Info for
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Its a *very* busy table ... and running on a 7.4.0 database ...
I wonder how many tuples are really in this table. Almost all of the 190ms is
spent in the two sequential scans of it. Which is an awful lot of time for a
32 tuple table.
You say it'
I have been trying to troubleshoot a PL/R related issue on-and-off for a
few weeks now, but this morning ran into what appears to be a more
general issue related to 7.4.5 on x86_64. A full backtrace is below, and
in it you can see that PL/R is never reached (but PL/pgSQL is). What is
really odd
Josh asked me to post this, since it was just "odd" ... I have
pg_autovacuum running on the table, with output looking for it looking
like:
[2004-09-30 02:29:47 PM] Performing: VACUUM ANALYZE "public"."shown"
[2004-09-30 02:35:11 PM] Performing: ANALYZE "public"."shown"
[2004-09-30 02:40:22 PM]
I noticed that pgindent is doing weird things with function pointer
declarations; see for example what it did with AnalyzeAttrFetchFunc
and compute_stats in src/include/commands/vacuum.h. I don't recall
that it was doing this before the latest run.
regards, tom lane
-
Jan Wieck wrote:
> Any chance for bad memory?
>
I'll say near 0. However who never knows ? Now the server is again up and
running without glitches.
I suspect a race condition somewhere for the reindex operation.
I had with the engine 7.3 ( see in the archives ) a duplicate error during
reindexes at
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> I'm running postgres 7.4.5 on a linux box, this morning I got this error on my logs:
> WARNING: FlushRelationBuffers("exp_provider", 1836): block 1460 is referenced
> (private 0, global 1)
> ERROR: FlushRelationBuffers returned -2
> Info for hacker
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> This error can easily be solved by adding an #include to
> src/port/isinf.c
Done.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with th
Another error caught by the buildfarm
hostname = aix-ppc
uname -m = 24719100
uname -r = 3
uname -s = AIX
uname -v = 4
/usr/bin/oslevel = 4.3.3.0
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/local/bin
Using GNU make found at /usr/local/bin/gmake
/usr/local/bin/gmake -C doc all
gmake[1]
Any chance for bad memory?
Jan
On 9/30/2004 6:16 AM, Gaetano Mendola wrote:
Hi all,
I'm running postgres 7.4.5 on a linux box, this morning I got this error on my logs:
WARNING: FlushRelationBuffers("exp_provider", 1836): block 1460 is referenced
(private 0, global 1)
ERROR: FlushRelationBuffers
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Here is the actual query:
> select lock_cuid(id), *
> ...
> order by wcl_vin_no, wcl_claim_no, id
> limit 1
Looks like Stephan made the right guess.
Logically the LIMIT executes after the ORDER BY, so the sorted result
has to be formed co
Stephan Szabo wrote:
> On Thu, 30 Sep 2004, Merlin Moncure wrote:
>
> > OK, I have a situation that might be a performance problem, a bug,
or an
> > unavoidable consequence of using prepared statements. The short
version
> > is that I am getting function executions for rows not returned in a
> >
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> now, if ps ends up using a index scan on t, everything is ok. However,
> if ps does a seqscan, f executes for every row on t examined until the
> [expr] criteria is met. Is this a bug?
Works for me.
regression=# create function f(int) returns int a
On Thu, 30 Sep 2004, Merlin Moncure wrote:
> OK, I have a situation that might be a performance problem, a bug, or an
> unavoidable consequence of using prepared statements. The short version
> is that I am getting function executions for rows not returned in a
> result set when they are in a pr
Hi all,
I'm running postgres 7.4.5 on a linux box, this morning I got this error on my logs:
WARNING: FlushRelationBuffers("exp_provider", 1836): block 1460 is referenced
(private 0, global 1)
ERROR: FlushRelationBuffers returned -2
DEBUG: AbortCurrentTransaction
PANIC: cannot abort transactio
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> The patch adds a new make target ("profile-opt") that does the PGO
>> steps outlined above -- the "representative input data" is the
>> regression tests running in serial mode. I haven't run any benchmarks
>> yet (if someone wants
> Here's another workaround that may let you use a prepared statement:
>
> prepare ps(...) as
> select f(c) from (select c from t where [expr] limit 1) as t1
>
> -Mike
I was just exploring that. In fact, the problem is not limited to
prepared statements...it's just that they are more likely to
On Thu, Sep 30, 2004 at 09:45:51AM -0400, Merlin Moncure wrote:
> Now, if the same query is executed as a prepared statement,
> prepare ps(...) as select f(t.c) from t where [expr] limit 1;
> execute ps;
>
> now, if ps ends up using a index scan on t, everything is ok. However,
> if ps does a seq
OK, I have a situation that might be a performance problem, a bug, or an
unavoidable consequence of using prepared statements. The short version
is that I am getting function executions for rows not returned in a
result set when they are in a prepared statement.
In other words, I have a query:
se
> The name max_locks_per_transaction indicates a limit of some kind. The
> documentation doesn't mention anything about whether that limit is
> enforced
> or not.
>
> I suggest the additional wording:
> "This parameter is not a hard limit: No limit is enforced on the
number of
> locks in each tran
Hi,
I'm working on a new product for PostgreSQL (description below) and I'm
looking for 5 to 10 Mac users who might be interested in beta testing.
The first release will be for Mac OS X 10.2 or later. A Windows version
will follow, most likely in November. Drop me an email if you can spare
a li
On Thu, Sep 30, 2004 at 07:07:27PM +1000, Neil Conway wrote:
> I think it would be cool to add support for PGO to PostgreSQL's build
> system (for 8.1). There are a lot of situations where PostgreSQL is
> compiled once, and then used for weeks or months (compilations for
> inclusion in a distro b
On Thu, 2004-09-30 at 19:49, Peter Eisentraut wrote:
> I doubt that the regression tests are anywhere near representative input
> data. They run a proportion of borderline and error cases that is much
> higher than I would expect in normal use.
That's definitely true. At first glance, the regre
Neil Conway wrote:
> The patch adds a new make target ("profile-opt") that does the PGO
> steps outlined above -- the "representative input data" is the
> regression tests running in serial mode. I haven't run any benchmarks
> yet (if someone wants to try that, I'd be very curious to see the
> resu
Profile-guided optimization is a relatively new GCC feature that
improves the quality of generated code by:
- compiling a copy of the source program with some profiling hooks
- running this copy of the program on some representative input data
- recompiling the program using the profiling data pro
>Tom Lane
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Does this mean that the parameter max_locks_per_transaction
> isn't honoured
> > at all, it is just used to size the lock table
>
> Yes, and that's how it's documented.
>
The name max_locks_per_transaction indicates a limit of some kind. Th
63 matches
Mail list logo
