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 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 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: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 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
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
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
>
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
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
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: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
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
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
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
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
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
> 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 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
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 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
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 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
>>
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
* 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 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
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 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
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 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?
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 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 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 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 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
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
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
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
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
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
101 - 139 of 139 matches
Mail list logo
