gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -
Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -
fwrapv -bundle -multiply_defined suppress regress.o -
bundle_loader ../../../src/backend/postgres -L../../../src/port -o
regress.so
cp
PFA. This file is to be kept in 'pgsql_init' base directory.
On Tue, Jun 9, 2009 at 12:54 PM, Grzegorz Jaskiewicz
g...@pointblue.com.plwrote:
gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
-bundle
Floris Bos / Maxnet wrote:
I am having the problem that some queries are unable to find rows when
using the index.
When I force a sequential scan, by doing set enable_indexscan=false;
set enable_bitmapscan=false;, the same queries work fine.
Not a hacker myself, but I can tell you that the
And can you post an explain plan for the incorrect scan? In particular
is it using a bitmap index scan or a regular index scan? Or does it
happen with either?
--
Greg
On 9 Jun 2009, at 09:43, Richard Huxton d...@archonet.com wrote:
Floris Bos / Maxnet wrote:
I am having the problem
Hi,
The patch automates table partitioning to support Range and Hash
partitions. Please refer to attached readme file for further details.
The syntax used conforms to most of the suggestions mentioned in
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring
the
still doesn't work:
make[1]: Leaving directory `/home/gjaskie/Projects/postgres/pgsql/config'
/home/gjaskie/Projects/postgres/pgsql/partition.sh: line 14: a.keyorder,:
command not found
/home/gjaskie/Projects/postgres/pgsql/partition.sh: line 15: where: command not
found
: command not
Hi,
Richard Huxton wrote:
Not a hacker myself, but I can tell you that the first question you'll
be asked is can you produce a test case? If you can generate the
problem from a test table+generated data that will let people figure out
the problem for you.
Unfortunately, I have not been able
I did a fresh checkout and applied patch and added files and it works at my
end.
Is there any problem with formatting of the file? May be some
characters('\') missing in conversion?
On Tue, Jun 9, 2009 at 4:14 PM, gj g...@pointblue.com.pl wrote:
still doesn't work:
make[1]: Leaving directory
Floris Bos / Maxnet b...@je-eigen-domein.nl writes:
Richard Huxton wrote:
Not a hacker myself, but I can tell you that the first question you'll
be asked is can you produce a test case? If you can generate the
problem from a test table+generated data that will let people figure out
the
On Tue, 9 Jun 2009 at 13:52:08, Kedar Potdar wrote:
I did a fresh checkout and applied patch and added files and it works at my
end.
Is there any problem with formatting of the file? May be some
characters('\') missing in conversion?
For one, I think you should put it around in quotes,
Joe Conway m...@joeconway.com writes:
I think the attached is what you had in mind. But I don't know right off
how to trigger the failure (and therefore how to test the solution). A
naive test with two databases, one LATIN2, the other UTF8 does not
produce the error with simple text
A couple of people in recent years have had a problem with page X is
uninitialised -- fixing messages.
I have a case now with 569357 consecutive pages that required fixing in
pg_attribute. We looked at pages by hand and they really are
uninitialised, but otherwise what we would expect for size,
Building 8.4beta2 on my AIX test machine works fine,
but when I set listen_addresses = '*' in postgresql.conf,
the server fails to start.
This is what I get:
LOG: 0: could not translate service 5432 to address: Hostname and
service name not provided or found
LOCATION: StreamServerPort,
On Tue, 2009-06-09 at 13:40 +0200, Floris Bos / Maxnet wrote:
fsync = off
That's a bad plan if you care about your database.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Mark Kirkwood mark.kirkw...@catalyst.net.nz writes:
A construction of the form
DECLARE cur CURSOR WITH HOLD FOR SELECT * FROM obj
loop
FETCH 1000 FROM cur
process 'em
COMMIT
results in some of the same rows being emitted more than once, altho the
final rowcount is correct
* Simon Riggs:
On Tue, 2009-06-09 at 13:40 +0200, Floris Bos / Maxnet wrote:
fsync = off
That's a bad plan if you care about your database.
It shouldn't introduce this type of corruption, though.
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH
Hi,
Simon Riggs wrote:
On Tue, 2009-06-09 at 13:40 +0200, Floris Bos / Maxnet wrote:
fsync = off
That's a bad plan if you care about your database.
I am aware of the risk of dataloss in case of power failure, etc.
However fsync=on is simply too slow for my purpose, and it concerns data
I noticed the following core-dump situation in CVS HEAD:
regression=# select array_agg_finalfn(null);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost.
Tom Lane wrote:
Please get this committed soon, we have other stuff to get done
(like a pgindent run).
Thanks -- committed.
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Normally we would consider a pg_proc change as requiring a catversion
bump. Since we are already past 8.4 beta we couldn't do that without
forcing an initdb for beta testers.
I think a serious issue like this warrants a bump. It seems like
On Tue, Jun 9, 2009 at 11:31 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Normally we would consider a pg_proc change as requiring a catversion
bump. Since we are already past 8.4 beta we couldn't do that without
forcing an initdb for beta testers. What I'd like to do about this
is change the
Well sure it could -- once. It wouldn't be reproducible in a freshly
rebuilt index unless he's crashing his machine every time.
--
Greg
On 9 Jun 2009, at 17:12, Florian Weimer fwei...@bfk.de wrote:
* Simon Riggs:
On Tue, 2009-06-09 at 13:40 +0200, Floris Bos / Maxnet wrote:
fsync =
Jaime Casanova jcasa...@systemguards.com.ec writes:
why not bump it just at the final release.
There aren't going to be any more betas, so it's now or not at all.
I don't think we want to plan a catversion bump between RC and final.
regards, tom lane
--
Sent via
Floris,
The website this setup is for has been running various previous versions
of PostgreSQL with fsync=off since 2005.
So I still expect it to work.
You've been lucky, that's all.
Our documentation has been clear, back to version 7.0, that turning
fsync=off carries the risk that you
Tom Lane wrote:
Normally we would consider a pg_proc change as requiring a catversion
bump. Since we are already past 8.4 beta we couldn't do that without
forcing an initdb for beta testers. What I'd like to do about this
is change the proisstrict settings in pg_proc.h but not bump
* Josh Berkus:
Our documentation has been clear, back to version 7.0, that turning
fsync=off carries the risk that you will have to recreate your entire
database in the event of unexpected shutdown. That's not new.
The documentation does not say this. Instead, there's the following
rather
It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life
On Tue, Jun 9, 2009 at 12:41 PM, Greg Sabino Mullaneg...@turnstep.com wrote:
Normally we would consider a pg_proc change as requiring a catversion
bump. Since we are already past 8.4 beta we couldn't do that without
forcing an initdb for beta testers.
I think a serious issue like this
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lanet...@sss.pgh.pa.us wrote:
The technically best solution is probably similar to what Materialize
nodes do, ie, read the query only once and be careful to stash rows
aside into a tuplestore as they are read. This would fix both issues
with one patch.
Florian Weimer wrote:
* Josh Berkus:
Our documentation has been clear, back to version 7.0, that turning
fsync=off carries the risk that you will have to recreate your entire
database in the event of unexpected shutdown. That's not new.
The documentation does not say this. Instead,
Robert Haas escribió:
I suppose in theory you could try to figure out whether
materialization is really necessary (let's see... no seqscans here and
no volatile functions... ok, so we can cheat...) but that seems
likely to lead to future bugs as the rules for which things are safe
change.
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
This will ensure the fix is in place and protecting future coding,
although possibly not getting enforced in 8.4 production instances that
were upgraded from beta (if there are any such).
How common is this scenario? It's certainly
Robert Haas robertmh...@gmail.com writes:
This seems like the only option that will produce correct answers, so
it gets my vote. How much is the performance penalty for
materializing the tuplestore? I'm inclined to think that whatever it
is, you just have to pay it if you ask for a WITH HOLD
On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
We could probably fix this specific issue by refactoring things in such
a way that the seqscan start point is frozen on the first read and
re-used after rewinds.
I don't know what you mean by frozen exactly, but the start point of a
Alvaro Herrera alvhe...@commandprompt.com wrote:
Yeah, AFAICT the writes are handed off to the operating system (just
not synced), so if it flushes its caches sanely at all there
shouldn't be a problem.
I would certainly *hope* that's the case. We sometimes use fsync=off
for conversions,
On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
We could probably fix this specific issue by refactoring things in such
a way that the seqscan start point is frozen on the first read and
re-used after rewinds.
I don't know what you
Simon Riggs si...@2ndquadrant.com writes:
A couple of people in recent years have had a problem with page X is
uninitialised -- fixing messages.
I have a case now with 569357 consecutive pages that required fixing in
pg_attribute. We looked at pages by hand and they really are
uninitialised,
Alvaro, Kevin,
Yeah, AFAICT the writes are handed off to the operating system (just
not synced), so if it flushes its caches sanely at all there
shouldn't be a problem.
I would certainly *hope* that's the case. We sometimes use fsync=off
for conversions, where we plan to just start over if
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This seems like the only option that will produce correct answers,
so it gets my vote. How much is the performance penalty for
materializing the tuplestore? I'm inclined to think that whatever
it is, you just have
On Tue, Jun 9, 2009 at 1:47 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
This seems like the only option that will produce correct answers, so
it gets my vote. How much is the performance penalty for
materializing the tuplestore? I'm inclined to think that
On Monday 08 June 2009 07:12:33 Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On Sunday 31 May 2009 18:41:55 Tom Lane wrote:
AFAICS, the SQL standard demands that precision and scale fields be
non-null all the time for those data types where they make sense
(this is encoded in
On Tue, Jun 9, 2009 at 1:00 PM, Kevin
Grittnerkevin.gritt...@wicourts.gov wrote:
the same paragraph: The default is to allow scrolling in some cases;
in some cases... like in but not all... ?
this doesn't sound like a vow to me. if the user really wants
SCROLLing ability he should have been
On Tue, 2009-06-09 at 13:54 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
A couple of people in recent years have had a problem with page X is
uninitialised -- fixing messages.
I have a case now with 569357 consecutive pages that required fixing in
pg_attribute. We
Peter Eisentraut pete...@gmx.net writes:
diff --git a/src/backend/catalog/information_schema.sql
b/src/backend/catalog/information_schema.sql
index 9c5672f..cb0296a 100644
--- a/src/backend/catalog/information_schema.sql
+++ b/src/backend/catalog/information_schema.sql
@@ -160,12 +160,12 @@
On Tue, Jun 9, 2009 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
This will ensure the fix is in place and protecting future coding,
although possibly not getting enforced in 8.4 production instances that
were upgraded from
Peter Eisentraut pete...@gmx.net writes:
After gathering that there will probably be some other changes before
release that will require an initdb (even without catversion bump), and
after reexamining the issue, I think it's trivial and uncontroversial to
fix the datetime issues:
For the
Gurjeet Singh singh.gurj...@gmail.com writes:
Can we hold it till 8.4.1? Or is that not an option?
What advantage would that have? We certainly wouldn't wish to put a
catversion change into 8.4.1.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Jeff Davis pg...@j-davis.com writes:
On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
I don't know what you mean by frozen exactly, but the start point of a
synchronized scan is stored in shared memory; otherwise, it wouldn't
know where to stop.
Correction: I didn't actually mean
Greg Sabino Mullane g...@turnstep.com writes:
Normally we would consider a pg_proc change as requiring a catversion
bump. Since we are already past 8.4 beta we couldn't do that without
forcing an initdb for beta testers.
I think a serious issue like this warrants a bump. It seems like you
Josh Berkus j...@agliodbs.com writes:
It doesn't. But what I don't trust, and the *first* place I'd look for
problems, is whether the OS flushes *all* dirty buffers to disk in the
event the application gets killed.
Why wouldn't you trust it? The sort of thing you seem to be thinking
about
Hi,
-Original Message-
From: ext Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, June 09, 2009 1:35 AM
To: Robert Haas
Cc: Greg Stark; Simon Riggs; Fujii Masao; Kolb, Harald (NSN -
DE/Munich); pgsql-hackers@postgresql.org; Czichy, Thoralf
(NSN - FI/Helsinki)
Subject: Re:
Hi,
Josh Berkus wrote:
It doesn't. But what I don't trust, and the *first* place I'd look for
problems, is whether the OS flushes *all* dirty buffers to disk in the
event the application gets killed.
That's why I want more information on Floris' case. Was 8.4 killed or
shut down with -m
On Tue, 2009-06-09 at 20:59 +0200, Kolb, Harald (NSN - DE/Munich) wrote:
There are some good reasons why a switchover could be an appropriate
means in case the DB is facing troubles. It may be that the root cause
is not the DB itsself, but used resources or other things which are
going crazy
Kolb, Harald (NSN - DE/Munich) harald.k...@nsn.com writes:
If you don't want to see this option as a GUC parameter, would it be
acceptable to have it as a new postmaster cmd line option ?
That would make two kluges, not one (we don't do options that are
settable in only one way). And it does
Kolb, Harald (NSN - DE/Munich) harald.k...@nsn.com wrote:
From: ext Tom Lane [mailto:t...@sss.pgh.pa.us]
Mechanism should exist to support useful policy. I don't believe
that the proposed switch has any real-world usefulness.
There are some good reasons why a switchover could be an
Not really since once you fail over you may as well stop the rebuild
since you'll have to restore the whole database. Moreover wouldn't
that have to be a manual decision?
The closest thing I can come to a use case would be if you run a very
large cluster with hundreds of read-only
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Kolb, Harald (NSN - DE/Munich) harald.k...@nsn.com wrote:
There are some good reasons why a switchover could be an appropriate
means in case the DB is facing troubles. It may be that the root
cause is not the DB itsself, but used resources or
Simon Riggs si...@2ndquadrant.com writes:
A couple of people in recent years have had a problem with page X is
uninitialised -- fixing messages.
I have a case now with 569357 consecutive pages that required fixing in
pg_attribute. We looked at pages by hand and they really are
uninitialised,
Albe Laurenz laurenz.a...@wien.gv.at writes:
Building 8.4beta2 on my AIX test machine works fine,
but when I set listen_addresses = '*' in postgresql.conf,
the server fails to start.
I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
peculiarities. What about forgetting the whole
On Tue, 2009-06-09 at 16:17 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
A couple of people in recent years have had a problem with page X is
uninitialised -- fixing messages.
I have a case now with 569357 consecutive pages that required fixing in
pg_attribute. We
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Kolb, Harald (NSN - DE/Munich) harald.k...@nsn.com wrote:
There are some good reasons why a switchover could be an
appropriate means in case the DB is facing troubles. It may be
that the root cause is not
Tom Lane wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Building 8.4beta2 on my AIX test machine works fine,
but when I set listen_addresses = '*' in postgresql.conf,
the server fails to start.
I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
peculiarities. What
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
peculiarities. What about forgetting the whole matter and always
using our src/port/ implementation on that OS?
I'm assuming that the OP has tested that 8.3 works on
Simon Riggs si...@2ndquadrant.com writes:
A corrupt record of a block number would do this in XLogReadBuffer() if
we had full page writes enabled. But it would have to be corrupt between
setting it correctly and the CRC check on the WAL record. Which is a
fairly small window of believability.
On Tue, Jun 9, 2009 at 5:24 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
peculiarities. What about forgetting the whole matter and always
using our src/port/ implementation on
On Tue, 2009-06-09 at 17:28 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
A corrupt record of a block number would do this in XLogReadBuffer() if
we had full page writes enabled. But it would have to be corrupt between
setting it correctly and the CRC check on the WAL
On Tue, 2009-06-09 at 15:48 -0500, Kevin Grittner wrote:
My first reaction on hearing the request was that it might have *some*
use; but in trying to recall any restart where it is what I would have
wanted, I come up dry. I haven't even really come up with a good
hypothetical use case.
On Thursday 28 May 2009 13:31:16 Itagaki Takahiro wrote:
Here is a patch to fix the bug. I added a parameter 'encode' to
map_sql_value_to_xml_value() and pass false for xml attributes.
I have committed your patch with minor editing. Thanks.
--
Sent via pgsql-hackers mailing list
On Sunday 31 May 2009 20:00:44 Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Here is a patch to fix the bug. I added a parameter 'encode' to
map_sql_value_to_xml_value() and pass false for xml attributes.
One thing I was wondering about, which is sort of
Merlin Moncure mmonc...@gmail.com writes:
Tom Lane wrote:
The only serious knock I can see on our implementation is that it lacks
IPv6 support. So we'd not want to use it on AIX versions that are
IPv6-capable. Which are those, if any, and do they have any of these
getaddrinfo issues?
Tom Lane t...@sss.pgh.pa.us writes:
This would be a serious security problem if it weren't for the fact that
nearly all internal-accepting functions in the backend are also marked
STRICT, and so they won't get called in this type of scenario. A query
to pg_proc shows that the only ones that
Sergey Burladyan eshkin...@gmail.com writes:
How about contrib/ ? I have this in my test 8.3.7 database:
That stuff should all be marked strict ... on the whole I'm not sure
that contrib is null-safe anyway, independently of this particular
issue. AFAIK no one's really gone through it.
Bruce Momjian wrote:
It is time to run pgindent on CVS HEAD for 8.4. I am thinking of
running it at zero-hour GMT tomorrow, meaning five hours from now.
Any objections?
I ran pgindent and was concerned enough about the results so I am
posting here rather than applying any changes. I used
Bruce Momjian wrote:
The typedef is coming from the indicated line, and from
/usr/include/sys/stat.h, where there is no typedef for stat. Obviously
Linux or the buildfarm is finding the same issue, but I have no idea
why.
My only guess right now is that we are linking postgres differently
Bruce Momjian br...@momjian.us writes:
I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:
The standard headers do define struct stat. I wonder whether the
objdump kluge we are using is unable to distinguish
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:
The standard headers do define struct stat. I wonder whether the
objdump kluge we are using is
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:
The standard headers do define struct stat. I wonder whether the
objdump kluge we are using is
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?
Do you want me to just run with my old typedef list now and
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?
Do you want me to just run with my
Bruce Momjian wrote:
OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?
The buildfarm does not run the
80 matches
Mail list logo
