On 8/2/13 4:48 PM, Stephen Frost wrote:
* Josh Berkus (j...@agliodbs.com) wrote:
I really think this is the wrong approach. If we start removing
"unsafe" parameters from ALTER SYSTEM SET, we basically hobble the
feature to the point of uselessness. Out of the 15 or so parameters 80%
of our use
Alvaro,
I applied the patch and tried upgrading again, and everything seemed to
work as expected. We are now up and running the beta!
--
Jesse Denardo
On Fri, Aug 2, 2013 at 10:25 PM, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> > >
On 2013-08-02 22:25:36 -0400, Alvaro Herrera wrote:
> Andres Freund escribió:
> > On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> > > Alvaro Herrera escribió:
> > >
> > > > As it turns out, I have a patched slru.c that adds a new function to
> > > > verify whether a page exists on disk. I c
On Fri, Aug 2, 2013 at 11:20:37PM -0400, Jesse Denardo wrote:
> Alvaro,
>
> I applied the patch and tried upgrading again, and everything seemed to work
> as
> expected. We are now up and running the beta!
Yeah, great, thanks everyone!
--
Bruce Momjian http://momjian.us
Enterpris
(2013/08/03 8:47), Josh Berkus wrote:
Given that we can expect to be dealing with more patches per CF in the
future, I'd like some feedback about what things would make the CF
process more efficient. For that matter, for the first time we tried
enforcing some of the "rules" of CFs this time, and
Andres Freund escribió:
> On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> > Alvaro Herrera escribió:
> >
> > > As it turns out, I have a patched slru.c that adds a new function to
> > > verify whether a page exists on disk. I created this for the commit
> > > timestamp module, for the BDR b
On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
> Alvaro Herrera escribió:
>
> > As it turns out, I have a patched slru.c that adds a new function to
> > verify whether a page exists on disk. I created this for the commit
> > timestamp module, for the BDR branch, but I think it's what we need
On 1 August 2013 18:01, Dimitri Fontaine wrote:
> Hi,
>
> Please find attached to this email the latest and greatest version of
> in-line SQL only extensions support, known as "Extension Templates" and
> which could be renamed "In-Catalog Extension Templates".
>
> I've included a high-level descr
On Fri, Aug 2, 2013 at 03:55:27PM -0700, Josh Berkus wrote:
> On 08/02/2013 03:18 PM, Bruce Momjian wrote:
> >> You're making a big deal out of what's a minor clerical detail. Don't
> >> let minutia which any secretary could take care of get in the way of an
> >> important project goal, that is,
On 08/02/2013 04:47 PM, Josh Berkus wrote:
> Folks,
>
> The first CF for the 9.4 development cycle is officially over.
Also, I wanted to say "thank you" to:
- Mike Blackwell, assistant CFM
- all 30+ reviewers and committers (list to come)
--
Josh Berkus
PostgreSQL Experts Inc.
h
Folks,
The first CF for the 9.4 development cycle is officially over.
In all, 49 patches were committed, 47 were returned with feedback, 6
were rejected outright, and 6 were punted to CF2. We're 17 days over
the CF deadline at this point, but that's unsurprising considering that
this CF included
On 08/02/2013 03:45 PM, Tom Lane wrote:
>> So, Returned With Feedback, or move it to September?
>
> The patch is certainly not getting committed as-is (at least not by me),
> so it would likely be fair to mark it RWF so we can close the commitfest.
> I'll still work on a revised version after the
On 08/02/2013 03:18 PM, Bruce Momjian wrote:
>> You're making a big deal out of what's a minor clerical detail. Don't
>> let minutia which any secretary could take care of get in the way of an
>> important project goal, that is, rewarding reviewers so that lack of
>> reviewers stops being a major
Josh Berkus writes:
>> Reading between the lines of the original submission at
>> ,
>> I gather that it's the KNNGist-style case that worries you, so maybe
>> it's worth applying this type of patch anyway. I'd want to rejigger
>> it to be aware of the cost implications though, at least for
>> gro
On Fri, Aug 2, 2013 at 02:36:42PM -0700, Josh Berkus wrote:
> On 08/02/2013 02:24 PM, Bruce Momjian wrote:
>
> > Based on existing workflow, we need those reviewer names in the commit
> > message. I don't see how the CommitFestManager can help with that.
>
> We can change the workflow. It's ou
Alvaro Herrera escribió:
> As it turns out, I have a patched slru.c that adds a new function to
> verify whether a page exists on disk. I created this for the commit
> timestamp module, for the BDR branch, but I think it's what we need
> here.
Here's a patch that should fix the problem. Jesse,
> Reading between the lines of the original submission at
> ,
> I gather that it's the KNNGist-style case that worries you, so maybe
> it's worth applying this type of patch anyway. I'd want to rejigger
> it to be aware of the cost implications though, at least for
> grouping_planner's choices.
Tomas Vondra wrote:
> I'm learning how to use the "background worker processes" commited in
> 9.3. The usage basics are quite nicely illustrated in the worker_spi
> extension (kudos to those who designed the feature / extension).
Thanks!
> I'm not quite sure how to pass data between the regular
On 08/02/2013 02:23 PM, Bruce Momjian wrote:
> I don't think dumping reviewer names at the bottom of the 9.3 release
> notes is what the majority want, and it seems like an ugly short-term
> solution.
It's better than not crediting the reviewers *at all*, which is the only
alternative I can think
On 08/02/2013 02:24 PM, Bruce Momjian wrote:
> Based on existing workflow, we need those reviewer names in the commit
> message. I don't see how the CommitFestManager can help with that.
We can change the workflow. It's ours, there's no government agency
mandating it.
Anyway, the list from the
Craig Ringer wrote:
> A SELECT ... FOR SHARE will incorrectly block on another open
> transaction that ran SELECT ... FOR SHARE and still holds the locks if
> it has to follow a ctid chain from the current snapshot through a
> committed update to a share-locked tuple.
>
> This also affects unique
On Fri, Aug 2, 2013 at 02:07:53PM -0700, Josh Berkus wrote:
> On 08/02/2013 01:56 PM, Bruce Momjian wrote:
> > On Fri, Aug 2, 2013 at 04:43:30PM -0400, Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>> On Fri, Jul 12, 2013 at 12:18:15PM -0700, Joshua D. Drake wrote:
> >>
> Right cause if
On Fri, Aug 2, 2013 at 02:10:17PM -0700, Josh Berkus wrote:
> Bruce, all:
>
> Per previous email, I wanted to make a specific proposal for what to do
> on the 9.3 release notes. This is because, without policy set, we have
> not been tracking which reviewers make "substantial changes" in 9.3, an
Bruce, all:
Per previous email, I wanted to make a specific proposal for what to do
on the 9.3 release notes. This is because, without policy set, we have
not been tracking which reviewers make "substantial changes" in 9.3, and
listing some-but-not-all of them would cause a lot of unhappiness amo
On 08/02/2013 01:56 PM, Bruce Momjian wrote:
> On Fri, Aug 2, 2013 at 04:43:30PM -0400, Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>>> On Fri, Jul 12, 2013 at 12:18:15PM -0700, Joshua D. Drake wrote:
>>
Right cause if a reviewer ends up writing (or cleaning up) all the
docs, I would s
On Fri, Aug 2, 2013 at 04:43:30PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Fri, Jul 12, 2013 at 12:18:15PM -0700, Joshua D. Drake wrote:
>
> > > Right cause if a reviewer ends up writing (or cleaning up) all the
> > > docs, I would say they deserve very close to equal credit. As
* Josh Berkus (j...@agliodbs.com) wrote:
> I really think this is the wrong approach. If we start removing
> "unsafe" parameters from ALTER SYSTEM SET, we basically hobble the
> feature to the point of uselessness. Out of the 15 or so parameters 80%
> of our users touch, half of them are on your
Bruce Momjian wrote:
> On Fri, Jul 12, 2013 at 12:18:15PM -0700, Joshua D. Drake wrote:
> > Right cause if a reviewer ends up writing (or cleaning up) all the
> > docs, I would say they deserve very close to equal credit. As an
> > example.
>
> I can do whatever we agree to in the release notes.
On Fri, Jul 12, 2013 at 12:18:15PM -0700, Joshua D. Drake wrote:
>
> On 07/12/2013 10:49 AM, Andrew Dunstan wrote:
> >
> >
> >On 07/12/2013 01:28 PM, Alvaro Herrera wrote:
> >>Josh Berkus wrote:
> >>
> >>>-- a couple of compromise proposals were made:
> >>>
> >>>a) that reviewers who do actual cod
Stephen Frost writes:
> * Josh Berkus (j...@agliodbs.com) wrote:
>> A much simpler solution to the issue Stephen proposes is to have a way
>> to start up the server with all settings from ALTER SYSTEM SET disabled,
>> just like some software allows you to start it up in "safe mode".
> See above f
"Etsuro Fujita" writes:
> Thank you for the adjustments and comments! In addition to adding comments to
> the function, I've improved the code in the function a little bit. Please
> find
> attached an updated version of the patch.
I started looking at this patch (finally). I'm not terribly sa
* Josh Berkus (j...@agliodbs.com) wrote:
> On 08/02/2013 07:54 AM, Stephen Frost wrote:
> > Curiously, I've not heard any argument about what parameters are "safe"
> > and what aren't, though I was asked which ones I thought were safe and
> > which weren't. Perhaps looking at the specific options
I just realized I mixed two different (but related) cases in my previous
email:
Alvaro Herrera wrote:
> Does the combination in $SUBJECT make sense? It is currently allowed,
> but of course the underlying locks only last while the creating
> transaction is open, and they are reacquired during a r
On 08/02/2013 07:54 AM, Stephen Frost wrote:
> Curiously, I've not heard any argument about what parameters are "safe"
> and what aren't, though I was asked which ones I thought were safe and
> which weren't. Perhaps looking at the specific options that would
> likely cause PG to not start would b
Alvaro Herrera wrote:
> Does the combination in $SUBJECT make sense?
I don't think so; I don't know what it would mean.
> It is currently allowed,
I will take a look.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing li
Stephen Frost escribió:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > What if you set a combination of parameters that prevents Postgres from
> > starting?
>
> This was what I was trying to get at up-thread. Things that prevent PG
> from being able to start (or, really, which cause PG to be starte
Does the combination in $SUBJECT make sense? It is currently allowed,
but of course the underlying locks only last while the creating
transaction is open, and they are reacquired during a refresh.
Somewhat related is that the error message they emit is a bit
nonstandard:
cannot lock rows in mate
Dear pgsql-hackers,
We students of International Institute of Information Technology Bangalore
India, are interested to contribute to PostgreSQL development. We identified
some modules from ToDo list to which we want to contribute.We want to begin
with an simple module with less dependency lik
Dimitri Fontaine escribió:
> Andres Freund writes:
> > They would need a setting that disables ALTER (DATABASE|USER) ... SET
> > ... as well though. At least for some settings.
> >
> > I don't think enforcing things on that level makes much sense.
>
> If only we could trigger some actions when a
Greg,
* Greg Stark (st...@mit.edu) wrote:
> Writing out each guc in a separate file is a singularly bad idea. It's
> going out of our way to confuse users about what's going on and how
> they're expected to interact with the settings files and it actively
> makes it harder or nearly impossible to
While looking at the GIN's partial match logic, I got an idea to let the generic
index code do what opclass-specific comparePartial() functions do. It can be
achieved if range type is accepted as key entry.
In this patch I add ANYRANGEARRAY pseudotype (note that changes in
parse_coerce.c are rathe
Robert Haas escribió:
> On Wed, Jul 31, 2013 at 1:26 PM, Fujii Masao wrote:
> > I encountered the following assertion failure when I executed
> > an immediate shutdown.
> >
> > LOG: received immediate shutdown request
> > WARNING: terminating connection because of crash of another server process
Merlin Moncure escribió:
> On Fri, Aug 2, 2013 at 7:22 AM, Andrew Tipton wrote:
> > On Fri, Aug 2, 2013 at 8:12 PM, Robert Haas wrote:
> >>
> >> +1, but I'm wondering why we need anything more than just
> >> json_typeof(). Doesn't that pretty much cover it?
> >
> > I agree with Merlin that json_
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What if you set a combination of parameters that prevents Postgres from
> starting?
This was what I was trying to get at up-thread. Things that prevent PG
from being able to start (or, really, which cause PG to be started in a
completely different mode, al
On Wed, Jul 31, 2013 at 6:49 AM, Pavel Golub wrote:
> Hello, PostgreSQL.
>
> Let's assume we have created MATERIALIZED VIEW, e.g.
>
> CREATE MATERIALIZED VIEW customer_v AS SELECT ;
>
> Then one wants to redefine this view as a regular view, e.g.
>
> CREATE OR REPLACE VIEW customer_v AS ;
Sent from my iPad
On 02-Aug-2013, at 10:30, Bruce Momjian wrote:
> On Mon, Jul 8, 2013 at 06:25:44PM -0700, Peter Geoghegan wrote:
>> When rebasing a patch that I'm working on, I occasionally forget to
>> update the oid of any pg_proc.h entries I may have created. Of course
>> this isn't a re
On 8/1/13 10:47 AM, David Johnston wrote:
Minor request: could someone enlighten me as to why making the directory
location a compile-time option is undesirable.
The ongoing argument here is whether to allow moving the directory at
all, or to make it fixed to $PGDATA the way recovery.conf is.
Writing out each guc in a separate file is a singularly bad idea. It's
going out of our way to confuse users about what's going on and how
they're expected to interact with the settings files and it actively
makes it harder or nearly impossible to protect against simple
failures.
1) The whole reas
On 2013-08-02 08:41:09 -0400, Stephen Frost wrote:
> Perhaps having the file be a heap file instead of anything a sysadmin
> can be asked to go hack would also make it more clear that this is an
> internal PG file which is to be managed only through PG and stop all
> this arguing about how "oh, the
On 7/29/13 3:46 PM, Josh Berkus wrote:
Based on the ongoing discussion of this patch, I have moved it to 9.4CF2
(9-2013).
Mind you, it would be good to commit some version of it before September.
Quite a bit of the patch adds some refactored GUC parameter validation
code that seems necessary
On Wed, Jul 31, 2013 at 5:50 AM, Etsuro Fujita
wrote:
> Attached is a small typo fix patch.
Committed. Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Stephen Frost writes:
> Perhaps having the file be a heap file instead of anything a sysadmin
> can be asked to go hack would also make it more clear that this is an
> internal PG file which is to be managed only through PG and stop all
> this arguing about how "oh, they can just fix it by twiddli
Hi,
I'm very new here on this mailing list, but I've been using PostgreSQL
for a while, and it scares me a little, that it's a real pain to try to
recover data from corrupted table.
Situations like file being lost following server crash (after fsck) or
page corruption happens quite often.
H
On Fri, Aug 2, 2013 at 7:22 AM, Andrew Tipton wrote:
> On Fri, Aug 2, 2013 at 8:12 PM, Robert Haas wrote:
>>
>> +1, but I'm wondering why we need anything more than just
>> json_typeof(). Doesn't that pretty much cover it?
>
>
> I agree with Merlin that json_is_object() is superfluous, since it
* Amit Kapila (amit.kap...@huawei.com) wrote:
> > This is an internal-to-PG data file and we should really implement it
> > in whichever way makes the most sense for us. My general feeling is
> > that one file is simpler and sufficient for the postgresql.conf-like
> > parameters,
>
> Sure, I als
On Friday, August 02, 2013 5:19 PM Stephen Frost wrote:
> * Amit Kapila (amit.kap...@huawei.com) wrote:
> > Below are some points in my mind due to which I have
> > supported/implemented one-file-all-setting approach:
> > a. I had heard quite a few times that Postgres has lot of files (each
> > rel
On Fri, Aug 2, 2013 at 8:12 PM, Robert Haas wrote:
> +1, but I'm wondering why we need anything more than just
> json_typeof(). Doesn't that pretty much cover it?
>
I agree with Merlin that json_is_object() is superfluous, since it can just
be replaced with json_typeof() = 'object'. Likewise f
On Wed, Jul 31, 2013 at 1:26 PM, Fujii Masao wrote:
> I encountered the following assertion failure when I executed
> an immediate shutdown.
>
> LOG: received immediate shutdown request
> WARNING: terminating connection because of crash of another server process
> DETAIL: The postmaster has com
On Fri, Aug 2, 2013 at 8:17 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 26, 2013 at 8:27 AM, Tom Lane wrote:
>>> would you expect crash recovery to notice the disappearance of a file
>>> that was touched nowhere in the replayed actions?
>
>> Eh, maybe not. But should we try harder
Robert Haas writes:
> On Fri, Jul 26, 2013 at 8:27 AM, Tom Lane wrote:
>> would you expect crash recovery to notice the disappearance of a file
>> that was touched nowhere in the replayed actions?
> Eh, maybe not. But should we try harder to detect the unexpected
> disappearance of one that is?
On Tue, Jul 30, 2013 at 3:10 AM, Gibheer wrote:
> here is an update off my patch based on the discussion with Marko
> Tiikkaja and Andres Freund.
>
> Marko and I had the idea of introducing reserved connections based on
> roles as it would create a way to garantuee specific roles to connect
> when
On Mon, Jul 29, 2013 at 5:36 PM, Merlin Moncure wrote:
> On Mon, Jul 29, 2013 at 2:16 AM, Andrew Tipton wrote:
>> The attached patch adds four new SQL functions for the JSON type:
>> json_typeof(json) RETURNS text
>> json_is_object(json) RETURNS boolean
>> json_is_array(json) RETURNS
On Fri, Jul 26, 2013 at 8:27 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-07-26 13:33:13 +0900, Satoshi Nagayasu wrote:
>>> Is this expected or acceptable?
>
>> I'd say it's both.
>
> Postgres is built on the assumption that the underlying filesystem is
> reliable, ie, once you've succe
* Amit Kapila (amit.kap...@huawei.com) wrote:
> Yes, this can be viable option to ignore variable values that don't allow
> server to start, also I agree with you that
> this can be a separate patch.
I disagree that this can be a separate patch. Adding an option to not
allow certain GUCs from
* Amit Kapila (amit.kap...@huawei.com) wrote:
> Below are some points in my mind due to which I have supported/implemented
> one-file-all-setting approach:
> a. I had heard quite a few times that Postgres has lot of files (each
> relation has separate file) as compare to Oracle.
>Users feel tha
On Friday, August 02, 2013 4:17 PM Cédric Villemain wrote:
Le vendredi 2 août 2013 09:23:17, Amit Kapila a écrit :
> On Friday, August 02, 2013 8:57 AM Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
>> > > FWIW, I think you've just put the final nail in the coffin of this
On Thursday, August 01, 2013 8:37 PM Andres Freund wrote:
> Hi,
>
> On 2013-08-01 15:40:22 +0100, Greg Stark wrote:
> > Why isn't it enough to just dump out all variables with a source of
> alter
> > system to a text file? You can either have a single global lock
> around that
> > operation or wri
Le vendredi 2 août 2013 09:23:17, Amit Kapila a écrit :
> On Friday, August 02, 2013 8:57 AM Stephen Frost wrote:
> > * Andres Freund (and...@2ndquadrant.com) wrote:
> > > FWIW, I think you've just put the final nail in the coffin of this
> > > patch by raising the barriers unreasonably high.
> >
On Fri, Jul 26, 2013 at 6:28 PM, Tom Lane wrote:
>
>
> I think we could do with both more documentation, and better error
> messages for these cases. In the SET-where-you-should-use-ADD case,
> perhaps
>
> ERROR: option "use_remote_estimate" has not been set
> HINT: Use ADD not SET to define a
Michael Paquier writes:
> By reading this thread, -1 for the addition of a new GUC parameter related
> to cascading, it looks like an overkill for the possible gain. And +1 for
> the removal of WAL file once it is replayed in archive recovery if
> cascading replication is not allowed. However, wha
FOR SHARE|UPDATE NOWAIT will still block if they have to follow a ctid
chain because the call to EvalPlanQualFetch doesn't take a param for
noWait, so it doesn't know not to block if the updated row can't be locked.
The attached patch against master includes an isolationtester spec to
demonstrate
On Friday, August 02, 2013 8:57 AM Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > FWIW, I think you've just put the final nail in the coffin of this
> > patch by raising the barriers unreasonably high.
>
> For my 2c, I don't think it's an unreasonable idea to actually
>
72 matches
Mail list logo
