Hi,
On Wed, Feb 4, 2009 at 4:17 PM, K, Niranjan (NSN - IN/Bangalore)
niranja...@nsn.com wrote:
Thanks for the response.
I tried with the your sources and found the same issue.
Thanks for the retesting!
Could you please help. If you need any more symptoms, I can re-work.
May I ask you some
Hi,
Thanks for the response.
I tried with the your sources and found the same issue.
I explain the steps that I followed, just to avoid any gaps in
understanding.
1) I assumes that the patch was already applied in your sources. So did
went ahead doing configure, make and make install
2) Built
On Tue, Feb 03, 2009 at 04:06:39PM -0300, Alvaro Herrera wrote:
Note that spoonbill is still red. This animal is special because it
uses some peculiar malloc flags.
Not just spoonbill, five of them are. Without access to a failing machine this
is difficult to debug. I found some missing error
- Do you use a packet filtering software (eg. firewall)?
If yes, what happens if you disabled such a software?
Firewall was disabled
- Do you use SELinux?
If yes, what happens if you disabled SELinux?
SELinux is disabled.
- Please run the following commands and report those results.
On Wed, 2009-02-04 at 14:42 +0800, Don Marvick wrote:
4. any other issue needs consideration?
Most attempts to improve sorting further have fallen to nothing because
of the lack of repeatable test results. In particular, coming up with
test cases *after* writing the code is a good way to get
Svenne Krap wrote:
Rick Vernam wrote:
The reference documentation is *always* intended to be more complete and
more authoritative than the narrative description. If you don't think
so then you need to readjust your expectations.
very well, I did not know that.
expectations
I wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Can you let it run to completion? Without explain analyze results
it's going to be pretty difficult to isolate the problem.
Barring some currently unforseen need to switch it into service to
back the web site, yes.
It's been about 23 hours
On Wed, 2009-02-04 at 10:55 +, Greg Stark wrote:
Is this basically the same as our current algorithm but without
multiplexing the tapes onto single files? I have been wondering
whether we multiplex the tapes any better than filesystems can lay out
separate files actually.
I don't think
On Wed, Feb 4, 2009 at 3:07 PM, Kevin Grittner
It's been about 23 hours and it's still running.
@snide(Gee, it sure would be nice if we continued with that
explain-in-progress patch I had sent in earlier...:)
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Greg Stark st...@enterprisedb.com writes:
Is this basically the same as our current algorithm but without
multiplexing the tapes onto single files? I have been wondering
whether we multiplex the tapes any better than filesystems can lay out
separate files actually.
The reason for the
On Wed, Feb 4, 2009 at 10:12 AM, Greg Stark st...@enterprisedb.com wrote:
On Wed, Feb 4, 2009 at 3:07 PM, Kevin Grittner
It's been about 23 hours and it's still running.
@snide(Gee, it sure would be nice if we continued with that
explain-in-progress patch I had sent in earlier...:)
Don Marvick donmarv...@gmail.com writes:
Since nobody replied, I would give it a try. I am going to implement the
merge pattern described in Knuth Page 365 (5.4.9), essentially it is as
follow:
- create initial runs using replacement selection (basically this is as in
the current
On Wednesday 04 February 2009 8:41:55 am Svenne Krap wrote:
Andrew Dunstan wrote:
Me neither. I wonder how many other long term users (I have used pgsql
for more than a decade - 6.2 was my first version if memory serves)
and have never caught that nuance either.
Maybe that should be
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2009-02-04 at 10:55 +, Greg Stark wrote:
Is this basically the same as our current algorithm but without
multiplexing the tapes onto single files? I have been wondering
whether we multiplex the tapes any better than filesystems can lay out
Kevin Grittner kevin.gritt...@wicourts.gov writes:
It's been about 23 hours and it's still running. No apparent memory
leakage. No significant disk activity. One CPU pegged (of the 16 on
the machine).
Hmmm ... I wonder if it could be stuck in an infinite loop? It's
probably just a horribly
Tom Lane t...@sss.pgh.pa.us wrote:
If you can attach to the backend with gdb, try bt, then cont,
then wait a few seconds, then control-C and bt again. Repeat
five or ten times and see if there's any consistency to the traces.
Attached.
-Kevin
kgri...@athena:~ gdb
Bruce Momjian wrote:
The fundamental behavior above is that the S1 transaction is adding
_and_ removing rows from the S2 query's result set; S2 is seeing the
pre-query values that don't match its criteria and ignoring them and
blocking on a later row that does match its criteria. Once S1
Fujii Masao wrote:
On Fri, Jan 30, 2009 at 11:55 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The startup process now catches SIGTERM, and calls proc_exit() at the next
WAL record. That's what will happen in a fast shutdown. Unexpected death of
the startup process is
Andrew Dunstan wrote:
Me neither. I wonder how many other long term users (I have used pgsql
for more than a decade - 6.2 was my first version if memory serves)
and have never caught that nuance either.
Maybe that should be printed as a note on the narrative description
pages.. something
Bruce Momjian br...@momjian.us wrote:
Well, with no one replying, :-(, I went ahead and added to the Read
Committed section of our manual to show a simple case where our read
committed mode produces undesirable results. I also did a little
cleanup at the same time.
You can see the
Is this basically the same as our current algorithm but without
multiplexing the tapes onto single files? I have been wondering
whether we multiplex the tapes any better than filesystems can lay out
separate files actually.
Or is there something else that's different here?
--
greg
--
Sent via
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
If you can attach to the backend with gdb, try bt, then cont,
then wait a few seconds, then control-C and bt again. Repeat
five or ten times and see if there's any consistency to the traces.
Attached.
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
Well, with no one replying, :-(, I went ahead and added to the Read
Committed section of our manual to show a simple case where our read
committed mode produces undesirable results. I also did a little
cleanup at the same time.
Tom Lane t...@sss.pgh.pa.us wrote:
SELECT ... FROM CaseDispo CD
WHERE (NOT (EXISTS
(
SELECT
1
FROM
CaseDispo CD2
WHERE (
(CD2.caseNo = CD.caseNo)
AND (CD2.countyNo = CD.countyNo)
AND (CD2.dispoDate CD.dispoDate))
)))
which in fact the planner thought would be pretty expensive;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rick Vernam wrote:
The reference documentation is *always* intended to be more complete and
more authoritative than the narrative description. If you don't think
so then you need to readjust your expectations.
very well, I did not know that.
I looked at this a little bit --- it needs proofreading (VACUUME?).
Sorry, VACUUME fixed
Do we really need an additional column in pgstat table entries in
order to store something that looks like it can be derived from the
other columns? The stats tables are way too big already.
It's not
Simon Riggs wrote:
* I think we are now renaming the recovery.conf file too early. The
comment says We have already restored all the WAL segments we need from
the archive, and we trust that they are not going to go away even if we
crash. We have, but the files overwrite each other as they
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Well, of the cases which are selected based on the other criteria,
there would be about one CaseDispo row each. The main selection
criterion is the Party.searchName, with various security limitations
added. Where one or more CaseDispo rows
Tom Lane t...@sss.pgh.pa.us wrote:
there's some sort of logic bug here someplace.
Keep in mind that this is running with the patch that started this
thread. I didn't try actually running this query on 8.4devel without
the patch. Should I kill this query, revert the software to
pre-patch,
On Feb 4, 2009, at 5:25 AM, Andrew Dunstan wrote:
In effect it does say that - perhaps not quite as explicitly as you
might have wanted. It says: The information in this part is
presented in a narrative fashion in topical units. Readers looking
for a complete description of a particular
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
there's some sort of logic bug here someplace.
Keep in mind that this is running with the patch that started this
thread. I didn't try actually running this query on 8.4devel without
the patch. Should I
Looked at this a bit ... do you think it's really a good idea to remove
the strategy number argument of comparePartial? The argument given in
the docs for it is that it might be needed to determine when to end the
scan, and that still seems plausible to me.
Strategy number is not removed, it's
On Wed, Feb 4, 2009 at 12:15 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
there's some sort of logic bug here someplace.
Keep in mind that this is running with the patch that started this
thread. I didn't try actually running this query on 8.4devel
On Feb 4, 2009, at 9:25 AM, Robert Haas wrote:
Oh, dear. If this turns out to be my bug Tom will kick my ass!
Can I buy tickets to this event?
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Feb 4, 2009 at 12:22 PM, David E. Wheeler da...@kineticode.com wrote:
In effect it does say that - perhaps not quite as explicitly as you might
have wanted. It says: The information in this part is presented in a
narrative fashion in topical units. Readers looking for a complete
Tom Lane t...@sss.pgh.pa.us wrote:
It would be worth checking whether you get the same plan without
the patch (you should, but let's check).
Same plan.
(Robert can relax, and David can forget about those tickets.)
-Kevin
--
Sent via pgsql-hackers mailing list
Robert Haas robertmh...@gmail.com writes:
Oh, dear. If this turns out to be my bug Tom will kick my ass!
Hmm ... one of the things that struck me as odd was that it was doing a
merge join on just the countyNo, which is presumably very far from
unique. Testing the query here with Kevin's schema
Jeff Davis wrote:
On Wed, 2009-02-04 at 11:11 -0500, Bruce Momjian wrote:
Well, with no one replying, :-(, I went ahead and added to the Read
Committed section of our manual to show a simple case where our read
committed mode produces undesirable results. I also did a little
cleanup at
On Wed, 2009-02-04 at 11:11 -0500, Bruce Momjian wrote:
Well, with no one replying, :-(, I went ahead and added to the Read
Committed section of our manual to show a simple case where our read
committed mode produces undesirable results. I also did a little
cleanup at the same time.
We could
On Feb 4, 2009, at 9:33 AM, Robert Haas wrote:
Just to play devil's advocate, I have used the PostgreSQL
documentation for years and have long understood that the references
pages are the place to go if you really need the nitty-gritty on how a
particular command works. I agree that you might
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
It would be worth checking whether you get the same plan without
the patch (you should, but let's check).
Same plan.
Yeah, I just managed to reproduce a similar behavior in unpatched HEAD.
Now, since I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David E. Wheeler wrote:
I think that all pages that seem to document particular features
should cross-reference the reference pages in section VI, but not
necessarily vice-versa. I don't think that's asking for a lot. If
you're reading the
Tom Lane t...@sss.pgh.pa.us wrote:
Hmm ... one of the things that struck me as odd was that it was doing
a
merge join on just the countyNo, which is presumably very far from
unique.
There are 72 possible values for any columns in that domain. In most
large tables, Milwaukee County (value
Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
Noticed another issue with 'client only' type installs in the
Makefile. Shouldn't make install on libpq install postgres_ext.h in
addition to the interface headers?
I don't think libpq's Makefile has any business doing that.
On Wed, 2009-02-04 at 19:03 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
* I think we are now renaming the recovery.conf file too early. The
comment says We have already restored all the WAL segments we need from
the archive, and we trust that they are not going to go away even if
Robert Treat wrote:
On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
Alvaro Herrera wrote:
Robert Treat wrote:
On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
David Fetter wrote:
Ref: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00198.php
Robert Haas wrote:
2009/1/10 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
Uh, is this ready to be applied?
I don't think any consensus has been reached on changing this behavior.
I thing, so this is bug - RETURN QUERY has to supply FOR SELECT LOOP
RETURN
On Mon, 2009-02-02 at 20:38 -0500, Tom Lane wrote:
Also, I really think it's a pretty bad idea to make index cost
estimation depend on the current state of the index's pending list
--- that state seems far too transient to base plan choices on.
I'm confused by this. Don't we want to base the
I wrote:
Now, since I'm running without any stats, it might be that it's
estimating similar costs for the one-key and two-key merges; but I don't
see why that would happen for you. Off to do some debugging.
... well, actually, it's because I blew off applying any cost correction
for this case
On Feb 4, 2009, at 10:04 AM, Svenne Krap wrote:
I have the same experience, I also go directly for the most technical
parts. But even I sometimes search and hit those narrative ones
Btw. there seems to be no section VI (i.e. non-narrative) page about
datatypes and functions... things there
Tom Lane t...@sss.pgh.pa.us wrote:
That doesn't seem to be the only issue in your example, but it's
definitely one of 'em.
FWIW, the pattern causing the problem here is a pretty common one in
court business logic: join (often outer join or an exists test) to a
set of candidate rows WHERE NOT
On Wed, Feb 4, 2009 at 12:33 PM, Robert Haas robertmh...@gmail.com wrote:
Still, the queries-limit.html page includes this statement: OFFSET 0
is the same as omitting the OFFSET clause. I don't see that there
would be anything bad or confusing about changing it to read this way:
OFFSET 0 is
Hi,
indices.sgml contains this paragraph about hash indexes:
Note: Testing has shown PostgreSQL's hash indexes to perform no
better than B-tree indexes, and the index size and build time for hash
indexes is much worse. Furthermore, hash index operations are not
presently WAL-logged, so
Tom Lane wrote:
The proximate cause of this complaint:
http://archives.postgresql.org/pgsql-general/2008-12/msg00283.php
seems to be that the polymorphic-type code doesn't consider a domain
over an enum type to match an ANYENUM function argument.
ISTM this is probably wrong: we need such a
On Wed, Feb 4, 2009 at 1:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
Noticed another issue with 'client only' type installs in the
Makefile. Shouldn't make install on libpq install postgres_ext.h in
addition to the interface
On Wed, Feb 4, 2009 at 1:39 PM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2009-02-02 at 20:38 -0500, Tom Lane wrote:
Also, I really think it's a pretty bad idea to make index cost
estimation depend on the current state of the index's pending list
--- that state seems far too transient to
On Wed, Feb 4, 2009 at 1:32 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
2009/1/10 Tom Lane t...@sss.pgh.pa.us:
Bruce Momjian br...@momjian.us writes:
Uh, is this ready to be applied?
I don't think any consensus has been reached on changing this behavior.
I thing,
Robert Haas wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data types
Simon Riggs wrote:
On Tue, 2009-01-06 at 09:44 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
It looks to me that generating a single error message while idle causes
the server to provide ErrorResponse, which the client assumes is the end
of the processing of that
I had submitted the documentation change as part of my
hash function patch but it was removed as not relevant.
(It wasn't really.) I would basically remove the first
sentence:
Note: Hash index operations are not presently WAL-logged,
so hash indexes might need to be rebuilt with REINDEX
On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
Well, there's nothing to force that plan to be invalidated when the
state of the pending list changes, is there?
Would it be unreasonable to invalidate cached plans during the pending
list cleanup?
Anyway, it just strikes me as strange to
On Wed, Feb 4, 2009 at 4:23 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
Well, there's nothing to force that plan to be invalidated when the
state of the pending list changes, is there?
Would it be unreasonable to invalidate cached plans
Hi.
Is it in todo or in a plan to implement lmza commpression in pg_dump
backups?
Thanks
Stano
--
Mgr.
Stano LACKO
mobil:
+421 908 175 753
fax.:
+421 2 555 72 676
e-mail: lacko@spacesystems.sk
On Wed, Feb 04, 2009 at 01:23:04PM -0500, Bruce Momjian wrote:
Robert Treat wrote:
On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
Alvaro Herrera wrote:
Robert Treat wrote:
On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
David Fetter wrote:
Ref:
On Wed, 2009-02-04 at 14:53 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Tue, 2009-01-06 at 09:44 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
It looks to me that generating a single error message while idle causes
the server to provide ErrorResponse,
The main speed improvement is for varchar datatype. I think It should be
mention here as well. IIRC, times are similar with B-Tree for integer
datatype.
Zdenek
Kenneth Marshall píše v st 04. 02. 2009 v 13:57 -0600:
I had submitted the documentation change as part of my
hash function
On Wed, Feb 4, 2009 at 1:23 PM, Bruce Momjian br...@momjian.us wrote:
Robert Treat wrote:
On Wednesday 21 January 2009 20:21:41 Bruce Momjian wrote:
Alvaro Herrera wrote:
Robert Treat wrote:
On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
David Fetter wrote:
Ref:
Stanislav Lacko wrote:
Hi.
Is it in todo or in a plan to implement lmza commpression in pg_dump
backups?
Nope, never heard anything about it.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Bruce Momjian
Sent: Wednesday, February 04, 2009 3:28 PM
To: Stanislav Lacko
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Is a plan for lmza commpression
On Wed, Feb 04, 2009 at 11:22:44PM +0100, Zdenek Kotala wrote:
The main speed improvement is for varchar datatype. I think It should be
mention here as well. IIRC, times are similar with B-Tree for integer
datatype.
Zdenek
Kenneth Marshall pe v st 04. 02. 2009 v 13:57 -0600:
I
Hi,
On Wed, Feb 4, 2009 at 8:35 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yes, and in fact I ran into it myself yesterday while testing. It seems that
we should reset FatalError earlier, ie. when the recovery starts and
bgwriter is launched. I'm not sure why we in CVS
Good point. I would note this issue. Thanks for the advice :).
Regards,
Don
On Wed, Feb 4, 2009 at 6:09 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2009-02-04 at 14:42 +0800, Don Marvick wrote:
4. any other issue needs consideration?
Most attempts to improve sorting further
This is what I understand from existing implementation:
- fix the merge fan in F, and number of tapes=F+1
- for each sorted run generated, we have a formula to determine which tape
it belongs to
- the sorted run is added to the end of the tape
- all sorted runs have been added to tape. There is
Hmm probably it's worth to try this. Has anybody try this before? If not, I
am interested to give it a try.
Regards,
Don
On Wed, Feb 4, 2009 at 11:25 PM, Gregory Stark st...@enterprisedb.comwrote:
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2009-02-04 at 10:55 +, Greg Stark
Dann Corbit wrote:
The LZMA SDK is granted to the public domain:
http://www.7-zip.org/sdk.html
I played with this but found the SDK extremely confusing and flat out horrible.
One personal dislike was the unnecessary use of C++; although it was the
horrible API that turned me off. I'm not
2009/2/5 Bruce Momjian br...@momjian.us:
Robert Haas wrote:
I am not thrilled about inventing a new column for this, but how about
a display like so:
regression=# \df nth_value
List of functions
Schema | Name| Result data type | Argument data
Hi Niranjan,
On Wed, Feb 4, 2009 at 6:21 PM, K, Niranjan (NSN - IN/Bangalore)
niranja...@nsn.com wrote:
- Do you use a packet filtering software (eg. firewall)?
If yes, what happens if you disabled such a software?
Firewall was disabled
- Do you use SELinux?
If yes, what happens if you
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Feb 4, 2009 at 8:35 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
... I'm not sure why we in CVS HEAD we don't reset
FatalError until after the startup process is finished.
Which may repeat the recovery crash and
Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Feb 4, 2009 at 8:35 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
... I'm not sure why we in CVS HEAD we don't reset
FatalError until after the startup process is finished.
Which may repeat the recovery
Simon Riggs wrote:
We could avoid that by performing a good old startup checkpoint, but I
quite like the fast failover time we get without it.
ISTM it's either slow failover or (fast failover, but restart archive
recovery if crashes).
I would suggest that at end of recovery we write the last
On Thu, 2009-02-05 at 09:28 +0200, Heikki Linnakangas wrote:
I've changed the way minRecoveryPoint is updated now anyway, so it no
longer happens every XLogFileRead().
Care to elucidate?
I got rid of minSafeStartPoint, advancing minRecoveryPoint instead. And
it's advanced in
On Thu, 2009-02-05 at 09:28 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
We could avoid that by performing a good old startup checkpoint, but I
quite like the fast failover time we get without it.
ISTM it's either slow failover or (fast failover, but restart archive
recovery
82 matches
Mail list logo
