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 commit
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
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
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:
Hi,
On Wed, Jun 10, 2009 at 4:21 AM, Simon Riggssi...@2ndquadrant.com 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
Tom Lane wrote:
Drat. Okay, that easy solution probably won't fly. Anyone with AIX
access want to try to develop a patch that covers this case without
breaking the other ones?
I can try, but I only have AIX 5.3 to test with, so I won't be able
to test for bugs in other versions.
I would
Getting error while trying to insert date with the format 'dd-month-' ,
'day-mm-' (format which add the space in between the date ) etc..
Testcase:
postgres=# \d t
Table public.t
Column | Type | Modifiers
+--+---
a | date |
postgres=# insert into
Hi,
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freundand...@anarazel.de writes:
On 06/03/2009 06:21 PM, Tom Lane wrote:
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at all in profiles. What sort of
queries are you
On 6/10/09, Jeremy Kerr j...@ozlabs.org wrote:
+ int optval;
+ if (!setsockopt(conn-sock,
SOL_SOCKET, SO_NOSIGPIPE,
+ (char *)optval,
sizeof(optval)))
Andres Freund and...@anarazel.de writes:
Plan time (averaged) without change:
cnt: 40 (4 times per session)
avg: 4572ms
Plan time (averaged) with change:
cnt: 40 (4 times per session)
avg: 4236ms
~7% difference. Same with higher number of repetitions and with most other
planner settings
Hi,
On 06/10/2009 01:38 PM, Gregory Stark wrote:
Andres Freundand...@anarazel.de writes:
Plan time (averaged) without change:
cnt: 40 (4 times per session)
avg: 4572ms
Plan time (averaged) with change:
cnt: 40 (4 times per session)
avg: 4236ms
~7% difference. Same with higher number of
Marko,
optval seems used without initialization.
Dang, I was checking for the SO_NOSIGPIPE flag, and didn't check for
optval. New patch coming...
Cheers,
Jeremy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
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:
On Wed, Jun 10, 2009 at 3:38 AM, Albe Laurenzlaurenz.a...@wien.gv.at wrote:
Tom Lane wrote:
Drat. Okay, that easy solution probably won't fly. Anyone with AIX
access want to try to develop a patch that covers this case without
breaking the other ones?
I can try, but I only have AIX 5.3 to
On Tue, 2009-06-09 at 17:28 -0400, Tom Lane wrote:
Is there any particular reason to suppose that the empty pages appeared
during a crash recovery?
Have you read through md.c? I seem to recall there are some slightly
squirrelly choices made there about segment-extension behavior. Maybe
Andrew Dunstan wrote:
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
Simon Riggs si...@2ndquadrant.com writes:
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.
Why don't we do this automatically after each individual
Rushabh Lathia rushabh.lat...@gmail.com writes:
Getting error while trying to insert date with the format 'dd-month-' ,
'day-mm-' (format which add the space in between the date ) etc..
1. Why are you bothering with the completely pointless to_char call at all?
2. It is not a bug that
Floris Bos / Maxnet wrote:
The following settings differ from the defaults:
--
shared_buffers=3500MB
maintenance_work_mem = 128MB
fsync = off
synchronous_commit = off
checkpoint_segments = 25
--
==
Table layout
==
--
Table public.posts_index
Column |
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)?
I agree we are running out of time so I will be running
Bruce Momjian wrote:
Andrew Dunstan wrote:
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
Andrew Dunstan wrote:
Well, sometimes I build it and they don't come ;-).
I don't have every platform under the sun that I can run this on,
although I do now have an FBSD VM that I didn't have when I worked on
this previously. If you're actually going to use it I'll set it up as a
Bruce Momjian wrote:
Good point. Here is another diff I need you to make to the pl file.
Done. Linux run under way.
If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do that?
It needs to be done in
Merlin Moncure wrote:
I wrote:
I can try, but I only have AIX 5.3 to test with, so I won't be able
to test for bugs in other versions.
I would need to know what the problems with getaddrinfo on AIX are.
I'll also try to investigate known bugs in AIX' getaddrinfo.
AIX 4.3 has been out of
Bruce Momjian wrote:
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
Andres Freund and...@anarazel.de wrote:
- Sometimes adding a single join more/less dropped the planning time
to a fraction - strange.
- The same with changing {join,from}_collapse_limit - sometimes
changing it yields plan times different by orders of magnitudes in
both directions.
That
Andrew Dunstan wrote:
Bruce Momjian wrote:
Good point. Here is another diff I need you to make to the pl file.
Done. Linux run under way.
If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do
Albe Laurenz laurenz.a...@wien.gv.at writes:
Maybe it would be good enough to state that AIX is only supported with
certain fixpacks installed? And do without all the AIX hacks?
That would definitely be a good-enough solution in my opinion,
as long as we can document which fixes are needed for
Bruce Momjian br...@momjian.us writes:
OK, I have found the cause of the script error, and it was my fault. A
month after we ran pgindent for 8.3 (December 2007), I received this
issue from Tom:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
Something I noticed the other
Given that RC freeze is nearly upon us for 8.4, and that we need a
reasonably non-invasive fix for 8.3 anyway, I propose that for now
we just deal with the syncscan issue by tweaking heap_rescan so that
rs_startblock doesn't get changed. It looks like that's about a
three-line patch. The
Hi all,
I created a function which needs build or find a relation (RelOptInfo).
The build is ok.
On the other hand, I can't find the relation. I have all informations that
pg_plan_query has: querytree (Query), cursorOptions (int),
boundParams(ParamListInfo) and plan (PlannedStmt).
So, how can I
Hi,
On 06/10/2009 06:01 PM, Kevin Grittner wrote:
Andres Freundand...@anarazel.de wrote:
- Sometimes adding a single join more/less dropped the planning time
to a fraction - strange.
- The same with changing {join,from}_collapse_limit - sometimes
changing it yields plan times different by
If we are to make the proposed schedule for 8.4 (ie, wrap RC1 tomorrow)
we've got to get pretty hard-nosed about closing out the open items at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
The current list is:
* do we need to worry about re-encoding file path names?
There is perhaps
Ana Carolina Brito de Almeida ana...@ig.com.br writes:
I created a function which needs build or find a relation (RelOptInfo).
The build is ok.
On the other hand, I can't find the relation. I have all informations that
pg_plan_query has: querytree (Query), cursorOptions (int),
Tom Lane wrote:
If we are to make the proposed schedule for 8.4 (ie, wrap RC1 tomorrow)
we've got to get pretty hard-nosed about closing out the open items at
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
The current list is:
* do we need to worry about re-encoding file path
Andy,
6) To the -hackers: I write the records and then refind them in the
exact same order, would it be a better test to search for records in a
more random order? would it make a difference? Would searching for some
but not all make a difference?
Are you on OpenSolaris? Can you give your
Magnus Hagander mag...@hagander.net writes:
Tom Lane wrote:
* do we need to worry about re-encoding file path names?
Is there really something new here for 8.4? Haven't we lived with this
same thing previously?
Right, it's a pre-existing issue --- any misbehavior in this area goes
back to
On 6/10/09 10:40 AM, Tom Lane wrote:
* contrib/seg and contrib/cube GiST index support have performance issues
Wasn't there an issue that fixing this requires a data format change?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
On Wed, Jun 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Maybe it would be good enough to state that AIX is only supported with
certain fixpacks installed? And do without all the AIX hacks?
That would definitely be a good-enough solution
Merlin Moncure wrote:
On Wed, Jun 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Albe Laurenz laurenz.a...@wien.gv.at writes:
Maybe it would be good enough to state that AIX is only supported with
certain fixpacks installed? And do without all the AIX hacks?
That
Josh Berkus wrote:
Andy,
6) To the -hackers: I write the records and then refind them in the
exact same order, would it be a better test to search for records in a
more random order? would it make a difference? Would searching for some
but not all make a difference?
Are you on OpenSolaris?
Josh Berkus j...@agliodbs.com writes:
On 6/10/09 10:40 AM, Tom Lane wrote:
* contrib/seg and contrib/cube GiST index support have performance issues
Wasn't there an issue that fixing this requires a data format change?
Well, that means it probably doesn't get fixed till 8.5. I'm annoyed
at
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
OK, I have found the cause of the script error, and it was my fault. A
month after we ran pgindent for 8.3 (December 2007), I received this
issue from Tom:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
Floris,
One more question set: what version of OpenSolaris, and what filesystem
are you using? Does the OS have any non-default tuning settings? How
did you install or compile PostgreSQL?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list
Tom,
Alternatively, we can postpone 8.4 till Oleg and Teodor have some spare
cycles to look at the patch, but who knows when that will be.
Not soon. So, +1 to go ahead.
If this issue has existed for several versions, and we're not getting a
lot of complaints, it says that either not many
Bruce Momjian br...@momjian.us writes:
I am unclear why struct pointers are not being formatted properly in
function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.
Have you
On Wednesday 10 June 2009 17:10:42 Tom Lane wrote:
Rushabh Lathia rushabh.lat...@gmail.com writes:
Getting error while trying to insert date with the format 'dd-month-'
, 'day-mm-' (format which add the space in between the date ) etc..
1. Why are you bothering with the completely
Josh Berkus j...@agliodbs.com writes:
If this issue has existed for several versions, and we're not getting a
lot of complaints, it says that either not many people are using cube
and seg or they don't notice performance issues.
Mind you, if performance is terrible, then not many people
Tom,
I suspect there aren't many. What I'm more concerned about is that
people may have copied the bogus logic for use in their own datatypes.
(Which is exactly how Matthew Wakeling came to find out the problem.)
But in any case, this train is leaving the station.
Can we put a warning in the
Josh Berkus j...@agliodbs.com writes:
Tom,
I suspect there aren't many. What I'm more concerned about is that
people may have copied the bogus logic for use in their own datatypes.
(Which is exactly how Matthew Wakeling came to find out the problem.)
But in any case, this train is leaving
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I am unclear why struct pointers are not being formatted properly in
function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do
Bruce Momjian br...@momjian.us writes:
Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.
I am waiting for Andrew to tell me he is ready with updated lists for
his platforms.
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I am unclear why struct pointers are not being formatted properly in
function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something
Andrew Dunstan wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I am unclear why struct pointers are not being formatted properly in
function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it
On Wed, 10 Jun 2009, Tom Lane wrote:
There are also a number of documentation issues open, particularly
Dimitri's work on documenting the GIST API better, but we can work
on those later. We've never considered that the RC freeze applies
to documentation.
I had a question in this area
Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Bruce Momjian wrote:
I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:
typedef struct PortalData *Portal;
typedef struct PortalData
{
/* Bookkeeping data */
...
Greg Smith gsm...@gregsmith.com writes:
On Wed, 10 Jun 2009, Tom Lane wrote:
There are also a number of documentation issues open, particularly
Dimitri's work on documenting the GIST API better, but we can work
on those later. We've never considered that the RC freeze applies
to
Greg Stark st...@enterprisedb.com writes:
Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.
It tends to put extra spaces in variable declarations that are using
the
On Tuesday 09 June 2009 20:21:35 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?
Btw., can you make pgindent remove whitespace at the end of lines?
--
Sent via
Floris Bos / Maxnet b...@je-eigen-domein.nl writes:
Hi,
Tom Lane wrote:
Floris Bos / Maxnet b...@je-eigen-domein.nl writes:
postg...@db:/data$ /opt/postgres/8.4-beta/bin/64/initdb -E SQL_ASCII -X
/data/pg_xlog /data/db
The database cluster will be initialized with locale en_US.UTF-8.
Peter Eisentraut pete...@gmx.net writes:
Btw., can you make pgindent remove whitespace at the end of lines?
I think it usually does that already ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Andrew Dunstan wrote:
Bruce Momjian wrote:
I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:
typedef struct PortalData *Portal;
typedef struct PortalData
{
/* Bookkeeping data */
Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
Out of curiosity how different is the output if we don't pass the
typedef list at all? I'm wondering if the formatting differences are
things we actually care much about anyways.
It tends to put extra spaces in variable
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Btw., can you make pgindent remove whitespace at the end of lines?
I think it usually does that already ...
Yes.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB
On Wednesday 10 June 2009 22:50:15 Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Btw., can you make pgindent remove whitespace at the end of lines?
I think it usually does that already ...
Yes.
Um, attached you will find a bunch of counterexamples.
Peter Eisentraut pete...@gmx.net writes:
I think it usually does that already ...
Um, attached you will find a bunch of counterexamples.
At a quick look, I'm not sure that any of these are in code that hasn't
been edited since the 8.3 pgindent run.
regards, tom lane
On Wed, Jun 10, 2009 at 9:54 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
I think it usually does that already ...
Um, attached you will find a bunch of counterexamples.
At a quick look, I'm not sure that any of these are in code that hasn't
been edited
I'm having trouble coming up with a sensible translation for the last line of
this:
peter=# \d test*
Table public.test1
Column | Type | Modifiers
+-+---
a | integer | not null
Indexes:
test1_pkey PRIMARY KEY, btree (a)
Referenced by:
test2_y_fkey IN
Peter Eisentraut wrote:
I'm having trouble coming up with a sensible translation for the last line of
this:
peter=# \d test*
Table public.test1
Column | Type | Modifiers
+-+---
a | integer | not null
Indexes:
test1_pkey PRIMARY KEY, btree (a)
Bruce Momjian br...@momjian.us wrote:
Peter Eisentraut wrote:
Indexes:
test1_pkey PRIMARY KEY, btree (a)
Referenced by:
test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a)
Is there a magic reason why the IN is capitalized?
should be lowercase.
What about PRIMARY KEY,
Peter Eisentraut pete...@gmx.net writes:
Referenced by:
test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a)
Is there a magic reason why the IN is capitalized? (Maybe from would be
better anyway?)
I think it was probably done to make it more visually distinct from the
adjacent
On Wed, Jun 10, 2009 at 10:58 PM, Bruce Momjianbr...@momjian.us wrote:
Is there a magic reason why the IN is capitalized? (Maybe from would be
better anyway?)
Probably not. They were used to capitalizing IN for a subquery and it
carried over; should be lowercase.
Well in that line
2009/6/11 Peter Eisentraut pete...@gmx.net:
Referenced by:
test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a)
Is there a magic reason why the IN is capitalized? (Maybe from would be
better anyway?)
Isn't on the conventional preposition to use here? I would think of
this as a
On Wed, Jun 10, 2009 at 11:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Or use TABLE:
test2_y_fkey TABLE test2 FOREIGN KEY (y) REFERENCES test1(a)
Hm, one of the things a lot of people said they liked about the
existing list is that it was almost copy-pastable as the command to
recreate the
I wrote:
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
Greg Stark st...@enterprisedb.com writes:
So perhaps something like:
Referenced by:
TABLE test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a);
+1
... although making it *really* copy-and-pastable would require a bit
more attention to detail than I bet it's gotten. (Schema
Tom Lane wrote:
Given that RC freeze is nearly upon us for 8.4, and that we need a
reasonably non-invasive fix for 8.3 anyway, I propose that for now
we just deal with the syncscan issue by tweaking heap_rescan so that
rs_startblock doesn't get changed. It looks like that's about a
three-line
On Wed, Jun 10, 2009 at 11:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
So perhaps something like:
Referenced by:
TABLE test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a);
+1
... although making it *really* copy-and-pastable would
Greg Stark st...@enterprisedb.com writes:
On Wed, Jun 10, 2009 at 11:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
TABLE test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a);
+1
Even there the TABLE is kind of optional. It would stlil make
Dear PostgreSQL Hackers,
Through PostgreSQL 8.3, both of the following functions worked, using
generate_series(array_lower($1, 1), array_upper($1, 1)) i
instead of generate_subscripts($1, 1).
With PostgreSQL 8.4, both are accepted, but only the second one works,
regardless of whether I use
Andrew Dunstan wrote:
I am doing runs as requested on various platforms to extract the
typedef lists. Linux is done, Windows (mingw) is running, FBSD and
Cygwin to come.
Results in a few hours. The buildfarm will have a consolidated list.
The consolidated list comes from
Andrew Dunstan wrote:
Andrew Dunstan wrote:
I am doing runs as requested on various platforms to extract the
typedef lists. Linux is done, Windows (mingw) is running, FBSD and
Cygwin to come.
Results in a few hours. The buildfarm will have a consolidated list.
The
On Thu, Jun 11, 2009 at 12:02 AM, Peter Eisentraut pete...@gmx.net wrote:
On Wednesday 10 June 2009 17:10:42 Tom Lane wrote:
Rushabh Lathia rushabh.lat...@gmail.com writes:
Getting error while trying to insert date with the format
'dd-month-'
, 'day-mm-' (format which add the
Rushabh Lathia rushabh.lat...@gmail.com writes:
I thought when we are providing the different format into to_char for
datetime then standard datetime input converters should also have the
capability to read that format.
to_char is designed to support a near-infinite number of output formats,
Bruce Momjian wrote:
The consolidated list comes from Windows(mingw) and Linux. My Cygwin
run broke for some reason, and 'objdump --stabs' doesn't seem to do what
we need on FBSD, so the output there was empty. If someone knows how to
get the typedefs out via objdump on FBSD would they
Andrew Dunstan and...@dunslane.net writes:
Bruce Momjian wrote:
I will check on our Postgres shell server right away.
OK, so we got that working, and the consolidated list now contains FBSD
data as well.
Um, let's *go* guys. RC1 wrap is scheduled for 18 hours from now.
That means it is
88 matches
Mail list logo
