The SE-PostgreSQL patches are updated as follows:
1) http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.4beta2-r2016.patch
2) http://sepgsql.googlecode.com/files/sepgsql-02-core-8.4beta2-r2016.patch
3) http://sepgsql.googlecode.com/files/sepgsql-03-writable-8.4beta2-r2016.patch
4) http://sepg
Andrew Dunstan 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 already too late t
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 pleas
Rushabh Lathia 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,
including many that ar
On Thu, Jun 11, 2009 at 12:02 AM, Peter Eisentraut wrote:
> On Wednesday 10 June 2009 17:10:42 Tom Lane wrote:
> > Rushabh Lathia 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.
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
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 Windows(ming
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 gene
Greg Stark writes:
> On Wed, Jun 10, 2009 at 11:21 PM, Tom Lane wrote:
>> Greg Stark 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 sense as
> Referenced by:
> test2 CONSTRAINT test
On Wed, Jun 10, 2009 at 11:21 PM, Tom Lane wrote:
> Greg Stark 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
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 pa
Greg Stark 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 qualification
and double
I wrote:
> 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.
So I jus
On Wed, Jun 10, 2009 at 11:04 PM, Tom Lane 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 constraint. If we
2009/6/11 Peter Eisentraut :
> 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 foreign key
On Wed, Jun 10, 2009 at 10:58 PM, Bruce Momjian 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 everything
Peter Eisentraut 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 identifiers,
Bruce Momjian 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, FO
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 KE
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"
On Wed, Jun 10, 2009 at 9:54 PM, Tom Lane wrote:
> Peter Eisentraut 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
Peter Eisentraut 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
--
Sent via
On Wednesday 10 June 2009 22:50:15 Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut 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.
Index:
Tom Lane wrote:
> Greg Stark 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 us
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
> > {
> > /* Bookkeep
Tom Lane wrote:
> Peter Eisentraut writes:
> > Btw., can you make pgindent remove whitespace at the end of lines?
>
> I think it usually does that already ...
Yes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life
Peter Eisentraut 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 subscription:
http://ww
Floris Bos / Maxnet writes:
> Hi,
> Tom Lane wrote:
>> Floris Bos / Maxnet 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.
>>
>> Oooh, that doesn't look real good
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 pgsql-ha
Greg Stark 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 typedef. Not sure a
Greg Smith 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 documentation.
> I had
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 */
...
b
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:
http://www
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 actually
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > Bruce Momjian 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,
Tom Lane wrote:
Bruce Momjian 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.
Bruce Momjian 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. His CGI ou
Tom Lane wrote:
> Bruce Momjian 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.
Josh Berkus 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 the station
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 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 *would* use
> cu
On Wednesday 10 June 2009 17:10:42 Tom Lane wrote:
> Rushabh Lathia 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 c
Bruce Momjian 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 started the pgind
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 pe
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 (pgsq
Tom Lane wrote:
> Bruce Momjian 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
Josh Berkus 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 that, but such
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? C
Merlin Moncure wrote:
On Wed, Jun 10, 2009 at 12:13 PM, Tom Lane wrote:
"Albe Laurenz" 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
On Wed, Jun 10, 2009 at 12:13 PM, Tom Lane wrote:
> "Albe Laurenz" 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 c
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 (pgsql-hackers@p
Magnus Hagander 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 the beginning.
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 scr
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
Ana Carolina Brito de Almeida 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),
> boundParams(ParamListInfo)
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
Hi,
On 06/10/2009 06:01 PM, Kevin Grittner wrote:
Andres Freund 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 i
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 ta
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 question
Bruce Momjian 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 day is that
"Albe Laurenz" 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 which releases.
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
Andres Freund 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 seems like the p
Bruce Momjian wrote:
> 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
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 h
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
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
> b
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 CVS
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)?
> I agree we are running out of time so I will be running pgindent in
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
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 |
Rushabh Lathia 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 to_char is capable of e
Simon Riggs 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 commit?
It's not ve
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?
> >
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. May
On Wed, Jun 10, 2009 at 3:38 AM, Albe Laurenz 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 test with, so I
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
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:
http://www.postgresq
Hi,
On 06/10/2009 01:38 PM, Gregory Stark wrote:
Andres Freund 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 m
Andres Freund 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 I tried
On 6/10/09, Jeremy Kerr wrote:
> + int optval;
> + if (!setsockopt(conn->sock,
> SOL_SOCKET, SO_NOSIGPIPE,
> + (char *)&optval,
> sizeof(optval)))
optval seems u
Hi,
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freund 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 testing?
Many left joins
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
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 n
84 matches
Mail list logo
