Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> the tarball was actually made. In particular, the tags REL6_5, REL7_1,
> >> and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
> >> lot of faith in some of the other early tags either, because we don't seem
>
On Mon, Sep 13, 2010 at 9:06 PM, Rob Wultsch wrote:
> On Mon, Sep 6, 2010 at 7:55 PM, Robert Haas wrote:
>>
>> 3. With respect to unlogged tables, the major obstacle seems to be
>> figuring out a way for these to get automatically truncated at startup
>> time.
>
> (please forgive what is probably
On 09/13/2010 09:30 PM, Itagaki Takahiro wrote:
Hi,
Anyone working on JSON datatype?
If no, I'm going to submit simplified version of JSON datatype patch.
What's the state of the GSOC project?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On Mon, Sep 13, 2010 at 9:13 PM, Heikki Linnakangas
wrote:
> Here's an updated patch with those bugs fixed.
Great!
+ /*
+* Walreceiver sets this latch every time new WAL has been received and
+* fsync'd to disk, allowing startup process to wait for new WAL to
+* arr
Hi,
Anyone working on JSON datatype?
If no, I'm going to submit simplified version of JSON datatype patch.
On Wed, Aug 25, 2010 at 2:34 PM, Itagaki Takahiro
wrote:
> On Fri, Aug 13, 2010 at 7:33 PM, Joseph Adams
> wrote:
>> Updated patch: the JSON code has all been moved into core, so this
>>
On Mon, Sep 6, 2010 at 7:55 PM, Robert Haas wrote:
> 3. With respect to unlogged tables, the major obstacle seems to be
> figuring out a way for these to get automatically truncated at startup
> time.
>
(please forgive what is probably a stupid question)
By truncate do mean reduce the table to a
On Tue, Sep 14, 2010 at 12:10 AM, Heikki Linnakangas
wrote:
> Yet another idea: Check in pg_ctl if recovery.conf is also present. If it
> is, assume we're in recovery and don't print that warning. That would be
> dead simple. I would even consider backpatching it to 9.0, this can be
> regarded as
2010/9/14 Merlin Moncure :
> On Mon, Sep 13, 2010 at 9:20 AM, Robert Haas wrote:
>> On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada wrote:
>>> The patch attached is based on the one rejected at the last CF for 9.0
>>> last year.
>>>
>>> http://archives.postgresql.org/message-id/16303.1266023...@s
On Tue, Sep 14, 2010 at 12:35 AM, Heikki Linnakangas
wrote:
> Hmm, looking at this more closely, I'm a bit confused. We already rename
> away backup_label at the beginning of recovery. Under what circumstances do
> we have a problem? This starts to seem like a complete non-issue to me.
A checkpoi
Bruce Momjian writes:
> Tom Lane wrote:
>> the tarball was actually made. In particular, the tags REL6_5, REL7_1,
>> and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
>> lot of faith in some of the other early tags either, because we don't seem
>> to have an archived tarb
Tom Lane wrote:
> the tarball was actually made. In particular, the tags REL6_5, REL7_1,
> and REL7_1_2 don't match the tarballs they ought to. I don't have a whole
> lot of faith in some of the other early tags either, because we don't seem
> to have an archived tarball to compare them to.
I be
>Joe Conway wrote:
> Committed.
Thanks!
I'm pulling together a new version of the main patch, and it is
almost 300 lines shorter and touches five fewer files than the last
version because this went in. It should be easier for people to
scan to understand the substance of the changes without
Can someone update the PostgreSQL shared memory usage table for 9.0?
http://www.postgresql.org/docs/9.0/static/kernel-resources.html#SYSVIPC
Right now it says "Approximate shared memory bytes required (as of
8.3)".
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Mon, Sep 13, 2010 at 21:28, Tom Lane wrote:
> I wrote:
>> return bool(re.match(
>> r'file .* was added on branch .* on '
>> r'\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2}( [\+\-]\d{4})?'
>> '\n$',
>> log_msg,
>> ))
>
>> So it looks like I have to make the
I wrote:
> return bool(re.match(
> r'file .* was added on branch .* on '
> r'\d{4}\-\d{2}\-\d{2} \d{2}\:\d{2}\:\d{2}( [\+\-]\d{4})?'
> '\n$',
> log_msg,
> ))
> So it looks like I have to make the dead revisions' log messages match
> that regexp. Off to
On Mon, Sep 13, 2010 at 2:43 PM, Merlin Moncure wrote:
> Just to be clear, the attached patch is missing the part of the wCTE
> that allows queries of the form:
> WITH foo AS (DELETE * FROM bar RETURNING *)
Understood.
> IOW, your CTE query has to be a select. This is still highly useful
> how
On Mon, Sep 13, 2010 at 9:20 AM, Robert Haas wrote:
> On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada wrote:
>> The patch attached is based on the one rejected at the last CF for 9.0
>> last year.
>>
>> http://archives.postgresql.org/message-id/16303.1266023...@sss.pgh.pa.us
>>
>> This patch impl
Magnus Hagander writes:
> Yeah, let's not touch the CVS side, but definitely +1 for dropping
> them from git (in fact, my script does this automatically if I just
> let it run through all the steps, which I've repeatedly not done which
> is why they've sometimes shown up and sometimes not in the o
On Mon, Sep 13, 2010 at 18:31, Tom Lane wrote:
> This is an attempt to sum up the open issues remaining before we can
> make another try at converting our source code to git.
> * The REL8_0_0 branch needs to be downgraded to a tag, as previously
> discussed.
Yeah, and that's easily done.
> *
On Mon, Sep 13, 2010 at 19:14, Robert Haas wrote:
> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
> wrote:
>> Excerpts from Tom Lane's message of lun sep 13 12:31:53 -0400 2010:
>>
>>> * As I noted previously, up till about 2003 we were quite haphazard about
>>> applying CVS tags to identify t
Robert Haas writes:
> On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane wrote:
>> Well, the other side of that argument is that changing these things in
>> the CVS repository will be overwriting the available evidence, in case
>> any questions come up later. On the git side, applying the tag to the
>> a
On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
>> wrote:
>>> +1 on both -- fixing the broken tags, and creating the missing tags,
>>> particularly since you already seem to have found out the necessary
>>> dates for the
On 13/09/10 20:43, Jeff Davis wrote:
On Mon, 2010-09-13 at 09:10 +0300, Heikki Linnakangas wrote:
but we should be consistent and document that:
(a) it shouldn't happen
(b) that it's just a sanity check and we're ignoring the race
Would this be sufficient?
--- a/src/backend/port/unix_la
On Mon, 2010-09-13 at 09:10 +0300, Heikki Linnakangas wrote:
> > but we should be consistent and document that:
> > (a) it shouldn't happen
> > (b) that it's just a sanity check and we're ignoring the race
>
> Would this be sufficient?
>
> --- a/src/backend/port/unix_latch.c
> +++ b/src/backe
I wrote:
> I'm a bit disappointed by the fact that we get either of these. I had
> gathered from Max's comments that the dead-revision-at-the-base-of-the-
> branch trick is considered standard in newer CVS versions, and so I'd
> hoped that cvs2git would understand the construct and not generate
>
Robert Haas writes:
> On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
> wrote:
>> +1 on both -- fixing the broken tags, and creating the missing tags,
>> particularly since you already seem to have found out the necessary
>> dates for the missing tags.
> +1 from me, too. I don't agree with sta
On 09/13/2010 06:43 PM, Greg Smith wrote:
Thom Brown wrote:
I thought sysbench was designed for MySQL benchmarks. How new is the
PostgreSQL driver? Is it stable yet?
It's been out there for years; the FreeBSD 7.0 development used it
extensively on MySQL and PostgreSQL to track kernel performan
On Mon, Sep 13, 2010 at 1:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
>>> Robert Haas writes:
I wonder if we should consider fixing some or all of these things on
the master CVS repository. I wouldn't be too eager to inject those
On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
wrote:
> Excerpts from Tom Lane's message of lun sep 13 12:31:53 -0400 2010:
>
>> * As I noted previously, up till about 2003 we were quite haphazard about
>> applying CVS tags to identify the points where releases were made. Should
>> we try to cl
Robert Haas writes:
> On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I wonder if we should consider fixing some or all of these things on
>>> the master CVS repository. I wouldn't be too eager to inject those
>>> fake .0 commits for fear of breakage, but moving tag
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane wrote:
>>> Having completed that comparison, I then moved on to trying to get rid of
>>> the discrepancies in the git conversion; particularly, trying to get rid
>>> of the "manu
Excerpts from Tom Lane's message of lun sep 13 12:31:53 -0400 2010:
> * As I noted previously, up till about 2003 we were quite haphazard about
> applying CVS tags to identify the points where releases were made. Should
> we try to clean that up? I think there is a stronger case for moving the
>
Thom Brown wrote:
I thought sysbench was designed for MySQL benchmarks. How new is the
PostgreSQL driver? Is it stable yet?
It's been out there for years; the FreeBSD 7.0 development used it
extensively on MySQL and PostgreSQL to track kernel performance on both
databases back in 2007:
On 13/09/10 19:31, Tom Lane wrote:
* If we do the above, should it be done in the existing CVS repository
or just as part of the conversion to git? (I suspect it'd be a lot easier
in git.) Similarly, ought we to fix the now-known tagging inconsistencies
in the CVS repository, or just leave it f
On Mon, 2010-09-13 at 12:31 -0400, Tom Lane wrote:
> This is an attempt to sum up the open issues remaining before we can
> make another try at converting our source code to git.
>
> * As I noted previously, up till about 2003 we were quite haphazard about
> applying CVS tags to identify the point
On 13 September 2010 17:27, Stefan Kaltenbrunner
wrote:
> On 09/13/2010 06:05 PM, Greg Smith wrote:
>>
>> Domas Mituzas wrote:
>>>
>>> I've been playing around today a lot with sysbench, and observed that
>>> 2.6.32 kernel supplied by Ubuntu is having perf regression with PG
>>> (which does not af
This is an attempt to sum up the open issues remaining before we can
make another try at converting our source code to git.
* As I noted previously, up till about 2003 we were quite haphazard about
applying CVS tags to identify the points where releases were made. Should
we try to clean that up?
On 09/13/2010 06:05 PM, Greg Smith wrote:
Domas Mituzas wrote:
I've been playing around today a lot with sysbench, and observed that
2.6.32 kernel supplied by Ubuntu is having perf regression with PG
(which does not affect MySQL), compared to 2.6.28 builds I have.
What I observed can be seen in
Domas Mituzas wrote:
I've been playing around today a lot with sysbench, and observed that 2.6.32
kernel supplied by Ubuntu is having perf regression with PG (which does not
affect MySQL), compared to 2.6.28 builds I have.
What I observed can be seen in a paste at http://p.defau.lt/?8_GQV82Pz3_
Michael Haggerty writes:
> On 09/13/2010 03:14 AM, Tom Lane wrote:
>> Now as far as I can tell, the branch was made immediately before those
>> test commits you can see Marc making in each branch. In particular,
>> it was definitely made *after* Bryan deleted the src/bin/monitor files,
>> because
Robert Haas writes:
> On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane wrote:
>> Having completed that comparison, I then moved on to trying to get rid of
>> the discrepancies in the git conversion; particularly, trying to get rid
>> of the "manufactured commits". I didn't have much success in that fo
On 13/09/10 18:19, Tom Lane wrote:
Heikki Linnakangas writes:
Yet another idea: Check in pg_ctl if recovery.conf is also present. If
it is, assume we're in recovery and don't print that warning. That would
be dead simple.
+1. This sounds like a much more appropriate approach.
Hmm, looking
Heikki Linnakangas writes:
> Yet another idea: Check in pg_ctl if recovery.conf is also present. If
> it is, assume we're in recovery and don't print that warning. That would
> be dead simple.
+1. This sounds like a much more appropriate approach.
regards, tom lane
--
On 13/09/10 16:01, Heikki Linnakangas wrote:
On 13/09/10 13:08, Fujii Masao wrote:
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-05/msg00921.php
(2)
pg_ctl -ms stop emits the following warning whenever there is the
backup_label file in $PGDATA.
WARNING: online backup mode is active
Sh
Robert Haas writes:
> Regrettably, all of your attachments came through as part of the
> actual email, both in my GMail and in the archives. I hate
> technology.
Sorry about that. Here's another try with the stuff in a tarball.
This time, I also remembered to include cvs2git.options; although
I
http://www.sigaev.ru/misc/builtin_knngist_core-0.9.gz
http://www.sigaev.ru/misc/builtin_knngist_itself-0.8.2.gz
http://www.sigaev.ru/misc/builtin_knngist_proc-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_contrib_pg_trgm-0.8.gz
http://www.sigaev.ru/misc/builtin_knngist_contrib_btree_gist-0.8.1.
On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada wrote:
> The patch attached is based on the one rejected at the last CF for 9.0
> last year.
>
> http://archives.postgresql.org/message-id/16303.1266023...@sss.pgh.pa.us
>
> This patch implements the feature that allows top-level DMLs under CTE
> WIT
toplevel-dml-cte.20100913.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 13/09/10 13:08, Fujii Masao wrote:
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-05/msg00921.php
(2)
pg_ctl -ms stop emits the following warning whenever there is the
backup_label file in $PGDATA.
WARNING: online backup mode is active
Shutdown will not complete until pg_
On Mon, Sep 13, 2010 at 8:38 AM, KaiGai Kohei wrote:
> Yes, if and when MAC-X and MAC-Y are installed, it is significant event
> for MAC-X to change X's label, so MAC-X may need to check special
> permissions. But it is a common event for MAC-Y and DAC, so they checks
> an appropriate permission t
(2010/09/13 20:46), Robert Haas wrote:
2010/9/13 KaiGai Kohei:
Robert, although you suggested that only one ESP module shall be
invoked on relabeling an object before, and I agreed this design
at that time, but I noticed that we cannot implement the following
behavior correctly.
SELinux defines
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane wrote:
> I've spent much of the weekend examining the discrepancies between our CVS
> repository and the tarballs available from our FTP archives, and after
> that trying to remove infelicities in the cvs2git output. There are a
> couple of remaining odd
On 13/09/10 14:54, Heikki Linnakangas wrote:
BTW, I noticed that I missed incrementing the latch count in
win32_latch.c, and the owning/disowning the latch was done correctly,
you get an error if you restart the master and reconnect. I'll post an
updated patch shortly.
Here's an updated patch w
On Mon, Sep 13, 2010 at 7:44 AM, Thom Brown wrote:
> So did the materialized views patch not get submitted?
I think someone else will need to pick it up and do a bunch more work
with it before it can be considered a serious candidate for commit.
--
Robert Haas
EnterpriseDB: http://www.enterpris
On Mon, Sep 13, 2010 at 5:24 AM, Heikki Linnakangas
wrote:
> The LSNs on all pages in an unlogged relation should be zero, and
> XLogFlush() will do nothing. That's what we rely on at the moment for pages
> that are not WAL-logged for some reason, I don't think you need any extra
> flag for that.
On 13/09/10 14:47, Thom Brown wrote:
On 13 September 2010 12:40, Heikki Linnakangas
wrote:
Now that we have the wonderful latch facility, let's use it to reduce the
delay between receiving a piece of WAL and applying in the standby.
Currently, the startup process polls every 100ms to see if ne
On 13 September 2010 12:47, Thom Brown wrote:
> On 13 September 2010 12:40, Heikki Linnakangas
> wrote:
>> Now that we have the wonderful latch facility, let's use it to reduce the
>> delay between receiving a piece of WAL and applying in the standby.
>> Currently, the startup process polls every
On 13 September 2010 12:40, Heikki Linnakangas
wrote:
> Now that we have the wonderful latch facility, let's use it to reduce the
> delay between receiving a piece of WAL and applying in the standby.
> Currently, the startup process polls every 100ms to see if new WAL has
> arrived, which adds an
2010/9/13 KaiGai Kohei :
> Robert, although you suggested that only one ESP module shall be
> invoked on relabeling an object before, and I agreed this design
> at that time, but I noticed that we cannot implement the following
> behavior correctly.
>
> SELinux defines these permissions correspondi
On 18 August 2010 22:45, Kevin Grittner wrote:
> At the close of the 2010-07 CommitFest, the numbers were:
>
> 72 patches were submitted
> 3 patches were withdrawn (deleted) by their authors
> 14 patches were moved to CommitFest 2010-09
> --
> 55 patches in CommitFest 2010-07
> --
> 3 committed
Now that we have the wonderful latch facility, let's use it to reduce
the delay between receiving a piece of WAL and applying in the standby.
Currently, the startup process polls every 100ms to see if new WAL has
arrived, which adds an average a 50 ms delay between a transaction
commit in the m
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-05/msg00921.php
>>> (2)
>>> pg_ctl -ms stop emits the following warning whenever there is the
>>> backup_label file in $PGDATA.
>>>
>>> WARNING: online backup mode is active
>>> Shutdown will not complete until pg_stop_backup() is cal
On 12/09/10 23:31, Domas Mituzas wrote:
I've been playing around today a lot with sysbench, and observed that 2.6.32
kernel supplied by Ubuntu is having perf regression with PG (which does not
affect MySQL), compared to 2.6.28 builds I have.
What I observed can be seen in a paste at
http://p.d
On 13/09/10 05:49, Robert Haas wrote:
On Mon, Sep 6, 2010 at 10:55 PM, Robert Haas wrote:
3. With respect to unlogged tables, the major obstacle seems to be
figuring out a way for these to get automatically truncated at startup
time. As with temporary table cleanup in general, the problem here
On 13/09/10 08:10, Fujii Masao wrote:
Okay. I got rid of the access to pg_db_role_setting from the patch.
I attached the updated version, which makes walsender process the
options passed in the startup packet, apply PostAuthDelay and initialize
client encoding.
Thanks, committed.
I moved the c
On 09/13/2010 03:14 AM, Tom Lane wrote:
[...]
Now as far as I can tell, the branch was made immediately before those
test commits you can see Marc making in each branch. In particular,
it was definitely made *after* Bryan deleted the src/bin/monitor files,
because neither of them have REL2_0 or
66 matches
Mail list logo
