Just wondering, will the planned range type functionality also be able
to absorb the functionality of the ip4r type as a range of the ip4 type
(http://pgfoundry.org/projects/ip4r)? Maybe it's trivial, but since the
ip types also have a kind of hierarchical structure, I figured I'd point
it out in
On Tue, Jul 19, 2011 at 11:44 AM, Simon Riggs wrote:
> Cascading replication feature for streaming log-based replication.
> Standby servers can now have WALSender processes, which can work with
> either WALReceiver or archive_commands to pass data. Fully updated
> docs, including new conceptual te
Since we are accepting host names in pg_hba.conf now, I figured it could
be useful to also show the host names in error message, e.g.,
no pg_hba.conf entry for host "localhost" (127.0.0.1), user "x", database
"y"
Attached is an example patch. The question might be what criterion to
use for
Here's a patch to fix what has been discussed:
* Change EDITOR_LINENUMBER_SWITCH to environment variable.
* I also changed "switch" to "arg" because "switch" is a bit of a
sloppy term.
* So the environment variable is called
PSQL_EDITOR_LINENUMBER_ARG.
* Set
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 tha
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 cluste
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
> t
On mån, 2011-07-18 at 11:05 -0400, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 3:25 PM, Robert Haas wrote:
> > On Thu, Jul 7, 2011 at 3:21 PM, Noah Misch 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 wrote:
> >>> > Check
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" --p
On Mon, Jul 18, 2011 at 10:57 PM, Josh Kupershmidt 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 tablespaces,
On Sun, Jul 17, 2011 at 11:25 PM, Robert Haas wrote:
> On Sat, Jul 2, 2011 at 8:37 PM, Josh Kupershmidt wrote:
>> On Sun, Jun 19, 2011 at 11:59 AM, Josh Kupershmidt
>> wrote:
> It seems funny to have is_system = true unconditionally for any object
> type. Why'd you do it that way? Or maybe I
>> 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-customi
Excerpts from Pavel Stehule's message of lun jul 18 16:02:43 -0400 2011:
> 2011/7/18 Tom Lane :
> > 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 errors, like unk
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.
>
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
> appli
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
"Kevin Grittner" writes:
> Josh Berkus 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
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 busines
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
On Jul18, 2011, at 22:19 , Tom Lane wrote:
> Robert Haas 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
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. Tec
On Jul 18, 2011, at 12:29 AM, Robert Haas wrote:
> On Fri, Jul 8, 2011 at 11:13 AM, Stuart Bishop
> wrote:
>> On Mon, Jun 6, 2011 at 7:50 AM, Jim Nasby wrote:
>>> On Jun 4, 2011, at 3:56 AM, Greg Stark wrote:
On Thu, Jun 2, 2011 at 8:58 PM, Jim Nasby wrote:
>
> I'm torn between wh
On 19/07/11 02:36, Tom Lane wrote:
Bruce Momjian 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...
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane 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 compared.
Here's
On Mon, Jul 18, 2011 at 4:19 PM, 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 b
Josh Berkus 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 FK
> names like
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
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 (pgsq
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 an
2011/7/18 Robert Haas :
> On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai 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.
Pavel Stehule 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
that, even if it seems t
On Mon, Jul 18, 2011 at 4:21 PM, Kohei KaiGai 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 manually remembe
Yeb, Thanks for your volunteering.
2011/7/18 Yeb Havinga :
> 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,
Robert Haas 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 one...);
Yeah, it's no
On Fri, Jul 15, 2011 at 10:05 PM, Josh Berkus 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 http://www.2ndQuadrant.com/
2011/7/18 Tom Lane :
> Pavel Stehule writes:
>> 2011/7/18 Tom Lane :
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
>>> referenc
On Fri, Jul 15, 2011 at 5:05 PM, Josh Berkus 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 premeditated, but I'
Pavel Stehule writes:
> 2011/7/18 Tom Lane :
>>> 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
>> referenced columns, they'd have put s
On Mon, Jul 18, 2011 at 3:28 PM, k...@rice.edu wrote:
> On Mon, Jul 18, 2011 at 03:12:20PM -0400, Tom Lane wrote:
>> Heikki Linnakangas 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 signif
On Mon, Jul 18, 2011 at 3:19 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams
>> 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
2011/7/18 Tom Lane :
> Josh Berkus 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 asso
On Mon, Jul 18, 2011 at 3:26 PM, Tom Lane wrote:
> Robert Haas 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 i
On Mon, Jul 18, 2011 at 03:12:20PM -0400, Tom Lane wrote:
> Heikki Linnakangas 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 time
Robert Haas 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, and the syntacti
Josh Berkus 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). COLUMN_NA
Robert Haas writes:
> On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams
> 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
> "JSON, if you happen to be using utf-8
Heikki Linnakangas 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
> instead of microseconds.
On the
On Mon, Jul 11, 2011 at 12:11 AM, Alvaro Herrera
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
>> wrote:
>> > In short: in my opinion, attoptions and attfdwoptions need to be one
>> > thing and the same.
>>
>> I fee
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
> b
On 18.07.2011 18:32, Tom Lane wrote:
Robert Haas writes:
On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane 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 complete
On Fri, Jul 15, 2011 at 3:56 PM, Joey Adams wrote:
> On Mon, Jul 4, 2011 at 10:22 PM, Joseph Adams
> 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 the review. I also fixed a bug
> where "\u0022
Pavel Stehule 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 explicit relation
On Mon, Jul 18, 2011 at 3:14 AM, Simon Riggs wrote:
> On Mon, Jul 18, 2011 at 2:20 AM, Robert Haas
> wrote:
> > On Fri, Jul 15, 2011 at 7:23 AM, Simon Riggs
> wrote:
> >> My additional requests would be that we can easily tell which blocks
> >> have been modified like this, that we have a way t
Pavel Stehule writes:
> 2011/7/14 Alvaro Herrera :
>> 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.
regards, tom lane
--
Sent via pgsql-hackers m
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 constraint
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 t
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
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
I wrote:
> Michael Meskes writes:
>> Made ecpglib write double with a precision of 15 digits.
>> Patch originally by Akira Kurosawa .
> I think you missed the 9.1 branch.
... not to mention that the buildfarm is now failing ecpg-check
everywhere ...
regards, tom lane
--
"Kevin Grittner" 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 these two patches the
Robert Haas writes:
> On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane 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 completely?
> Well, in the case of th
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.
On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan
>> 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(
On Thu, Jul 7, 2011 at 3:25 PM, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 3:21 PM, Noah Misch 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 wrote:
>>> > CheckIndexCompatible() calls ComputeIndexAttrs() to resolve the new
Simon Riggs writes:
> On Sun, Jul 17, 2011 at 10:41 PM, Tom Lane 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 potentially-inconsistent values.
>
Robert Haas writes:
> On Sun, Jul 17, 2011 at 12:59 AM, Tom Lane 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 extensions to be loaded into
>> every
Bruce Momjian 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 change it.
Robert Haas writes:
> On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan
> 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 maximum long size that can be
>> safely
On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan 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, or should
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 a
On 18 July 2011 01:48, Robert Haas 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
auxiliary processes, t
On sön, 2011-07-17 at 18:39 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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
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 wrote:
>>> you
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&& !res->t
On Mon, Jul 18, 2011 at 1:48 AM, Robert Haas 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
--
Sent via pgsql-hacke
On Mon, Jul 18, 2011 at 2:20 AM, Robert Haas wrote:
> On Fri, Jul 15, 2011 at 7:23 AM, Simon Riggs 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 bugs for next few releases, that we c
76 matches
Mail list logo
