On Sun, Jul 17, 2011 at 10:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, Jul 15, 2011 at 6:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd say send the signal when wal buffers are more than X% full (maybe
half). The suggestion to send it when
On Mon, Jul 18, 2011 at 2:20 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 15, 2011 at 7:23 AM, Simon Riggs si...@2ndquadrant.com wrote:
My additional requests would be that we can easily tell which blocks
have been modified like this, that we have a way to turn this off if
we get
On Mon, Jul 18, 2011 at 1:48 AM, Robert Haas robertmh...@gmail.com wrote:
Might be good to start a new thread for each auxilliary process, or we
may get confused.
+1
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Hello, Andrew.
I hope you don't mind I've added this patch to CommitFest:
https://commitfest.postgresql.org/action/patch_view?id=606
You wrote:
AC On 6/3/2011 10:26 PM, Andrew Chernow wrote:
I disagree -- I think the fix is a one-liner. line 446:
if (tup_num == res-ntups
Hello, Merlin.
I hope it's OK that I've added Andrew's patch to CommitFest:
https://commitfest.postgresql.org/action/patch_view?id=606
I did this becuase beta3 already released, but nut nothig is done on
this bug.
You wrote:
MM On Thu, Jun 23, 2011 at 7:54 AM, Andrew Chernow a...@esilo.com
On sön, 2011-07-17 at 18:39 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Add temp_file_limit GUC parameter to constrain temporary file space
usage.
The limit is enforced against the total amount of temp file space used by
On 18 July 2011 01:48, Robert Haas robertmh...@gmail.com wrote:
Might be good to start a new thread for each auxilliary process, or we
may get confused.
Right - I've done so in this reply. There isn't a problem as such with
the AV Launcher patch - there's a problem with most or all remaining
On Jul18, 2011, at 15:12 , Peter Geoghegan wrote:
struct timeval is comprised of two longs - one representing seconds,
and the other represented the balance of microseconds. Previously, we
didn't combine them into a single microsecond representation. Now, we
do.
I haven't actually looked at
On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Another concern is, what happens when we receive a signal, generically
handled or otherwise, and have to SetLatch() to avoid time-out
invalidation? Should we just live with a spurious
AutoVacLauncherMain() iteration,
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
There could perhaps be a very large nap, as determined by
launcher_determine_sleep(), so that the total number of microseconds
passed to WaitLatch() would exceed the
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
Huh? Seems like a waste of text to me. What else would happen?
Well, if we exceed work_mem, we spill to temp disk. If we exceed temp
disk, we error out. Those different behaviors don't seem obvious to me.
[ shrug... ] Feel free to
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 17, 2011 at 12:59 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I agree custom_variable_classes is conceptually messy, but it's a
reasonably lightweight compromise that gives some error checking without
requiring a lot of possibly-irrelevant
Simon Riggs si...@2ndquadrant.com writes:
On Sun, Jul 17, 2011 at 10:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, I agree with putting the actual SetLatch call after we release the
lock ... but doesn't the calculation need to be done while we're still
holding it? Otherwise it'd be using
On Thu, Jul 7, 2011 at 3:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 7, 2011 at 3:21 PM, Noah Misch n...@2ndquadrant.com wrote:
On Thu, Jul 07, 2011 at 03:06:46PM -0400, Robert Haas wrote:
On Thu, Jul 7, 2011 at 2:55 PM, Noah Misch n...@2ndquadrant.com wrote:
On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan pe...@2ndquadrant.com
wrote:
There could perhaps be a very large nap, as determined by
launcher_determine_sleep(), so that the total
Hello KaiGai-san,
I've been preparing to review this patch by reading both pgsql-hackers
history on sepgsql, and also the RHEL 6 guide on SELinux this weekend,
today I installed GIT HEAD with --with-selinux on Scientific Linux 6,
developer installation, so far almost everything looking good.
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
A wakeup once every half hour would surely not be an issue from a power
consumption standpoint. However, I'm not sure I understand here: aren't
we trying to remove the timeouts
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Noah Misch wrote:
With this patch in its final form, I have completed 180+ suite
runs without a failure.
The attached patch allows the tests to pass when
default_transaction_isolation is stricter than 'read committed'.
Without
I wrote:
Michael Meskes mes...@postgresql.org writes:
Made ecpglib write double with a precision of 15 digits.
Patch originally by Akira Kurosawa kurosawa-ak...@mxc.nes.nec.co.jp.
I think you missed the 9.1 branch.
... not to mention that the buildfarm is now failing ecpg-check
everywhere
On Mon, Jul 18, 2011 at 12:16:50PM -0400, Tom Lane wrote:
... not to mention that the buildfarm is now failing ecpg-check
everywhere ...
I seem to have messed up my local make check call, sorry, working on the fix.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot
Hi!
New version of patch is attached. There are following changes.
1) Since proposed tchnique is not always a fast build, it was renamed
everywhere in the patch to buffering build.
2) Parameter buffering now has 3 possible values yes, no and auto.
auto means automatic switching from regular index
Excerpts from Jim Nasby's message of dom jul 17 16:31:45 -0400 2011:
On a somewhat related note, I'd also really like to have the ability to parse
things like .sql files externally, to do things like LINT checking.
We talked about this during PGCon. The idea that seemed to have
consensues
Hello Tom,
Thank you for review
I am thinking, so your comment is clean and I'll respect it in new version.
There is only one issue, that should be solved first. I introduced non
standard diagnostics field column_names, because there is not
possible get column_name value for check constraints
Pavel Stehule pavel.steh...@gmail.com writes:
2011/7/14 Alvaro Herrera alvhe...@commandprompt.com:
Thanks ... I expect you're going to resubmit the patch based on David's
last version and my comments?
yes, see a attachment
Applied with some editorial adjustments.
On Mon, Jul 18, 2011 at 3:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Jul 18, 2011 at 2:20 AM, Robert Haas robertmh...@gmail.com
wrote:
On Fri, Jul 15, 2011 at 7:23 AM, Simon Riggs si...@2ndquadrant.com
wrote:
My additional requests would be that we can easily tell which blocks
Pavel Stehule pavel.steh...@gmail.com writes:
There is only one issue, that should be solved first. I introduced non
standard diagnostics field column_names, because there is not
possible get column_name value for check constraints now. A correct
implementation of COLUMN_NAME field needs a
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
On Mon, Jul 4, 2011 at 10:22 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
I'll try to submit a revised patch within the next couple days.
Sorry this is later than I said.
I addressed the issues covered in
On 18.07.2011 18:32, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Mon, Jul 18, 2011 at 10:35 AM, Tom Lanet...@sss.pgh.pa.us wrote:
A wakeup once every half hour would surely not be an issue from a power
consumption standpoint. However, I'm not sure I understand here: aren't
Tom,
No, I don't. You're adding complication to solve a problem that doesn't
need to be solved. The standard says to return the name of the
constraint for a constraint-violation failure. It does not say anything
about naming the associated column(s). COLUMN_NAME is only supposed to
be
On Mon, Jul 11, 2011 at 12:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of dom jul 10 21:21:19 -0400 2011:
On Jul 9, 2011, at 10:49 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
In short: in my opinion, attoptions and attfdwoptions need
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 18.07.2011 18:32, Tom Lane wrote:
Hmm. Well, it's not too late to rethink the WaitLatch API, if we think
that that might be a significant limitation.
Right, we can easily change the timeout argument to be in milliseconds
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
I'm having a really hard time figuring out how the JSON module should
handle non-Unicode character sets.
But, again, why not just forget about transcoding and define it as
Josh Berkus j...@agliodbs.com writes:
Tom,
No, I don't. You're adding complication to solve a problem that doesn't
need to be solved. The standard says to return the name of the
constraint for a constraint-violation failure. It does not say anything
about naming the associated column(s).
Robert Haas robertmh...@gmail.com writes:
... I think we should understand
attoptions as things that modify the behavior of PostgreSQL, while
attfdw/genoptions are there solely for the foreign data wrapper to
use. An extra nullable field in pg_attribute isn't costing us
anything non-trivial,
On Mon, Jul 18, 2011 at 03:12:20PM -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 18.07.2011 18:32, Tom Lane wrote:
Hmm. Well, it's not too late to rethink the WaitLatch API, if we think
that that might be a significant limitation.
Right, we
On Mon, Jul 18, 2011 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
... I think we should understand
attoptions as things that modify the behavior of PostgreSQL, while
attfdw/genoptions are there solely for the foreign data wrapper to
use. An extra
2011/7/18 Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com writes:
Tom,
No, I don't. You're adding complication to solve a problem that doesn't
need to be solved. The standard says to return the name of the
constraint for a constraint-violation failure. It does not say anything
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams joeyadams3.14...@gmail.com
wrote:
I'm having a really hard time figuring out how the JSON module should
handle non-Unicode character sets.
On Mon, Jul 18, 2011 at 3:28 PM, k...@rice.edu k...@rice.edu wrote:
On Mon, Jul 18, 2011 at 03:12:20PM -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 18.07.2011 18:32, Tom Lane wrote:
Hmm. Well, it's not too late to rethink the WaitLatch API, if we
Pavel Stehule pavel.steh...@gmail.com writes:
2011/7/18 Tom Lane t...@sss.pgh.pa.us:
Are we talking about FK constraints here, or CHECK contstraints?
Either one. They both have the potential to reference more than one
column, so if the committee had meant errors to try to identify the
On Fri, Jul 15, 2011 at 5:05 PM, Josh Berkus j...@agliodbs.com wrote:
As you can probably tell, we are not ready to end the commitfest. (I
think Robert gave me this CF to show why even talking about a one-week
mini-fest is a fantasy. If so, successful.).
Heh, heh. Well, it wasn't that
2011/7/18 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
2011/7/18 Tom Lane t...@sss.pgh.pa.us:
Are we talking about FK constraints here, or CHECK contstraints?
Either one. They both have the potential to reference more than one
column, so if the committee had
On Fri, Jul 15, 2011 at 10:05 PM, Josh Berkus j...@agliodbs.com wrote:
PATCHES WHICH HAVE BEEN UPDATED AND NEED FURTHER REVIEW:
* Cascade Replication
Sorry, too busy reviewing to take note of this. I expect to commit
when its tested and ready.
--
Simon Riggs
Robert Haas robertmh...@gmail.com writes:
We're down to three patches that fall into this category: two XML
patches by Florian, which have been somewhat derailed by an argument
about whether values of type xml should, in fact, be required to be
valid xml (I think you know my vote on this
Yeb, Thanks for your volunteering.
2011/7/18 Yeb Havinga yebhavi...@gmail.com:
Hello KaiGai-san,
I've been preparing to review this patch by reading both pgsql-hackers
history on sepgsql, and also the RHEL 6 guide on SELinux this weekend, today
I installed GIT HEAD with --with-selinux on
On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
3) sepgsql is currently a bit hard to find in the documentation.
www.postgresql.org website search doesn't find sepgsql and selinux only
refers to an old PostgreSQL redhat bug in 2005 on bugzilla.redhat.com. I had
to
Pavel Stehule pavel.steh...@gmail.com writes:
so for example, NULL or DOMAIN constraints doesn't affect a
COLUMN_NAME? These constraints has no name.
Well, the executor's NOT NULL tests could certainly be extended to emit
COLUMN_NAME --- I don't see any logical or implementation problem with
2011/7/18 Robert Haas robertmh...@gmail.com:
On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
3) sepgsql is currently a bit hard to find in the documentation.
www.postgresql.org website search doesn't find sepgsql and selinux only
refers to an old PostgreSQL redhat bug
Tom,
Either one. They both have the potential to reference more than one
column, so if the committee had meant errors to try to identify the
referenced columns, they'd have put something other than COLUMN_NAME
into the standard. They didn't.
I'm less concerned about the standard here and
Simon,
* Cascade Replication
Sorry, too busy reviewing to take note of this. I expect to commit
when its tested and ready.
So, would that be this commitfest, or next commitfest?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
Robert,
* Collect frequency statistics and selectivity estimation for arrays
* Allow multiple Postgres clusters running on the same machine to
distinguish themselves in the event log
* lazy vxid locks
I'm not clear on your criteria for moving these patches, as they seem
to be in somewhat
Josh Berkus j...@agliodbs.com wrote:
I'm less concerned about the standard here and more concerned
about what helps our users. Having column names for an FK error
is *extremely* useful for troubleshooting, particularly if the
database has been upgraded from the 7.4 days and has non-useful
On Mon, Jul 18, 2011 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
and an
error-reporting patch that Tom weighed in on over the weekend. This
last suffers from the issue that it's not quite clear whether Tom is
going to do the work or whether he's expecting the submitter to do it.
If you
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, could the \u problem be finessed by leaving such escapes in
source form?
Yes, it could. However, it doesn't solve the problem of comparison
(needed for member lookup), which requires canonicalizing the strings
to be
On 19/07/11 02:36, Tom Lane wrote:
Bruce Momjianbr...@momjian.us writes:
Tom Lane wrote:
Huh? Seems like a waste of text to me. What else would happen?
Well, if we exceed work_mem, we spill to temp disk. If we exceed temp
disk, we error out. Those different behaviors don't seem obvious
On Jul 18, 2011, at 12:29 AM, Robert Haas wrote:
On Fri, Jul 8, 2011 at 11:13 AM, Stuart Bishop stu...@stuartbishop.net
wrote:
On Mon, Jun 6, 2011 at 7:50 AM, Jim Nasby j...@nasby.net wrote:
On Jun 4, 2011, at 3:56 AM, Greg Stark wrote:
On Thu, Jun 2, 2011 at 8:58 PM, Jim Nasby
Jim,
Right; you need a timestamp and you need to know what timezone that timestamp
was entered in. That means you can always convert that time to whatever
timezone you'd like (like timestamptz), but you also know what time was
originally entered, and what timezone it was entered in.
On Jul18, 2011, at 22:19 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
We're down to three patches that fall into this category: two XML
patches by Florian, which have been somewhat derailed by an argument
about whether values of type xml should, in fact, be required to be
valid
Tom, Florian,
On the downside, the current behaviour prevents problems if someone changes
two interrelated GUCs, but makes a mistake at one of them. For example,
someone might drastically lower bgwriter_delay but might botch the matching
adjustment of bgwriter_lru_maxpages.
That's a fair
On Jul18, 2011, at 22:19 , Tom Lane wrote:
and an
error-reporting patch that Tom weighed in on over the weekend. This
last suffers from the issue that it's not quite clear whether Tom is
going to do the work or whether he's expecting the submitter to do it.
If you mean the business about
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Josh Berkus j...@agliodbs.com wrote:
I'm less concerned about the standard here and more concerned
about what helps our users. Having column names for an FK error
is *extremely* useful for troubleshooting, particularly if the
database has
On Jul19, 2011, at 00:17 , Joey Adams wrote:
I suppose a simple solution would be to convert all escapes and
outright ban escapes of characters not in the database encoding.
+1. Making JSON work like TEXT when it comes to encoding issues
makes this all much simpler conceptually. It also avoids
Excerpts from Josh Berkus's message of lun jul 18 18:37:15 -0400 2011:
The timestamp and the timezone in which that timestamp was entered are
two separate pieces of data and *ought* to be in two separate fields.
For one thing, the question of what timezone was this entered in is an
On Mon, Jul 18, 2011 at 02:05:42PM -0400, Alvaro Herrera wrote:
Excerpts from Jim Nasby's message of dom jul 17 16:31:45 -0400 2011:
On a somewhat related note, I'd also really like to have the
ability to parse things like .sql files externally, to do things
like LINT checking.
We
Excerpts from Pavel Stehule's message of lun jul 18 16:02:43 -0400 2011:
2011/7/18 Tom Lane t...@sss.pgh.pa.us:
which suggests that it might be meant *only* for use with
INSUFFICIENT_PRIVILEGE errors that are thrown due to a column ACL.
We can probably extend that to some other syntax
We talked about this during PGCon. The idea that seemed to have
consensues there was to export the parser similarly to how we build
the ecpg parser, that is, a set of perl scripts which take our
gram.y as input and modify it to emit something different.
That solves the non-customized part
On Sun, Jul 17, 2011 at 11:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jul 2, 2011 at 8:37 PM, Josh Kupershmidt schmi...@gmail.com wrote:
On Sun, Jun 19, 2011 at 11:59 AM, Josh Kupershmidt schmi...@gmail.com
wrote:
It seems funny to have is_system = true unconditionally for any
On Mon, Jul 18, 2011 at 10:57 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Well, I was hoping to go by the existing psql backslash commands'
notions about what qualifies as system and what doesn't; that worked
OK for commands which supported the 'S' modifier, but not all do. For
objects like
Has anyone successfully used pg_upgrade 9.0 with -l (log) on Windows?
I received a private email bug report that pg_upgrade 9.0 does not work
with the -l/log option on Windows. The error is:
Analyzing all rows in the new cluster
c:/MinGW/msys/1.0/home/edb/inst/bin/vacuumdb
On mån, 2011-07-18 at 11:05 -0400, Robert Haas wrote:
On Thu, Jul 7, 2011 at 3:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jul 7, 2011 at 3:21 PM, Noah Misch n...@2ndquadrant.com wrote:
On Thu, Jul 07, 2011 at 03:06:46PM -0400, Robert Haas wrote:
On Thu, Jul 7, 2011 at 2:55 PM,
On Mon, 2011-07-18 at 15:59 -0400, Robert Haas wrote:
On a pgbench run with 8
clients on a 32-core machine, I see about a 2% speedup from that patch
on pgbench -S, and it grows to 8% at 32 clients. At 80 clients (but
still just a 32-core box), the results bounce around more, but taking
the
On Mon, July 18, 2011 11:28 pm, Bruce Momjian wrote:
Has anyone successfully used pg_upgrade 9.0 with -l (log) on Windows?
I received a private email bug report that pg_upgrade 9.0 does not work
with the -l/log option on Windows. The error is:
Analyzing all rows in the new cluster
On sön, 2011-07-17 at 00:59 -0400, Tom Lane wrote:
Well, we *do* have a C API for that, of a sort. The problem is, what
do you do in processes that have not loaded the relevant extension?
Those processes that have the extension loaded check the parameter
settings in their namespace, those that
73 matches
Mail list logo
