Tatsuo,
Ok. Your suggestion is very helpfull. In general Tsutomu will wait for
feedbacks come in, probably until Jan 15th.
BTW, is there anyone who wishes the patches get in 8.5? Apparently
Tstutomu, Magnus and I are counted in the group:-) But I'd like to
know how other people are
Takahiro Itagaki escreveu:
Sure, I should have merge all of the comments. Patch attached.
Thanks for your effort. Looks sane to me.
- Updated the output format as follows. I think this format is the most
similar to existing lines. (actual by ANALYZE and Filter:).
If people object to it,
On Wed, Dec 9, 2009 at 8:31 AM, Massa, Harald Armin c...@ghum.de wrote:
Tatsuo,
Ok. Your suggestion is very helpfull. In general Tsutomu will wait for
feedbacks come in, probably until Jan 15th.
BTW, is there anyone who wishes the patches get in 8.5? Apparently
Tstutomu, Magnus and I are
On Wed, Dec 9, 2009 at 10:51 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Dec 9, 2009 at 10:12 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Thought? Am I missing something?
This seems terribly overdesigned. Just emit a warning when you see
the
Josh Berkus wrote:
I thought the idea was that we were going to add PL/proxy to 8.5, with
support for the foriegn data wrapper syntax? What happened to that?
Using SQL/MED for defining pl/proxy clusters is still in the TODO list.
I hope to do something about it during the next few weeks.
On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander mag...@hagander.net wrote:
2009/12/9 Bruce Momjian br...@momjian.us:
I frankly think the patch should be thought of as the SE-Linux-specific
directory files, which KaiGai can maintain, and the other parts, which I
think I can handle.
I think
On Wed, Dec 9, 2009 at 12:36 AM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Note that the patch also removes buffer counters from log_statement_stats,
but we only have brief descriptions about the options. Our documentation
say nothing about buffer counters, so I didn't modify those
On Mon, Dec 7, 2009 at 8:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Heikki Linnakangas wrote:
- at the end of WAL segment, when there's not enough space to write the
next WAL record, always write an XLOG SWITCH record to fill the rest of
the
It's a two step process. An update marks the tuple locked. Another
transaction which comes along and wants to lock the tuple waits on the
transaction marked on the tuple. When the first transaction commits or
aborts then the second transaction can proceed and lock the tuple
itself.
I agree with
Greg Smith píše v út 08. 12. 2009 v 22:44 -0500:
Zdenek Kotala wrote:
thanks for your useful comments. I attached new doc patch version. I
removed example changes and add link to create database cluster (I hope)
everywhere. Please, look on it and let me know if there is still
something
[moved to -hackers]
On tor, 2009-11-12 at 09:35 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
strace on the backend processes all showed them waiting at
futex(0x7f1ee5e21c90, FUTEX_WAIT_PRIVATE, 2, NULL
Notably, the first argument was the same for all of them.
Looks
Martin Pihlak escribió:
Josh Berkus wrote:
I thought the idea was that we were going to add PL/proxy to 8.5, with
support for the foriegn data wrapper syntax? What happened to that?
Using SQL/MED for defining pl/proxy clusters is still in the TODO list.
I hope to do something about
On Dec 9, 2009, at 8:32 AM, Zdenek Kotala zdenek.kot...@sun.com wrote:
Greg Smith píše v út 08. 12. 2009 v 22:44 -0500:
Zdenek Kotala wrote:
thanks for your useful comments. I attached new doc patch
version. I
removed example changes and add link to create database cluster (I
hope)
[moved to -hackers]
On tor, 2009-11-12 at 22:37 +0200, Marko Kreen wrote:
On 11/12/09, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
You talked about blocking in quickdie(), but you'd need
to block in elog().
I'm not really particularly worried about that
Bernd Helmle píše v út 08. 12. 2009 v 22:06 +0100:
--On 8. Dezember 2009 15:51:52 -0500 Greg Smith g...@2ndquadrant.com
wrote:
Try this instead, which will give you a test where checkpoints have a
minimal impact, but lots of memory will be thrown around:
pgbench -i -s 10 db
On ons, 2009-12-09 at 08:56 -0500, Ing. Marcos Ortiz Valmaseda wrote:
Which is the development state of SQL/MED?
That depends on what features of SQL/MED you are interested in. As you
could read upthread, PL/Proxy support is being worked on. Dblink
supports it in 8.4. The next step might be
Robert Haas píše v st 09. 12. 2009 v 08:56 -0500:
On Dec 9, 2009, at 8:32 AM, Zdenek Kotala zdenek.kot...@sun.com wrote:
snip
Ahh, It is somethink what I want to do, but it is not ready yet in
this
patch, but I already documented it. Idea is to install initdb and
postgres into
Peter Eisentraut pete...@gmx.net writes:
Yeah, on reflection, calling elog in the SIGQUIT handler is just waiting
for trouble. The call could block for any number of reasons, because
there is a boatload of functionality that comes with a logging call. In
the overall scheme of things, you
Jaime Casanova jcasa...@systemguards.com.ec writes:
i haven't made any performance tests but it should gain something :),
maybe someone can make those tests?
The argument for changing this at all is only that it will improve
performance, so I'd like some independent confirmation that it does.
Fujii Masao masao.fu...@gmail.com writes:
On Wed, Dec 9, 2009 at 3:58 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
But if everyone is happy with just relying on the OS buffer to not fill
up, let's just drop it.
The OS buffer is expected to be able to store a large number
Tatsuo,
Ok. Your suggestion is very helpfull. In general Tsutomu will wait for
feedbacks come in, probably until Jan 15th.
BTW, is there anyone who wishes the patches get in 8.5? Apparently
Tstutomu, Magnus and I are counted in the group:-) But I'd like to
know how other people are
BTW, is there anyone who wishes the patches get in 8.5? Apparently
Tstutomu, Magnus and I are counted in the group:-) But I'd like to
know how other people are interested in the patches.
I am very interested. A 64bit-Windows-Version would give a boost
perception-wise
I'm also very
2009/12/7 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
Came cross this when updating the cvs fix. We declare size requirements as:
Also check that you have sufficient disk space. You will need about
65 MB for the source tree during compilation and about MB
2009/12/9 Tatsuo Ishii is...@postgresql.org:
Ok. Your suggestion is very helpfull. In general Tsutomu will wait for
feedbacks come in, probably until Jan 15th.
Of course there's also no rule that you couldn't review these sooner -
that might help get the ball rolling!
Of course I did
Magnus Hagander mag...@hagander.net writes:
Perhaps we should just add it to the release checklist to verify that
they are reasonably correct?
Go for it. Now that you mention it, there are some memory-usage tables
in the documentation about shared memory configuration that also have
a pretty
2009/12/9 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
Perhaps we should just add it to the release checklist to verify that
they are reasonably correct?
Go for it. Now that you mention it, there are some memory-usage tables
in the documentation about shared
Magnus Hagander wrote:
2009/12/9 Tom Lane t...@sss.pgh.pa.us:
Magnus Hagander mag...@hagander.net writes:
Perhaps we should just add it to the release checklist to verify that
they are reasonably correct?
Go for it. Now that you mention it, there are some memory-usage tables
in the
On sön, 2009-12-06 at 19:50 -0500, Greg Smith wrote:
The fact that you're asking the question this way suggests to me I've
named this completely wrong. pg_stat_reset_global only resets the
bits
global to all databases. It doesn't touch any of the
database-specific
things that
On mån, 2009-12-07 at 09:53 +0100, Albe Laurenz wrote:
I would start with the TODO list: http://wiki.postgresql.org/wiki/Todo
These are things for which there is a consensus that it would be
a good idea to implement them.
The Todo list is not a list of things for which such a consensus exists.
On Tuesday 08 December 2009 17:15:36 Kevin Grittner wrote:
Andres Freund and...@anarazel.de wrote:
Could you show your testcase?
OK. I was going to try to check other platforms first, and package
up the information better, but here goes.
I created 1 lines with random IP-based URLs
Tom Lane wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
i haven't made any performance tests but it should gain something :),
maybe someone can make those tests?
The argument for changing this at all is only that it will improve
performance, so I'd like some independent
Peter Eisentraut wrote:
But unless the item is linked to a mailing
list thread that already shows a consensus about the feature, you need
to start with a discussion about a plan.
And realistically, even if the item is so linked, someone new to the
project still shouldn't just plow away on it
Hi,
I compiled current HEAD and trying to use pgbench, i initialized a
test database this way:
bin/pgbench -i -F80 -s100 test
and then run with this options:
bin/pgbench -c 50 -j 5 -l -t 20 test
and get this crash:
starting vacuum...end.
TRAP: FailedAssertion(!((data - start) == data_size),
I have just noticed while checking the EXPLAIN YAML patch that the
non-text explain formats are output as a single line with embedded line
feeds, while the text format is delivered as a set of text records, one
per line. The practical effect of this is that psql decorates the
non-text format
On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
I have just noticed while checking the EXPLAIN YAML patch that the non-text
explain formats are output as a single line with embedded line feeds, while
the text format is delivered as a set of text records, one per line.
This is a C front end for the LLVM compiler... I noticed that it
entered Debian/Unstable today:
http://packages.debian.org/sid/main/clang
I thought it would be interesting to see if PostgreSQL compiles with
this, as an alternative compiler that should presumably become more and
more available
Chris Browne wrote:
I suspect there's something about PASCAL that's a problem, as clang is
nominally supposed to be a C compiler ;-).
Pascal refers to a way of different way of pushing things onto the
stack when calling things; there's Pascal order and c order when you
call a function,
On Dec 9, 2009, at 4:23 PM, Chris Browne wrote:
This is a C front end for the LLVM compiler... I noticed that it
entered Debian/Unstable today:
http://packages.debian.org/sid/main/clang
I thought it would be interesting to see if PostgreSQL compiles with
this, as an alternative
Robert Haas wrote:
On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander mag...@hagander.net wrote:
2009/12/9 Bruce Momjian br...@momjian.us:
I frankly think the patch should be thought of as the SE-Linux-specific
directory files, which KaiGai can maintain, and the other parts, which I
think I
Robert Haas wrote:
On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
I have just noticed while checking the EXPLAIN YAML patch that the non-text
explain formats are output as a single line with embedded line feeds, while
the text format is delivered as a set of text
As a reference for the future, please let us know when you have done
this before the patch is submitted. I think it's not very common that
just because you are in the same company, you have reviewed it. For
example, I highly doubt that Heikki reviews all the patches Bruce
post, or the other
On Dec 8, 2009, at 5:10 AM, Zdenek Kotala wrote:
Dne 8.12.09 00:27, Bernd Helmle napsal(a):
--On 13. November 2009 23:29:41 +0100 Zdenek Kotala zdenek.kot...@sun.com
wrote:
t contains two DTrace probe groups. One is related to monitoring SLRU
and second is about executor nodes.
I
Bruce Momjian wrote:
Robert Haas wrote:
On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander mag...@hagander.net wrote:
2009/12/9 Bruce Momjian br...@momjian.us:
I frankly think the patch should be thought of as the SE-Linux-specific
directory files, which KaiGai can maintain, and the other parts,
The other day I returned idly to thinking about some work I did a few
years ago on creating a totally unprivileged user, i.e. one with not
even public permissions. The work I did then involved hacking the
pg_catalog, information_schema and public schemas and their contents.
Unfortunately, it
On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote:
If you want to avoid all good reasons for this features and are looking
for reasons why this patch is a bad idea, I am sure you can find them.
You seem to be suggesting that our reactions are pure obstructionism,
or that they
On Tue, Dec 8, 2009 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
patch attached.
I cannot get this patch to apply for anything. All 4 hunks fail, both
on HEAD and on the the pre-8.4-pgindent
Why does this patch #ifdef out the _PG_fini code in pg_stat_statements?
Where you check for INSERT, UPDATE, and DELETE return codes in
pgss_ProcessUtility, I think this deserves a comment explaining that
these could occur as a result of EXECUTE. It wasn't obvious to me,
anyway.
It seems to me
Robert Haas robertmh...@gmail.com wrote:
Why does this patch #ifdef out the _PG_fini code in pg_stat_statements?
That's because _PG_fini is never called in current releases.
We could remove it completely, but I'd like to leave it for future
releases where _PG_fini callback is re-enabled.
Or,
On Wed, Dec 9, 2009 at 9:33 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Robert Haas robertmh...@gmail.com wrote:
Why does this patch #ifdef out the _PG_fini code in pg_stat_statements?
That's because _PG_fini is never called in current releases.
We could remove it completely,
On Wed, Dec 9, 2009 at 9:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 8, 2009 at 9:45 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
patch attached.
I cannot get this patch to apply for
Robert Haas robertmh...@gmail.com wrote:
Like this?
/*
* Parse command tag to retrieve the number of affected rows.
* COPY command returns COPY tag. EXECUTE command might return INSERT,
* UPDATE, or DELETE tags, but we cannot retrieve the number of rows
* for SELECT. We assume
On Wed, Dec 9, 2009 at 10:14 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
I'm confused by the we cannot retrieve the number of rows for SELECT
part. Can you clarify that?
Ah, I meant the SELECT was EXECUTE of SELECT.
If I use internal structure names, the explanation will be:
Robert Haas wrote:
On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian br...@momjian.us wrote:
If you want to avoid all good reasons for this features and are looking
for reasons why this patch is a bad idea, I am sure you can find them.
You seem to be suggesting that our reactions are pure
Andrew Dunstan and...@dunslane.net writes:
The other day I returned idly to thinking about some work I did a few
years ago on creating a totally unprivileged user, i.e. one with not
even public permissions.
And the point would be what exactly?
regards, tom lane
--
Hi, I'm reviewing LO-AC patch.
KaiGai Kohei kai...@ak.jp.nec.com wrote:
Nothing are changed in other codes, including something corresponding to
in-place upgrading. I'm waiting for suggestion.
I have a question about the behavior -- the patch adds ownership
management of large objects.
While testing the pgbench setshell command patch with -j option,
I found all threads use the same sequence of random value.
At first, I think we need to call srandom() in each thread,
but the manual says we should use random_r() instead of random()
on multi-threaded programs.
On ons, 2009-12-09 at 15:18 +0100, Zdenek Kotala wrote:
Robert Haas píše v st 09. 12. 2009 v 08:56 -0500:
On Dec 9, 2009, at 8:32 AM, Zdenek Kotala zdenek.kot...@sun.com wrote:
snip
Ahh, It is somethink what I want to do, but it is not ready yet in
this
patch, but I already
On Thu, Dec 10, 2009 at 12:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
The OS buffer is expected to be able to store a large number of
XLogRecPtr messages, because its size is small. So it's also OK
to just drop it.
It certainly seems to be something we could improve later, when and
if
On Wed, 2009-12-09 at 21:00 -0500, Robert Haas wrote:
Done. Yeah, my first commit!
:)
I think you forgot to update release notes for 8.4.2 :(
--
Devrim GÜNDÜZ, RHCE
Command Prompt - http://www.CommandPrompt.com
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
Takahiro Itagaki wrote:
Hi, I'm reviewing LO-AC patch.
KaiGai Kohei kai...@ak.jp.nec.com wrote:
Nothing are changed in other codes, including something corresponding to
in-place upgrading. I'm waiting for suggestion.
I have a question about the behavior -- the patch adds ownership
2009/12/9 Robert Haas robertmh...@gmail.com:
On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan and...@dunslane.net wrote:
I have just noticed while checking the EXPLAIN YAML patch that the non-text
explain formats are output as a single line with embedded line feeds, while
the text format is
61 matches
Mail list logo
