Hi,
On Wed, Jun 10, 2009 at 4:21 AM, Simon Riggs wrote:
>
> 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
Currently, libpq will wrap each send() call on the connection with
two system calls to mask SIGPIPEs. This results in 3 syscalls instead
of one, and (on Linux) can lead to high contention on the signal
mask locks in threaded apps.
We have a couple of other methods to avoid SIGPIPEs:
sockopt(SO_NOS
Currently, the sigpipe-masking code in libpq is implemented as
a set of macros, which depend on declaring local variables.
This change adds a (private) struct sigpipe_info to contain the
compile-dependent data required for sigpipe masking and restoring.
The caller can then declare a struct sigpipe
A new approach to avioding manipulating the signal mask during for every
send - this time round, use SO_NOSIGPIPE and MSG_NOSIGNAL if available.
The patches have been tested on Linux and OSX, and I've confirmed that
'struct foo { };' will compile with a MSVC compiler. I'd still like a
little more
On Tue, 2009-06-09 at 13:21 -0400, 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?
Why don't we do this automatically after each individual commit? That
way each commi
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 find-type
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 apply it
Tom Lane wrote:
> Bruce Momjian 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 di
Tom Lane wrote:
> Bruce Momjian 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 di
Bruce Momjian 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 typedef names
from
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 differe
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
Sergey Burladyan 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.
re
Tom Lane 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 aren't strict a
Merlin Moncure 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?
> actually, aix
On Sunday 31 May 2009 20:00:44 Tom Lane wrote:
> Itagaki Takahiro 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 highlighted by your
> patch, is wh
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 (pgsql-hack
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 Tue, 2009-06-09 at 17:28 -0400, Tom Lane wrote:
> Simon Riggs 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
On Tue, Jun 9, 2009 at 5:24 PM, Tom Lane wrote:
> Andrew Dunstan 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
Simon Riggs 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.
> Should there be
Andrew Dunstan 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 the same machi
Tom Lane wrote:
"Albe Laurenz" 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
Tom Lane wrote:
> "Kevin Grittner" writes:
>> "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 itself, but used resources or
>>> other thi
On Tue, 2009-06-09 at 16:17 -0400, Tom Lane wrote:
> Simon Riggs 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 p
"Albe Laurenz" 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 matter and always
Simon Riggs 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, but otherwise
"Kevin Grittner" writes:
> "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 craz
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 replicas.
"Kolb, Harald (NSN - DE/Munich)" 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 appropriate
> me
"Kolb, Harald (NSN - DE/Munich)" 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 nothing whatever
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 cr
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 im
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)
> Subjec
Josh Berkus 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 would require t
"Greg Sabino Mullane" 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 are
> sayin
Jeff Davis 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 _shared_ memory
Gurjeet Singh 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 (pgsql-hackers@postgresql.org)
To mak
Peter Eisentraut 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 benefit of anyon
On Tue, Jun 9, 2009 at 11:14 PM, Tom Lane wrote:
> Andrew Dunstan 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).
Peter Eisentraut 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 @@ CREATE FU
On Tue, 2009-06-09 at 13:54 -0400, Tom Lane wrote:
> Simon Riggs 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 p
On Tue, Jun 9, 2009 at 1:00 PM, Kevin
Grittner 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 specified that way...
i
On Monday 08 June 2009 07:12:33 Tom Lane wrote:
> Peter Eisentraut 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 the
On Tue, Jun 9, 2009 at 1:47 PM, Tom Lane wrote:
> Robert Haas 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
Tom Lane wrote:
> Robert Haas 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 WIT
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 th
Simon Riggs 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, but otherwise
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 w
Alvaro Herrera 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, where we plan to just sta
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
synchr
Robert Haas 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 cursor.
I don't
Andrew Dunstan 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 not something
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
> chang
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. I
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lane 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. The problem with
On Tue, Jun 9, 2009 at 12:41 PM, Greg Sabino Mullane 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 warrants a bump.
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive,
* 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
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 catversion
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 will
Jaime Casanova 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 pgsql-hackers mailing list (pgsql-
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 wrote:
* Simon Riggs:
On Tue, 2009-06-09 at 13:40 +0200, Floris Bos / Maxnet wrote:
fsync = off
That's a b
On Tue, Jun 9, 2009 at 11:31 AM, 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 settin
-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 li
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
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. Attemp
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
th
* 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 Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Krieg
Mark Kirkwood 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 (i.e some rows end up b
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 ma
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, p
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,
Joe Conway 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 literals.
I can repro
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 quote
Floris Bos / Maxnet 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 problem for you.
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 wrote:
> still doesn't work:
>
> make[1]: Leaving directory `/home/gjaskie/Pro
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 abl
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 foundcts/pos
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
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 wrote:
Floris Bos / Maxnet wrote:
I am having the problem that some queries are
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 f
PFA. This file is to be kept in 'pgsql_init' base directory.
On Tue, Jun 9, 2009 at 12:54 PM, Grzegorz Jaskiewicz
wrote:
> gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv
> -bundle -multiply_defined s
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 ../../../contrib/
85 matches
Mail list logo
