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 int
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
On Wed, Dec 9, 2009 at 8:31 AM, Massa, Harald Armin 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 cou
On Wed, Dec 9, 2009 at 10:51 AM, Fujii Masao wrote:
> On Wed, Dec 9, 2009 at 10:12 AM, Tom Lane wrote:
>> Fujii Masao writes:
>>> Thought? Am I missing something?
>>
>> This seems terribly overdesigned. Just emit a warning when you see
>> the "unlogged op" record and have done.
>
> Sounds quite
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. H
On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander wrote:
> 2009/12/9 Bruce Momjian :
>> 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 that's a horribly bad idea.
On Wed, Dec 9, 2009 at 12:36 AM, Takahiro Itagaki
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 lines in sgml.
> http://dev
On Mon, Dec 7, 2009 at 8:48 PM, Tom Lane wrote:
> Alvaro Herrera 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 segment.
>
>> What happens if a rec
>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 wi
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
> > som
[moved to -hackers]
On tor, 2009-11-12 at 09:35 -0500, Tom Lane wrote:
> Peter Eisentraut 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 l
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 i
On Dec 9, 2009, at 8:32 AM, Zdenek Kotala 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)
everywhere. Please, look on
[moved to -hackers]
On tor, 2009-11-12 at 22:37 +0200, Marko Kreen wrote:
> On 11/12/09, Tom Lane wrote:
> > Marko Kreen writes:
> > > You talked about blocking in quickdie(), but you'd need
> > > to block in elog().
> >
> > I'm not really particularly worried about that case. By that logic,
Bernd Helmle píše v út 08. 12. 2009 v 22:06 +0100:
>
> --On 8. Dezember 2009 15:51:52 -0500 Greg Smith
> 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
> > pgbench -S -c 1
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 f
Robert Haas píše v st 09. 12. 2009 v 08:56 -0500:
> On Dec 9, 2009, at 8:32 AM, Zdenek Kotala wrote:
> >
> > 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 libexecdir and packag
Peter Eisentraut 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 don't really lo
Jaime Casanova 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.
reg
Fujii Masao writes:
> On Wed, Dec 9, 2009 at 3:58 PM, Heikki Linnakangas
> 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 of
> XLogRecPtr messages, because its size is sma
> 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 othe
> >> 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
>
>
2009/12/7 Tom Lane :
> Magnus Hagander 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 for
>> the installation direct
2009/12/9 Tatsuo Ishii :
>> > 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 before he p
Magnus Hagander 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 short half-life, an
2009/12/9 Tom Lane :
> Magnus Hagander 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 hav
Magnus Hagander wrote:
> 2009/12/9 Tom Lane :
> > Magnus Hagander 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 shar
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 pg_st
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 exist
On Tuesday 08 December 2009 17:15:36 Kevin Grittner wrote:
> Andres Freund 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 for a test.
Tom Lane wrote:
Jaime Casanova 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.
I'v
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 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. The
> practical
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 functio
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 wrote:
> > 2009/12/9 Bruce Momjian :
> >> 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 th
Robert Haas wrote:
On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan 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 li
> 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 oth
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
>> wrote:
>>> t contains two DTrace probe groups. One is related to monitoring SLRU
>>> and second is about executor nodes.
>>>
>>> I merged it
Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Dec 9, 2009 at 1:44 AM, Magnus Hagander wrote:
>>> 2009/12/9 Bruce Momjian :
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
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 do
On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian 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 have an ulteri
On Tue, Dec 8, 2009 at 9:45 PM, Robert Haas wrote:
> On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian 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 version of fuzzystrmatch
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 th
Robert Haas 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, removing #ifdef (enabl
On Wed, Dec 9, 2009 at 9:33 PM, Takahiro Itagaki
wrote:
> Robert Haas 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
> release
On Wed, Dec 9, 2009 at 9:00 PM, Robert Haas wrote:
> On Tue, Dec 8, 2009 at 9:45 PM, Robert Haas wrote:
>> On Tue, Dec 8, 2009 at 9:08 PM, Bruce Momjian wrote:
>>> Robert Haas wrote:
> patch attached.
I cannot get this patch to apply for anything. All 4 hunks fail, both
on H
Robert Haas 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 other comman
On Wed, Dec 9, 2009 at 10:14 PM, Takahiro Itagaki
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:
>
> EXECUTE co
Robert Haas wrote:
> On Wed, Dec 9, 2009 at 5:38 PM, Bruce Momjian 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
Andrew Dunstan 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
--
Sent via pgsql-ha
Hi, I'm reviewing LO-AC patch.
KaiGai Kohei 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. Non-privileged users canno
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.
http://www.kernel.org
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 wrote:
>
>
> > >
> > > Ahh, It is somethink what I want to do, but it is not ready yet in
> > > this
> > > patch, but I already documented i
On Thu, Dec 10, 2009 at 12:00 AM, Tom Lane 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 evidence emerges
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
http://www.
Takahiro Itagaki wrote:
> Hi, I'm reviewing LO-AC patch.
>
> KaiGai Kohei 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 lar
2009/12/9 Robert Haas :
> On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan 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,
61 matches
Mail list logo
