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,
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
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.
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 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
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
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
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
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
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:
> > 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 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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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)"
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
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
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.
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 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
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
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 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 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
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
> >> 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
>
>
> 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
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
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
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
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
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
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
[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,
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
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
[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
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
>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
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
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 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.
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 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
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
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
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
61 matches
Mail list logo
