On 13/09/10 08:10, Fujii Masao wrote:
On Mon, Sep 13, 2010 at 12:32 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Huh? walsender has no business applying any per-user or per-database
settings.
Okay. I got rid of the access to pg_db_role_setting from the patch.
I attached the updated version, which
On 12/09/10 20:13, Jeff Davis wrote:
On Sun, 2010-09-12 at 12:29 -0400, Tom Lane wrote:
... why throw an ERROR there if it can't happen (or
indicates an inconsistent state when it does happen)?
Are you suggesting that an Assert would be sufficient?
I'm not too picky about whether it's
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
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
On 13/09/10 05:49, Robert Haas wrote:
On Mon, Sep 6, 2010 at 10:55 PM, Robert Haasrobertmh...@gmail.com 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
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
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 called.
This
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
On 18 August 2010 22:45, Kevin Grittner kevin.gritt...@wicourts.gov 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
2010/9/13 KaiGai Kohei kai...@ak.jp.nec.com:
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
On 13 September 2010 12:40, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On 13 September 2010 12:47, Thom Brown t...@linux.com wrote:
On 13 September 2010 12:40, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
On 13/09/10 14:47, Thom Brown wrote:
On 13 September 2010 12:40, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Sep 13, 2010 at 5:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Sep 13, 2010 at 7:44 AM, Thom Brown t...@linux.com 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:
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
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us 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
(2010/09/13 20:46), Robert Haas wrote:
2010/9/13 KaiGai Koheikai...@ak.jp.nec.com:
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
On Mon, Sep 13, 2010 at 8:38 AM, KaiGai Kohei kai...@kaigai.gr.jp 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
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
-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 Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada umi.tan...@gmail.com 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
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
Robert Haas robertmh...@gmail.com 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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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.
On 13/09/10 18:19, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us 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
Michael Haggerty mhag...@alum.mit.edu 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
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
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
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 13 September 2010 17:27, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc 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
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 points
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
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:
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
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Sep 12, 2010 at 11:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Having completed that comparison, I then moved on to trying to get rid of
the discrepancies in the git conversion;
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
alvhe...@commandprompt.com 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.
On Mon, Sep 13, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 13, 2010 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wonder if we should consider fixing some or all of these things on
the
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
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
alvhe...@commandprompt.com 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.
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
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
+++
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?
---
On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
+1 on both -- fixing the broken tags, and creating the missing tags,
particularly since you already
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 13, 2010 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us 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
On Mon, Sep 13, 2010 at 19:14, Robert Haas robertmh...@gmail.com wrote:
On Mon, Sep 13, 2010 at 12:50 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, Sep 13, 2010 at 18:31, Tom Lane t...@sss.pgh.pa.us 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.
snip
* The REL8_0_0 branch needs to be downgraded to a tag, as previously
discussed.
Yeah, and that's
Magnus Hagander mag...@hagander.net 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
On Mon, Sep 13, 2010 at 9:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
The patch attached is based on the one rejected at the last CF for 9.0
last year.
On Mon, Sep 13, 2010 at 2:43 PM, Merlin Moncure mmonc...@gmail.com 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 *) any query using foo
Understood.
IOW, your CTE query has to be a select.
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 make
On Mon, Sep 13, 2010 at 21:28, Tom Lane t...@sss.pgh.pa.us 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
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 br...@momjian.ushttp://momjian.us
Joe Conway m...@joeconway.com 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
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
Bruce Momjian br...@momjian.us 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
On Tue, Sep 14, 2010 at 12:35 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
2010/9/14 Merlin Moncure mmonc...@gmail.com:
On Mon, Sep 13, 2010 at 9:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Sep 13, 2010 at 9:15 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
The patch attached is based on the one rejected at the last CF for 9.0
last year.
On Tue, Sep 14, 2010 at 12:10 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Mon, Sep 6, 2010 at 7:55 PM, Robert Haas robertmh...@gmail.com 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
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
itagaki.takah...@gmail.com wrote:
On Fri, Aug 13, 2010 at 7:33 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
Updated patch: the
On Mon, Sep 13, 2010 at 9:13 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
On Mon, Sep 13, 2010 at 9:06 PM, Rob Wultsch wult...@gmail.com wrote:
On Mon, Sep 6, 2010 at 7:55 PM, Robert Haas robertmh...@gmail.com 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.
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
68 matches
Mail list logo
