Etsuro Fujita wrote:
> While updating the patch, I noticed that in the previous patch, there is
> a bug in pushing down parameterized UPDATE/DELETE queries; generic plans
> for such queries fail with a can't-happen error. I fixed the bug and
> tried to add the regression tests that execute the gen
On 2015/02/16 12:03, Etsuro Fujita wrote:
> I'll update the patch.
While updating the patch, I noticed that in the previous patch, there is
a bug in pushing down parameterized UPDATE/DELETE queries; generic plans
for such queries fail with a can't-happen error. I fixed the bug and
tried to add th
On Tue, Mar 3, 2015 at 8:36 PM, Asif Naeem wrote:
> Thank you Michael. I have looked the patch.
Thanks for the review!
> Overall logic looks good to me,
> I have checked it with MSVC{2013,2008}. It works for MSVC 2013 but fail for
> MSVC 2008, I think the condition "if ($proj =~
> qr{ResourceCom
18.02.2015, 01:49, Jim Nasby kirjoitti:
> On 2/17/15 4:39 PM, Oskari Saarenmaa wrote:
>> 10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
>>> Andres Freund writes:
> In any case, no packager is going to ship an insecure-by-default
> configuration, which is what Dimitri seems to be fantasizin
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: tested, failed
Spec compliant: not tested
Documentation:not tested
Tom suggested few changes already which I too think author needs to addre
On 3/3/15 8:04 PM, Kyotaro HORIGUCHI wrote:
>Note: The OID alias types don't sctrictly comply the transaction
> isolation rules so do not use them where exact transaction
> isolation on the values of these types has a
> significance. Likewise, since they look as simple constants to
> plan
On Wed, Mar 4, 2015 at 12:35 PM, Haribabu Kommi
wrote:
> + foreach(line, parsed_hba_lines)
>
> In the above for loop it is better to add "check_for_interrupts" to
> avoid it looping
> if the parsed_hba_lines are more.
Updated patch is attached with the addition of check_for_interrupts in
the for
On Wed, Mar 4, 2015 at 12:41 AM, Syed, Rahila wrote:
> Please find attached updated patch with WAL replay error fixed. The patch
> follows chunk ID approach of xlog format.
(Review done independently of the chunk_id stuff being good or not,
already gave my opinion on the matter).
* readRecord
On Mon, Feb 23, 2015 at 7:11 AM, Tomas Vondra
wrote:
> On 28.1.2015 05:03, Abhijit Menon-Sen wrote:
> > At 2015-01-27 17:00:27 -0600, jim.na...@bluetreble.com wrote:
> >>
> Otherwise, the code looks OK to me. Now, there are a few features I'd
> like to have for production use (to minimize the impa
On Fri, Dec 26, 2014 at 1:08 PM, Abhijit Menon-Sen
wrote:
>
> At 2014-09-25 15:40:11 +0530, a...@2ndquadrant.com wrote:
> >
> > All right, then I'll post a version that addresses Amit's other
> > points, adds a new file/function to pgstattuple, acquires content
> > locks, and uses HeapTupleSatisfi
On Wed, Mar 4, 2015 at 6:48 AM, Peter Eisentraut wrote:
> - set up basic scaffolding for TAP tests in src/bin/pg_dump
Agreed.
> - write a Perl function that can create an extension on the fly, given
> name, C code, SQL code
I am perplex about that. Where would the SQL code or C code be stored?
Thank you Tom, Thank you Amit.
Regards,
Muhammad Asif Naeem
On Wed, Mar 4, 2015 at 9:30 AM, Tom Lane wrote:
> Amit Kapila writes:
> > On Sat, Feb 14, 2015 at 10:26 PM, Tom Lane wrote:
> >> It's not a false alarm, unfortunately, because chkpass_in actually does
> >> give different results from
On Wed, Mar 4, 2015 at 12:49 AM, Andres Freund wrote:
> I every now and then run installcheck against a primary, verify that
> replay works without errors, and then compare pg_dumpall from both
> clusters. Unfortunately that currently requires hand inspection of
> dumps, there are differences like
Amit Kapila writes:
> On Sat, Feb 14, 2015 at 10:26 PM, Tom Lane wrote:
>> It's not a false alarm, unfortunately, because chkpass_in actually does
>> give different results from one call to the next. We could fix the aspect
>> of that involving failing to zero out unused bytes (which it appears
On Sat, Feb 14, 2015 at 10:26 PM, Tom Lane wrote:
>
> Asif Naeem writes:
> > It is been observed on RANDOMIZE_ALLOCATED_MEMORY enabled PG95 build
that
> > chkpass is failing because of uninitialized memory and seems showing
false
> > alarm.
>
> It's not a false alarm, unfortunately, because chkpa
* Stephen Frost (sfr...@snowman.net) wrote:
> pg_start_backup, pg_stop_backup, pg_switch_xlog, pg_rotate_logfile,
> pg_create_restore_point, pg_xlog_replay_pause, lo_import, lo_export,
> and pg_xlog_replay_resume.
Meh, that list was too hastily copied and pasted from my earlier email.
lo_import an
On Wed, Mar 4, 2015 at 10:31 AM, Peter Geoghegan wrote:
> SnapBuildCommitTxn() has what I gather is an obsolete reference to
> SnapshotNow(). Attached patch corrects this.
Pushed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Tue, Mar 3, 2015 at 9:34 AM, Michael Paquier
wrote:
> On Tue, Mar 3, 2015 at 9:24 AM, Andres Freund wrote:
>> On 2015-03-03 08:59:30 +0900, Michael Paquier wrote:
>>> Already mentioned upthread, but I agree with Fujii-san here: adding
>>> information related to the state of a block image in
>>
Kevin Grittner wrote:
> [need to check performance more]
It looks like the remaining performance regression was indeed a
result of code alignment. I found two "paranoia" assignments I had
accidentally failed to put back with the rest of the mark/restore
optimization; after that trivial change
On Mon, Mar 2, 2015 at 5:05 PM, David Fetter wrote:
> So just to clarify, are you against back-patching the behavior change,
> or the addition to src/common?
Mostly the latter.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hacker
On Sat, Feb 21, 2015 at 11:34 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2015-02-20 22:19:54 -0500, Peter Eisentraut wrote:
>>> On 2/20/15 8:46 PM, Josh Berkus wrote:
Or what about just doing CSV?
>
>>> I don't think that would actually address the problems. It would just
>>> be the
On Tue, Mar 3, 2015 at 3:13 AM, Andres Freund wrote:
>> toast_save_datum() is called with a heap_insert() call before heap
>> insertion for the tuple proper. We're relying on the assumption that
>> if there is no immediate super deletion record, things are fine. We
>> cannot speculatively insert i
> Obviously FDW can add multiple paths at a time, like GetForeignPaths,
> so IMO it should be renamed to GetForeignJoinPaths, with plural form.
>
> In addition to that, new member of RelOptInfo, fdw_handler, should be
> initialized explicitly in build_simple_rel.
>
> Please see attached a patch f
On March 3, 2015 06:34:33 PM Jim Nasby wrote:
> On 3/3/15 5:24 PM, Jan de Visser wrote:> On March 3, 2015 04:57:58 PM
> Jim Nasby wrote:
> >> On 3/3/15 11:48 AM, Andres Freund wrote:
> >>> I'm saying that you'll need a way to notice that a reload was
> processed
> >> > or not. And that can
Bruce, all,
* Bruce Momjian (br...@momjian.us) wrote:
> It feels like MD5 has accumulated enough problems that we need to start
> looking for another way to store and pass passwords. The MD5 problems
> are:
>
> 1) MD5 makes users feel uneasy (though our usage is mostly safe)
>
> 2) The per-s
Hello, I attached the latest patches missing in the previous mail.
Thanks for pointing Jeevan.
0001-Add-regrole_v4.patch
0002-Add-regnamespace_v4.patch
Jim> BTW, I think the potential for MVCC issues should be mentioned in the
Jim> docs (http://www.postgresql.org/docs/devel/static/datatype-oid.h
It feels like MD5 has accumulated enough problems that we need to start
looking for another way to store and pass passwords. The MD5 problems
are:
1) MD5 makes users feel uneasy (though our usage is mostly safe)
2) The per-session salt sent to the client is only 32-bits, meaning
that it is po
On 03/03/2015 05:07 PM, Greg Stark wrote:
> On Wed, Mar 4, 2015 at 12:17 AM, Jim Nasby wrote:
>> I can make these changes if you want.
>
> Personally I'm just not convinced this is worth it. It makes the
> catalogs harder for people to read and use and only benefits people
> who have users named
On Wed, Mar 4, 2015 at 12:18 PM, Greg Stark wrote:
> On Wed, Mar 4, 2015 at 12:34 AM, Haribabu Kommi
> wrote:
>> Out of curiosity, regarding the result materialize code addition, Any
>> way the caller of "hba_settings" function
>> "ExecMakeTableFunctionResult" also stores the results in tuple_sto
SnapBuildCommitTxn() has what I gather is an obsolete reference to
SnapshotNow(). Attached patch corrects this.
--
Peter Geoghegan
diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index e911453..ff5ff26 100644
--- a/src/backend/replication/log
On Wed, Mar 4, 2015 at 12:34 AM, Haribabu Kommi
wrote:
> Out of curiosity, regarding the result materialize code addition, Any
> way the caller of "hba_settings" function
> "ExecMakeTableFunctionResult" also stores the results in tuple_store.
> Is there any advantage
> doing it in hba_settings fun
On Wed, Mar 4, 2015 at 12:17 AM, Jim Nasby wrote:
> I can make these changes if you want.
Personally I'm just not convinced this is worth it. It makes the
catalogs harder for people to read and use and only benefits people
who have users named "all" or databases named "all", "sameuser", or
"samer
Robert Haas writes:
> On Tue, Feb 24, 2015 at 2:20 PM, Peter Eisentraut wrote:
>> I think the combine function is not actually a property of the
>> aggregate, but a property of the transition function. If two aggregates
>> have the same transition function, they will also have the same combine
>
Jim,
* Jim Nasby (jim.na...@bluetreble.com) wrote:
> On 3/3/15 5:22 PM, Stephen Frost wrote:
> >The
> >problem with the role attribute approach is that they aren't inheirted
> >the way GRANTs are, which means you can't have a "backup" role that is
> >then granted out to users, you'd have to set a
On Wed, Mar 4, 2015 at 6:43 AM, Robert Haas wrote:
> That seems to make sense to me. Committed.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 3/3/15 5:13 PM, Tom Lane wrote:
Jim Nasby writes:
On 3/3/15 11:48 AM, Andres Freund wrote:
It'll be confusing to have different interfaces in one/multiple error cases.
If we simply don't want the code complexity then fine, but I just don't
buy this argument. How could it possibly be conf
On Wed, Mar 4, 2015 at 5:57 AM, Greg Stark wrote:
> On further review I've made a few more changes attached.
>
> I think we should change the column names to "users" and "databases"
> to be clear they're lists and also to avoid the "user" SQL reserved
> word.
>
> I removed the dependency on strlis
On 3/3/15 5:22 PM, Stephen Frost wrote:
The
problem with the role attribute approach is that they aren't inheirted
the way GRANTs are, which means you can't have a "backup" role that is
then granted out to users, you'd have to set a "BACKUP" role attribute
for every role added.
Yeah, but you'd
On 3/3/15 12:57 PM, Greg Stark wrote:
On Tue, Mar 3, 2015 at 6:05 PM, Jim Nasby wrote:
What about a separate column that's just the text from pg_hba? Or is that what
you're opposed to?
I'm not sure what you mean by that. There's a rawline field we could
put somewhere but it contains the ent
On Tue, Mar 3, 2015 at 3:53 PM, Robert Haas wrote:
> I find your statement that this is a pre-existing issue in
> tuplesort_begin_datum() to be pretty misleading, unless what you mean
> by it is "pre-existing since November, when an earlier patch by Peter
> Geoghegan changed the comments without c
On Tue, Feb 24, 2015 at 2:20 PM, Peter Eisentraut wrote:
> On 2/20/15 3:09 PM, Tomas Vondra wrote:
>> The 'combine' function gets two such 'state' values, while transition
>> gets 'state' + next value.
>
> I think the combine function is not actually a property of the
> aggregate, but a property o
On Fri, Feb 20, 2015 at 4:01 PM, Peter Geoghegan wrote:
> On Fri, Feb 20, 2015 at 11:58 AM, Tomas Vondra
> wrote:
>> This seems to happen because ordered_set_startup() calls
>> tuplesort_begin_datum() when (use_tuples == true), which only sets
>> 'onlyKey' and leaves (sortKeys == NULL). So 'merge
On March 3, 2015 04:57:58 PM Jim Nasby wrote:
> On 3/3/15 11:48 AM, Andres Freund wrote:
> > I'm saying that you'll need a way to notice that a reload was processed
> > or not. And that can't really be the message itself, there has to be
> > some other field; like the timestamp Tom proposes.
>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > The discussion I'm having with Peter on another thread is a very similar
> > case that should be looping in, which is if we should continue to have
> > any superuser check on updating catalog tables. He is advocating that
> > we r
Jim Nasby writes:
> On 3/3/15 11:48 AM, Andres Freund wrote:
>> It'll be confusing to have different interfaces in one/multiple error cases.
> If we simply don't want the code complexity then fine, but I just don't
> buy this argument. How could it possibly be confusing?
What I'm concerned abou
On 3/3/15 11:48 AM, Andres Freund wrote:
On 2015-03-03 11:43:46 -0600, Jim Nasby wrote:
>It's certainly better than now, but why put DBAs through an extra step for
>no reason?
Because it makes it more complicated than it already is? It's nontrivial
to capture the output, escape it to somehow fi
Stephen Frost writes:
> It's not a documented policy but it's certainly what a whole slew of
> functions *do*. Including pg_start_backup, pg_stop_backup,
> pg_switch_xlog, pg_rotate_logfile, pg_create_restore_point,
> pg_xlog_replay_pause, lo_import, lo_export, and pg_xlog_replay_resume,
> pg_rea
On Tue, Mar 3, 2015 at 10:29 PM, Stephen Frost wrote:
>> -1. If that policy exists at all, it's a BAD policy, because it
>> prevents users from changing the permissions using DDL. I think the
>> superuser check should be inside the function, when, for example, it
>> masks some of the output data
On 3/3/15 3:34 PM, David Fetter wrote:
On Tue, Mar 03, 2015 at 05:49:06PM -0300, Alvaro Herrera wrote:
Jim Nasby wrote:
FWIW, what I would find most useful at this point is a way to get
the equivalent of an AFTER STATEMENT trigger that provided all
changed rows in a MV as the result of a state
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Feb 28, 2015 at 12:27 AM, Stephen Frost wrote:
> > While this generally "works", the usual expectation is that functions
> > that should be superuser-only have a check in the function rather than
> > depending on the execute privilege. I'm ce
On Tue, Mar 3, 2015 at 11:41:20AM -0600, Jim Nasby wrote:
> >>Wouldn't it need attno info too, so all 3 orderings?
> >
> >Uh, what is the third ordering? Physical, logical, and ? It already
> >gets information about dropped columns, if that is the third one.
>
> attnum; used in other catalogs t
On 3/3/15 2:36 PM, Andrew Dunstan wrote:
On 03/03/2015 02:59 PM, Josh Berkus wrote:
On 03/03/2015 11:57 AM, Tom Lane wrote:
Josh Berkus writes:
Do we want to remove unit comments from all settings which accept
"MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
this, but seem
On Mon, Mar 2, 2015 at 6:22 PM, Fujii Masao wrote:
> On Tue, Mar 3, 2015 at 3:07 AM, Josh Berkus wrote:
>>> Per document,
>>>
>>> --
>>> In fast failover, the server is brought up immediately. Any WAL files
>>> in the archive that have not yet been applied will be ignored, and all
On Wed, Feb 25, 2015 at 10:03 AM, Fabien COELHO wrote:
>> You can add tests in src/test/modules/dummy_seclabel.
>
> Patch attached to test sec label there, in addition to the other more
> standard checks in event_trigger.
These tests seem worthwhile to me.
--
Robert Haas
EnterpriseDB: http://ww
On 3/1/15 2:17 PM, Stephen Frost wrote:
> Peter, if you have a minute, could you take a look at this thread and
> discussion of having TAP tests under src/test/modules which need to
> install an extension? I think it's something we certainly want to
> support but I'm not sure it's a good idea to j
On Wed, Feb 25, 2015 at 7:27 AM, Michael Paquier
wrote:
> Coverity is pointing out that addRangeTableEntry contains the
> following code path that does a NULL-pointer check on pstate:
> if (pstate != NULL)
> pstate->p_rtable = lappend(pstate->p_rtable, rte);
> But pstate is
On Tue, Mar 03, 2015 at 05:49:06PM -0300, Alvaro Herrera wrote:
> Jim Nasby wrote:
>
> > FWIW, what I would find most useful at this point is a way to get
> > the equivalent of an AFTER STATEMENT trigger that provided all
> > changed rows in a MV as the result of a statement.
>
> Ah, like
> https
On 2/28/15 6:32 PM, Stephen Frost wrote:
> This isn't really /etc/shadow though, this is more like direct access to
> the filesystem through the device node- and you'll note that Linux
> certainly has got an independent set of permissions for that called the
> capabilities system. That's because m
Jim Nasby wrote:
> FWIW, what I would find most useful at this point is a way to get the
> equivalent of an AFTER STATEMENT trigger that provided all changed rows in a
> MV as the result of a statement.
Ah, like
https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo%40web122301.mail.
On Mon, Mar 2, 2015 at 5:41 PM, Fabien COELHO wrote:
>> but I'd like to have a more robust discussion about what we want the error
>> reporting to look like rather than just sliding it into this patch.
>
> As an input, I suggest that the error reporting feature should provide a
> clue about where
On 03/03/2015 02:59 PM, Josh Berkus wrote:
On 03/03/2015 11:57 AM, Tom Lane wrote:
Josh Berkus writes:
Do we want to remove unit comments from all settings which accept
"MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
this, but seems like (a) it should be universal, and (b
>
> I think even something that just does that in pure SQL/plpgsql would be a
> big step forward, even if we wouldn't want it directly in the codebase.
Something like creating a trigger under the hood each time a MV is created,
that checks the changed rows on every statement against the query th
No intention to hijack. Dropping issue for now.
On Tue, Mar 3, 2015 at 2:05 PM, Josh Berkus wrote:
> On 03/03/2015 10:58 AM, Corey Huinker wrote:
> > Naive question: would it be /possible/ to change configuration to accept
> > percentages, and have a percent mean "of existing RAM at startup time
On 04/03/15 08:57, Tom Lane wrote:
Josh Berkus writes:
Do we want to remove unit comments from all settings which accept
"MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
this, but seems like (a) it should be universal, and (b) its own patch.
Meh. Doing this strikes me as a
On 03/03/2015 11:57 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Do we want to remove unit comments from all settings which accept
>> "MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
>> this, but seems like (a) it should be universal, and (b) its own patch.
>
> Meh. Doing thi
Josh Berkus writes:
> Do we want to remove unit comments from all settings which accept
> "MB,GB" or "ms,s,min"? There's more than a few. I'd be in favor of
> this, but seems like (a) it should be universal, and (b) its own patch.
Meh. Doing this strikes me as a serious documentation failure,
2015-03-03 20:32 GMT+01:00 Tom Lane :
> I wrote:
> > Robert Haas writes:
> >> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
> >>> To some extent this is a workaround for the fact that plpgsql does type
> >>> conversions the way it does (ie, by I/O rather than by using the
> parser's
> >>> cas
On 03/03/2015 10:58 AM, Corey Huinker wrote:
> Naive question: would it be /possible/ to change configuration to accept
> percentages, and have a percent mean "of existing RAM at startup time"?
>
> I ask because most of the tuning guidelines I see suggest setting memory
> parameters as a % of RAM
I wrote:
> Robert Haas writes:
>> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote:
>>> To some extent this is a workaround for the fact that plpgsql does type
>>> conversions the way it does (ie, by I/O rather than by using the parser's
>>> cast mechanisms). We've talked about changing that, but
On 03/03/2015 02:12 AM, Fujii Masao wrote:
> On Tue, Mar 3, 2015 at 8:51 AM, Josh Berkus wrote:
>> On 03/02/2015 03:43 PM, Andres Freund wrote:
>>> Hi,
>>>
>>> On 2015-03-02 15:40:27 -0800, Josh Berkus wrote:
! #max_wal_size = 1GB# in logfile segments
>>>
>>> Independe
Naive question: would it be /possible/ to change configuration to accept
percentages, and have a percent mean "of existing RAM at startup time"?
I ask because most of the tuning guidelines I see suggest setting memory
parameters as a % of RAM available.
On Tue, Mar 3, 2015 at 1:29 PM, Heikki Linn
On Tue, Mar 3, 2015 at 6:05 PM, Jim Nasby wrote:
> What about a separate column that's just the text from pg_hba? Or is that
> what you're opposed to?
I'm not sure what you mean by that. There's a rawline field we could
put somewhere but it contains the entire line.
> FWIW, I'd say that having
On 03/03/2015 10:37 AM, Heikki Linnakangas wrote:
> On 03/03/2015 08:31 PM, Josh Berkus wrote:
>> On 03/03/2015 10:29 AM, Heikki Linnakangas wrote:
>>> On 03/03/2015 08:21 PM, Josh Berkus wrote:
On 03/03/2015 10:15 AM, Josh Berkus wrote:
> On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
On 03/03/2015 08:31 PM, Josh Berkus wrote:
On 03/03/2015 10:29 AM, Heikki Linnakangas wrote:
On 03/03/2015 08:21 PM, Josh Berkus wrote:
On 03/03/2015 10:15 AM, Josh Berkus wrote:
On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
I propose that we remove the comment from max_wal_size, and also
On 03/03/2015 10:29 AM, Heikki Linnakangas wrote:
> On 03/03/2015 08:21 PM, Josh Berkus wrote:
>> On 03/03/2015 10:15 AM, Josh Berkus wrote:
>>> On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
I propose that we remove the comment from max_wal_size, and also remove
the "in milliseconds"
On 03/03/2015 08:21 PM, Josh Berkus wrote:
On 03/03/2015 10:15 AM, Josh Berkus wrote:
On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
I propose that we remove the comment from max_wal_size, and also remove
the "in milliseconds" from wal_receiver_timeout and
autovacuum_vacuum_cost_delay.
+1
On 03/03/2015 07:49 AM, Andres Freund wrote:
> I'd very much like to add a automated test like this to the tree, but I
> don't see wa way to do that sanely without a comparison tool...
We could use a comparison tool anyway. Baron Schwartz was pointing out
that Percona has a comparison tool for My
On 03/03/2015 10:15 AM, Josh Berkus wrote:
> On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
>> I propose that we remove the comment from max_wal_size, and also remove
>> the "in milliseconds" from wal_receiver_timeout and
>> autovacuum_vacuum_cost_delay.
>
> +1
>
Actually, let's be consistent
On 03/02/2015 11:25 PM, Heikki Linnakangas wrote:
> I propose that we remove the comment from max_wal_size, and also remove
> the "in milliseconds" from wal_receiver_timeout and
> autovacuum_vacuum_cost_delay.
+1
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-ha
On 3/3/15 9:08 AM, Greg Stark wrote:
On Mon, Jun 30, 2014 at 8:06 AM, Abhijit Menon-Sen wrote:
After sleeping on it, I realised that the code would return '{all}' for
'all' in pg_hba.conf, but '{"all"}' for '"all"'. So it's not exactly
ambiguous, but I don't think it's especially useful for cal
On Tue, Mar 3, 2015 at 2:00 AM, Jeremy Harris wrote:
> Yes; there seemed no advantage to any additional complexity.
> The merge consistently performs fewer comparisons than the
> quicksort, on random input - and many fewer if there are
> any sorted (or reverse-sorted) sections. However, it also
>
On Fri, Feb 27, 2015 at 09:09:35AM +0900, Amit Langote wrote:
> On 27-02-2015 AM 03:24, Andres Freund wrote:
> > On 2015-02-26 12:15:17 +0900, Amit Langote wrote:
> >> On 26-02-2015 AM 05:15, Josh Berkus wrote:
> >>> I would love to have it for 9.5, but I guess the
> >>> patch isn't nearly baked en
On 2015-03-03 11:43:46 -0600, Jim Nasby wrote:
> It's certainly better than now, but why put DBAs through an extra step for
> no reason?
Because it makes it more complicated than it already is? It's nontrivial
to capture the output, escape it to somehow fit into a delimited field,
et al. I'd rath
On 3/3/15 11:33 AM, Andres Freund wrote:
On 2015-03-03 11:09:29 -0600, Jim Nasby wrote:
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or
On 3/3/15 11:26 AM, Bruce Momjian wrote:
On Tue, Mar 3, 2015 at 11:24:38AM -0600, Jim Nasby wrote:
On 3/3/15 11:23 AM, Bruce Momjian wrote:
On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
This patch decouples these three things so th
Stephen,
Thanks for the review. I have pushed these patches, squashed in one
commit, with the exception of the one that changed ALTER TABLE. You had
enough comments about that one that I decided to put it aside for now,
and get the other ones done. I will post a new series shortly.
I fixed (mo
On 2015-03-03 11:09:29 -0600, Jim Nasby wrote:
> On 3/3/15 9:26 AM, Andres Freund wrote:
> >On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >>Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >>things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> >postmaste
On Tue, Mar 3, 2015 at 11:24:38AM -0600, Jim Nasby wrote:
> On 3/3/15 11:23 AM, Bruce Momjian wrote:
> >On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
> >>On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
> >>>This patch decouples these three things so that they
> >>>can changed freely -
On 3/3/15 11:15 AM, Jan de Visser wrote:
On March 3, 2015 11:09:29 AM Jim Nasby wrote:
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or
On 3/3/15 11:23 AM, Bruce Momjian wrote:
On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
This patch decouples these three things so that they
can changed freely -- but provides no user interface to do so. I think
that trying to only de
On Thu, Feb 26, 2015 at 01:55:44PM -0800, Josh Berkus wrote:
> On 02/26/2015 01:54 PM, Alvaro Herrera wrote:
> > This patch decouples these three things so that they
> > can changed freely -- but provides no user interface to do so. I think
> > that trying to only decouple the thing we currently h
On March 3, 2015 11:09:29 AM Jim Nasby wrote:
> On 3/3/15 9:26 AM, Andres Freund wrote:
> > On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> > postm
On March 3, 2015 10:29:43 AM Tom Lane wrote:
> Andres Freund writes:
> > On 2015-03-03 15:21:24 +, Greg Stark wrote:
> >> Fwiw this concerns me slightly. I'm sure a lot of people are doing
> >> things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
> >
> > postmaster.pid already
On 3/3/15 9:26 AM, Andres Freund wrote:
On 2015-03-03 15:21:24 +, Greg Stark wrote:
Fwiw this concerns me slightly. I'm sure a lot of people are doing
things like "kill -HUP `cat .../postmaster.pid`" or the equivalent.
postmaster.pid already contains considerably more than just the pid. e.
On 2015-03-03 11:09:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-03-03 09:39:03 -0500, Tom Lane wrote:
> > I think this is the way to go though. There's different extremes we can
> > go to though - the easiest is to simply remove the attname = "?column?"
> > assignment from get_ta
On Tue, Oct 14, 2014 at 01:21:53PM -0400, Bruce Momjian wrote:
> On Tue, Oct 14, 2014 at 09:20:22AM -0700, Jeff Janes wrote:
> > On Mon, Oct 13, 2014 at 12:11 PM, Bruce Momjian wrote:
> >
> >
> > I looked into this, and came up with more questions. Why is
> > checkpoint_completion_targe
On Tue, Mar 3, 2015 at 10:58:28AM -0500, Bruce Momjian wrote:
> > Would you suggest removing the automated system completely, or keep it
> > around
> > and just make it possible to override it (either by removing the note that
> > something is a patch, or by making something that's not listed as
On Sun, Feb 22, 2015 at 03:12:12PM -0500, Magnus Hagander wrote:
> > # Attempt to identify the file using magic information
> > mtype = mag.buffer(contents)
> > if mtype.startswith('text/x-diff'):
> > a.ispatch
Andres Freund writes:
> On 2015-03-03 09:39:03 -0500, Tom Lane wrote:
>> And on the third hand ... doing that would really only be robust as long
>> as you assume that the output will be read by a server using exactly the
>> same FigureColname() logic as what we are using. So maybe the whole idea
On 2015-03-03 09:39:03 -0500, Tom Lane wrote:
> Andres Freund writes:
> > For this case it seems easiest if we'd make get_rule_expr() (and some of
> > its helpers) return whether an implicit cast has been added.
>
> Aside from being pretty ugly, that doesn't seem particularly
> bulletproof.
Right
1 - 100 of 139 matches
Mail list logo
