On 21.06.2011 13:08, Alexander Korotkov wrote:
I've created section about testing in project wiki page:
http://wiki.postgresql.org/wiki/Fast_GiST_index_build_GSoC_2011#Testing_results
Do you have any notes about table structure?
It would be nice to have links to the datasets and scripts used, s
(2011/06/24 15:35), HuangQi wrote:
> Hi,
> I'm trying to debug a modification for the query planner. But I found it
> seems the data structure of my planned query is incorrect. I was trying to
> print out the data structure by use the "p" command in gdb which is quite
> inconvenient and takes t
On Fri, Jun 24, 2011 at 12:40 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 21.06.2011 13:08, Alexander Korotkov wrote:
>
>> I've created section about testing in project wiki page:
>> http://wiki.postgresql.org/**wiki/Fast_GiST_index_build_**
>> GSoC_2011#Testing_resul
2011/6/24 Shigeru Hanada
> (2011/06/24 15:35), HuangQi wrote:
> > Hi,
> > I'm trying to debug a modification for the query planner. But I found
> it
> > seems the data structure of my planned query is incorrect. I was trying
> to
> > print out the data structure by use the "p" command in gdb
While reviewing Peter Geoghegan's postmaster death patch, I noticed that
if you turn on silent_mode, the LINUX_OOM_ADJ code in fork_process()
runs when postmaster forks itself into background. That re-enables the
OOM killer in postmaster, if you've disabled it in the startup script by
adjusting
Hi Florian,
On Wed, Jun 22, 2011 at 12:47:42PM +0200, Florian Pflug wrote:
> Updated patch attached.
This builds and passes all tests on both test systems I used previously
(CentOS 5 with libxml2-2.6.26-2.1.2.8.el5_5.1 and Ubuntu 8.04 LTS with libxml2
2.6.31.dfsg-2ubuntu1.6). Tested behaviors lo
On Wed, Jun 22, 2011 at 9:11 PM, Peter Geoghegan wrote:
>> rc = WaitForMultipleObjects(numevents, events, FALSE,
>> (timeout >= 0) ?
>> (timeout / 1000) : INFINITE);
>> - if (rc == WAIT_FAILED)
>> +
On 24 June 2011 12:30, Fujii Masao wrote:
> +#ifndef WIN32
> + /*
> + * Initialise mechanism that allows waiting latch clients
> + * to wake on postmaster death, to finish their
> + * remaining business
> + */
> + InitPostmasterDeathWatchHandle();
> +#endif
On 11-06-24 12:41 AM, Jun Ishiduka wrote:
>
> The logic that not use pg_stop_backup() would be difficult,
> because pg_stop_backup() is used to identify minRecoveryPoint.
>
Considering everything that has been discussed on this thread so far.
Do you still think your patch is the best way to accom
(2011/06/24 19:14), HuangQi wrote:
> 2011/6/24 Shigeru Hanada
>
>> (2011/06/24 15:35), HuangQi wrote:
>> ex)
>> elog(DEBUG1, "%s", nodeToString(plan));
>
> Hi,
> I don't know why but when I am debugging the query evaluation, the elog
> function can not output to shell.
What kind of t
On tor, 2011-06-23 at 21:39 -0400, Bruce Momjian wrote:
> I have created the following patch which uses 25432 as the default port
> number for pg_upgrade.
I don't think we should just steal a port from the reserved range.
Picking a random port from the private/dynamic range seems more
appropriate.
On Fri, Jun 24, 2011 at 9:04 AM, Peter Eisentraut wrote:
>> It also creates two new environment variables,
>> OLDPGPORT and NEWPGPORT, to control the port values because we don't
>> want to default to PGPORT anymore.
>
> I would prefer that all PostgreSQL-related environment variables start
> with
On Jun24, 2011, at 13:24 , Noah Misch wrote:
> On Wed, Jun 22, 2011 at 12:47:42PM +0200, Florian Pflug wrote:
>> Updated patch attached.
>
> This builds and passes all tests on both test systems I used previously
> (CentOS 5 with libxml2-2.6.26-2.1.2.8.el5_5.1 and Ubuntu 8.04 LTS with libxml2
> 2.
Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
> While reviewing Peter Geoghegan's postmaster death patch, I noticed that
> if you turn on silent_mode, the LINUX_OOM_ADJ code in fork_process()
> runs when postmaster forks itself into background. That re-enables the
On Wed, Jun 22, 2011 at 8:54 PM, Bruce Momjian wrote:
>> 0003 is what I really wanted to solve, which was my failure with
>> pg_upgrade. The call to pg_ctl didn't succeed because the binaries
>> didn't match the data directory, thus resulting in this:
>>
>> The error had nothing to do with "trust"
Got another one (no env since the last changes). I'll try and run the "kept"
install from when I killed 22853 (had to use -9) to see if it reproduces the
problem with the same binaries. Is there interest in me removing the perl in
/opt/local/bin/perl? I can install ccache elsewhere and renam
Another thing I just noticed is that if you pg_upgrade from a previous
release, all the NOT NULL pg_constraint rows are going to be missing.
I'm not sure what's the best way to deal with this -- should we just
provide a script for the user to run on each database?
--
Álvaro Herrera
The PostgreS
Shigeru Hanada writes:
> (2011/06/24 15:35), HuangQi wrote:
>> I'm trying to debug a modification for the query planner. But I found it
>> seems the data structure of my planned query is incorrect. I was trying to
>> print out the data structure by use the "p" command in gdb which is quite
>> inco
On 24 June 2011 23:21, Tom Lane wrote:
> Shigeru Hanada writes:
> > (2011/06/24 15:35), HuangQi wrote:
> >> I'm trying to debug a modification for the query planner. But I found it
> >> seems the data structure of my planned query is incorrect. I was trying
> to
> >> print out the data structure
On Fri, Jun 24, 2011 at 11:17 AM, Alvaro Herrera
wrote:
> Another thing I just noticed is that if you pg_upgrade from a previous
> release, all the NOT NULL pg_constraint rows are going to be missing.
Uh, really? pg_upgrade uses SQL commands to recreate the contents of
the system catalogs, so if
While taking a look at the existing documentation for pg_locks I came
across the following paragraph:
When the pg_locks view is accessed, the
internal lock manager data structures are momentarily locked, and
a copy is made for the view to display. This ensures that the
view produce
Excerpts from Robert Haas's message of vie jun 24 12:06:17 -0400 2011:
> On Fri, Jun 24, 2011 at 11:17 AM, Alvaro Herrera
> wrote:
> > Another thing I just noticed is that if you pg_upgrade from a previous
> > release, all the NOT NULL pg_constraint rows are going to be missing.
>
> Uh, really?
Robert Haas wrote:
> While taking a look at the existing documentation for pg_locks I
> came across the following paragraph:
>
>
>When the pg_locks view is accessed,
>the internal lock manager data structures are momentarily
>locked, and a copy is made for the view to display. Thi
On Fri, Jun 24, 2011 at 12:27 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> While taking a look at the existing documentation for pg_locks I
>> came across the following paragraph:
>>
>>
>> When the pg_locks view is accessed,
>> the internal lock manager data structures are momentari
On 24.06.2011 11:40, Heikki Linnakangas wrote:
On 21.06.2011 13:08, Alexander Korotkov wrote:
I believe it's due to relatively expensive penalty
method in that opclass.
Hmm, I wonder if it could be optimized. I did a quick test, creating a
gist_trgm_ops index on a list of English words from
/u
--On 24. Juni 2011 12:06:17 -0400 Robert Haas wrote:
Uh, really? pg_upgrade uses SQL commands to recreate the contents of
the system catalogs, so if these entries aren't getting created
automatically, that sounds like a bug in the patch...
AFAIR, i've tested it and it worked as expected.
A couple of months back, Greg Stark reported mixed results on getting
Clang/LLVM to build Postgres. It could be done, but there were some
bugs, including a bug that caused certain grammar TUs to take way too
long to compile. 2 bug reports were filed. He said that the long
compile time problem was m
Robert Haas wrote:
> Kevin Grittner wrote:
>> It remains true that the heavyweight locking structures are
>> momentarily locked to capture a consistent view of those, and it
>> is also true that the predicate locking structures are
>> momentarily locked to get a consistent view of that data. B
On Fri, Jun 24, 2011 at 1:02 PM, Peter Geoghegan wrote:
> [research]
Nice stuff. Thanks for the update.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
There's been a steady flow of messages on pgsql-advocacy since last
month (threads "Crediting sponsors in release notes?" and "Crediting
reviewers & bug-reporters in the release notes") talking about who/how
should receive credited for their work on PostgreSQL. That discussion
seems to be me h
Excerpts from Bernd Helmle's message of vie jun 24 12:56:26 -0400 2011:
>
> --On 24. Juni 2011 12:06:17 -0400 Robert Haas wrote:
>
> > Uh, really? pg_upgrade uses SQL commands to recreate the contents of
> > the system catalogs, so if these entries aren't getting created
> > automatically, that
On Fri, Jun 24, 2011 at 5:15 PM, Greg Smith wrote:
> -All of these other ways to analyze of the contributors would be much easier
> to maintain. A little "Author:" decoration to that section of each commit
> would probably be welcome too.
I think you're quite right, that "mining" the commit logs
On Fri, Jun 24, 2011 at 1:15 PM, Greg Smith wrote:
> There's been a steady flow of messages on pgsql-advocacy since last month
> (threads "Crediting sponsors in release notes?" and "Crediting reviewers &
> bug-reporters in the release notes") talking about who/how should receive
> credited for the
On Thu, 2011-06-23 at 22:02 -0400, Robert Haas wrote:
> > 1. INSERT to a new page, marking it with LSN X
> > 2. WAL flushed to LSN Y (Y > X)
> > 2. Some persistent snapshot (that doesn't see the INSERT) is released,
> > and generates WAL recording that fact with LSN Z (Z > Y)
> > 3. Lazy VACUUM mar
On Fri, Jun 24, 2011 at 1:43 PM, Jeff Davis wrote:
>> And anything that is WAL-logged must obey the WAL-before-data rule.
>> We have a system already that ensures that when
>> synchronous_commit=off, CLOG pages can't be flushed before the
>> corresponding WAL record makes it to disk.
>
> In this c
On Fri, Jun 24, 2011 at 12:51 PM, Heikki Linnakangas
wrote:
> On 24.06.2011 11:40, Heikki Linnakangas wrote:
>>
>> On 21.06.2011 13:08, Alexander Korotkov wrote:
>>>
>>> I believe it's due to relatively expensive penalty
>>> method in that opclass.
>>
>> Hmm, I wonder if it could be optimized. I d
On 06/24/2011 01:42 PM, Robert Haas wrote:
I am disinclined to add a "feature"
annotation. I think it is unlikely that will end up being any more
useful than just extracting either the whole commit message or its
first line.
I don't see any good way to extract the list of commits relevant
On 2011-06-25 00:02, Peter Geoghegan wrote:
At a large presentation that I and other PG community members were
present at during FOSDEM, Postgres was specifically cited as an
example of a medium-sized C program that had considerably improved
compile times on Clang. While I was obviously unable t
On 24.06.2011 21:24, Robert Haas wrote:
Out of curiosity (and because there is no comment or Assert here), how
can you be so sure of the input alignment?
The input TRGM to makesign() is a varlena, so it must be at least 4-byte
aligned. If it was not for some reason, the existing VARSIZE invoca
On Fri, Jun 24, 2011 at 2:47 PM, Greg Smith wrote:
> On 06/24/2011 01:42 PM, Robert Haas wrote:
>> I am disinclined to add a "feature"
>> annotation. I think it is unlikely that will end up being any more
>> useful than just extracting either the whole commit message or its
>> first line.
>
> I d
On Fri, Jun 24, 2011 at 3:01 PM, Heikki Linnakangas
wrote:
> On 24.06.2011 21:24, Robert Haas wrote:
>>
>> Out of curiosity (and because there is no comment or Assert here), how
>> can you be so sure of the input alignment?
>
> The input TRGM to makesign() is a varlena, so it must be at least 4-by
On Fri, Jun 24, 2011 at 6:47 PM, Greg Smith wrote:
> On 06/24/2011 01:42 PM, Robert Haas wrote:
>> I am not inclined to try to track sponsors in the commit message at
>> all.
>
> I was not suggesting that information be part of the commit. We've worked
> out a reasonable initial process for the p
On Sun, Jun 19, 2011 at 2:16 PM, Robert Haas wrote:
> New patch attached, with that one-line change.
Jeff, are you planning to review this further? Do you think it's OK to commit?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hac
On Thu, Jun 23, 2011 at 8:59 PM, Robert Haas wrote:
> On Wed, Jun 22, 2011 at 11:26 AM, Simon Riggs wrote:
>> For people that still think there is still risk, I've added a
>> parameter called "relaxed_ddl_locking" which defaults to "off". That
>> way people can use this feature in an informed way
Hello,
I have seen the discussions about fastlock patch and lazy-vxid performance
degradation, so I decided to test it myself.
The setup:
- hardware
Supermicro blade
6xSAS @15k on LSI RAID:
1 disk for system + pg_xlog
4 disk RAID 10 for data
1 disk for spare
2 x Xeon E5405 @2GHz (no HT)
On Fri, Jun 24, 2011 at 3:31 PM, wrote:
> I post this results because they somehow contradict with previous results
> posted on the list. In
> my case the patches does not only improve peak performance but also improve
> the performance
> under load - without patches the performance with 256 clie
On Fri, Jun 24, 2011 at 3:46 PM, Simon Riggs wrote:
> Test case please. I don't understand the problem you're describing.
S1: select * from foo;
S2: begin;
S2: alter table foo alter column a set storage plain;
S1: select * from foo;
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Fri, Jun 24, 2011 at 1:08 PM, Kevin Grittner
wrote:
>> What I think we should do is replace the existing paragraph with
>> something along these lines:
>>
>> The pg_locks view displays data from both
>> the regular lock manager and the predicate lock manager, which are
>> separate systems. Whe
On Fri, Jun 24, 2011 at 9:00 PM, Robert Haas wrote:
> On Fri, Jun 24, 2011 at 3:46 PM, Simon Riggs wrote:
>> Test case please. I don't understand the problem you're describing.
>
> S1: select * from foo;
> S2: begin;
> S2: alter table foo alter column a set storage plain;
> S1: select * from foo;
Peter Eisentraut wrote:
> On tor, 2011-06-23 at 21:39 -0400, Bruce Momjian wrote:
> > I have created the following patch which uses 25432 as the default port
> > number for pg_upgrade.
>
> I don't think we should just steal a port from the reserved range.
> Picking a random port from the private/d
Robert Haas wrote:
> On Fri, Jun 24, 2011 at 2:47 PM, Greg Smith wrote:
> > On 06/24/2011 01:42 PM, Robert Haas wrote:
> >> I am disinclined to add a "feature"
> >> annotation. ?I think it is unlikely that will end up being any more
> >> useful than just extracting either the whole commit message
On Fri, Jun 24, 2011 at 4:27 PM, Simon Riggs wrote:
> On Fri, Jun 24, 2011 at 9:00 PM, Robert Haas wrote:
>> On Fri, Jun 24, 2011 at 3:46 PM, Simon Riggs wrote:
>>> Test case please. I don't understand the problem you're describing.
>>
>> S1: select * from foo;
>> S2: begin;
>> S2: alter table f
On 11-06-15 03:20 PM, Martin Pihlak wrote:
Yes, that sounds like a good idea -- especially considering that COPY
is not the only operation that can cause SSL_write retries.
This is of course still "work in progress", needs cleaning up and
definitely more testing. But at this point before going
On Fri, Jun 24, 2011 at 3:31 PM, wrote:
> clients beta2 +fastlock +lazyvzid local socket
> 8 76064 92430 92198 106734
> 16 64254 90788 90698 105097
> 32 56629 88189 88269 101202
> 64 51124 84354 84639 96362
> 128 45455 79361 79724 90625
> 256 40370 71904 72737 82434
I'm having trouble interpreti
On Fri, Jun 24, 2011 at 10:08 PM, Robert Haas wrote:
> On Fri, Jun 24, 2011 at 4:27 PM, Simon Riggs wrote:
>> On Fri, Jun 24, 2011 at 9:00 PM, Robert Haas wrote:
>>> On Fri, Jun 24, 2011 at 3:46 PM, Simon Riggs wrote:
Test case please. I don't understand the problem you're describing.
>>>
On Fri, Jun 24, 2011 at 5:28 PM, Simon Riggs wrote:
> I've explained all of the above points to you already and you're wrong.
We're going to have to agree to disagree on that point.
> Do you advocate that all ALTER TABLE operations use
> AccessExclusiveLock, or just the operations I added? If yo
When Magnus fixed and applied my SSPI-via-GSS patch in January, we
forgot to fix to the documentation. Suggested patch attached; should I
also put that four-liner into any CFs?
--
Christian
diff --git a/doc/src/sgml/client-auth.sgml b/doc/src/sgml/client-auth.sgml
new file mode 100644
index 575
So remind me ... did we discuss PRIMARY KEY constraints? Are they
supposed to show up as inherited not null rows in the child? Obviously,
they do not show up as PKs in the child, but they *are* not null so my
guess is that they need to be inherited as not null as well. (Right
now, unpatched hea
On Fri, Jun 24, 2011 at 6:39 PM, Alvaro Herrera
wrote:
> So remind me ... did we discuss PRIMARY KEY constraints? Are they
> supposed to show up as inherited not null rows in the child? Obviously,
> they do not show up as PKs in the child, but they *are* not null so my
> guess is that they need
On Jun 24, 2011, at 2:28 PM, Christopher Browne wrote:
> On Fri, Jun 24, 2011 at 6:47 PM, Greg Smith wrote:
>> On 06/24/2011 01:42 PM, Robert Haas wrote:
>>> I am not inclined to try to track sponsors in the commit message at
>>> all.
>>
>> I was not suggesting that information be part of the com
On fre, 2011-06-24 at 16:34 -0400, Bruce Momjian wrote:
> > > It also creates two new environment variables,
> > > OLDPGPORT and NEWPGPORT, to control the port values because we
> don't
> > > want to default to PGPORT anymore.
> >
> > I would prefer that all PostgreSQL-related environment variable
On Fri, Jun 24, 2011 at 04:15:35PM +0200, Florian Pflug wrote:
> On Jun24, 2011, at 13:24 , Noah Misch wrote:
> > On Wed, Jun 22, 2011 at 12:47:42PM +0200, Florian Pflug wrote:
> > There's also the " parser error :" difference; would that also be easy to
> > re-add? (I'm assuming it's not a const
On fre, 2011-06-24 at 18:02 +0100, Peter Geoghegan wrote:
> I'm very encouraged by this - Clang is snapping at the heels of GCC
> here. I'd really like to see Clang as a better supported compiler,
We have a build farm member for Clang:
http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=sme
On 06/24/2011 04:52 PM, Bruce Momjian wrote:
That tagging is basically what I do on my first pass through the release
notes. For the gory details:
http://momjian.us/main/blogs/pgblog/2009.html#March_25_2009
Excellent summary of the process I was trying to suggest might be
improve
Peter Eisentraut wrote:
> On fre, 2011-06-24 at 16:34 -0400, Bruce Momjian wrote:
> > > > It also creates two new environment variables,
> > > > OLDPGPORT and NEWPGPORT, to control the port values because we
> > don't
> > > > want to default to PGPORT anymore.
> > >
> > > I would prefer that all P
- Цитат от Robert Haas (robertmh...@gmail.com), на 25.06.2011 в 00:16 -
> On Fri, Jun 24, 2011 at 3:31 PM, wrote:
>> clients beta2 +fastlock +lazyvzid local socket
>> 8 76064 92430 92198 106734
>> 16 64254 90788 90698 105097
>> 32 56629 88189 88269 101202
>> 64 51124 84354 84639 96362
>>
Greg Smith wrote:
> On 06/24/2011 04:52 PM, Bruce Momjian wrote:
> > That tagging is basically what I do on my first pass through the release
> > notes. For the gory details:
> >
> > http://momjian.us/main/blogs/pgblog/2009.html#March_25_2009
> >
>
> Excellent summary of the process I was
On 06/24/2011 03:28 PM, Christopher Browne wrote:
I expect that the correlation between commit and [various parties] is
something that will need to take place outside git.
Agreed on everything except the "Author" information that is already
being placed into each commit. The right data is
On 25 June 2011 00:27, Peter Eisentraut wrote:
> On fre, 2011-06-24 at 18:02 +0100, Peter Geoghegan wrote:
>> I'm very encouraged by this - Clang is snapping at the heels of GCC
>> here. I'd really like to see Clang as a better supported compiler,
>
> We have a build farm member for Clang:
> http:
On 06/24/2011 03:21 PM, Robert Haas wrote:
If I were attacking this problem, I'd be inclined to make a web
application that lists all the commits in a format roughly similar to
the git API, and then lets you tag each commit with tags from some
list (feature, bug-fix, revert, repair-of-previous-co
Greg Smith wrote:
> I tend not to think in terms of solutions that involve web applications
> because I never build them, but this seems like a useful approach to
> consider. Given that the list of tags is pretty static, I could see a
> table with a line for each commit, and a series of check b
Excerpts from Robert Haas's message of vie jun 24 19:01:49 -0400 2011:
> On Fri, Jun 24, 2011 at 6:39 PM, Alvaro Herrera
> wrote:
> > So remind me ... did we discuss PRIMARY KEY constraints? Are they
> > supposed to show up as inherited not null rows in the child? Obviously,
> > they do not show
Attached is patch that addresses Fujii's third and most recent set of concerns.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 4952d22..bfe6bc
On Fri, Jun 24, 2011 at 7:51 PM, Greg Smith wrote:
> On 06/24/2011 03:28 PM, Christopher Browne wrote:
>> I expect that the correlation between commit and [various parties] is
>> something that will need to take place outside git.
>
> Agreed on everything except the "Author" information that is al
On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian wrote:
> Peter Eisentraut wrote:
>> On fre, 2011-06-24 at 16:34 -0400, Bruce Momjian wrote:
>> > > > It also creates two new environment variables,
>> > > > OLDPGPORT and NEWPGPORT, to control the port values because we
>> > don't
>> > > > want to def
On 25 June 2011 01:59, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of vie jun 24 19:01:49 -0400 2011:
>> I would tend to think of the not-null-ness that is required by the
>> primary constraint as a separate constraint, not an intrinsic part of
>> the primary key. IOW, if you drop
76 matches
Mail list logo
