Hi
Have we some possibility to take info about external user when any login
via mapping is used?
Two years ago It was a final blocker for migration one Oracle application
and last month I had this question more time.
The customer want to use map to do switch between external user to database
use
On Sat, May 30, 2015 at 10:47:27PM +0200, Andres Freund wrote:
> > The bottom line is that we just can't keep going on like this. The fact
> > we put out a release two weeks ago, then need to put out a fix release
> > for that, but we have more multi-xact bugs to fix and can't decide if we
> > sho
On Saturday, May 30, 2015, Bruce Momjian wrote:
> On Sat, May 30, 2015 at 12:26:11PM -0700, Peter Geoghegan wrote:
> > On Sat, May 30, 2015 at 5:56 AM, Bruce Momjian > wrote:
> > > Frankly, based on how I feel now, I would have no problem doing 9.5 in
> > > 2016 and saying we have a lot of retoo
On 05/30/2015 06:51 PM, David Steele wrote:
On 5/30/15 8:38 PM, Joshua D. Drake wrote:
On 05/30/2015 03:48 PM, David Steele wrote:
On 5/30/15 2:10 PM, Robert Haas wrote:
What, in this release, could break things badly? RLS? Grouping sets?
Heikki's WAL format changes? That last one sounds r
On Sat, May 30, 2015 at 12:26:11PM -0700, Peter Geoghegan wrote:
> On Sat, May 30, 2015 at 5:56 AM, Bruce Momjian wrote:
> > Frankly, based on how I feel now, I would have no problem doing 9.5 in
> > 2016 and saying we have a lot of retooling to do. We could say we have
> > gotten too far out ahe
Hi,
I have written a patch which makes it possible to change SSL
certificates (and other SSL parameters, including the CRL) without
restarting PostgreSQL. In fact this patch also makes it possible to turn
on or off ssl entirely without restart. It does so by initializing a new
SSL context whe
On 5/30/15 8:38 PM, Joshua D. Drake wrote:
>
> On 05/30/2015 03:48 PM, David Steele wrote:
>> On 5/30/15 2:10 PM, Robert Haas wrote:
>>> What, in this release, could break things badly? RLS? Grouping sets?
>>> Heikki's WAL format changes? That last one sounds really scary to me;
>>> it's painful
Hi,
Yesterday, JPUG held an unconference event at Tokyo, and
Hanada-san had a talk about join-pushdown feature of
postgres_fdw.
At this talk, someone proposed an interesting idea to
make join pushdown more aggressive/effective.
Let me share it with pgsql-hackers.
He said, we may have a workload t
On 2015-05-30 00:52:37 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
>
> > I considered for a second whether the solution for that could be to not
> > truncate while inconsistent - but I think that doesn't solve anything as
> > then we can end up with directories where every single offsets/me
On 05/30/2015 03:48 PM, David Steele wrote:
On 5/30/15 2:10 PM, Robert Haas wrote:
What, in this release, could break things badly? RLS? Grouping sets?
Heikki's WAL format changes? That last one sounds really scary to me;
it's painful if not impossible to fix the WAL format in a minor
release
On 2015-05-27 21:23:34 -0400, Robert Haas wrote:
> > Oh wow, that's bad, and could explain a couple of the problems we're
> > seing. One possible way to fix is to replace the sequence with if
> > (!TAS(spin)) S_UNLOCK();. But that'd mean TAS() has to be a barrier,
> > even if the lock isn't free -
On 5/30/15 2:10 PM, Robert Haas wrote:
> What, in this release, could break things badly? RLS? Grouping sets?
> Heikki's WAL format changes? That last one sounds really scary to me;
> it's painful if not impossible to fix the WAL format in a minor
> release.
I would argue Heikki's WAL stuff is a
On Sat, May 30, 2015 at 3:12 PM, Peter Geoghegan wrote:
> Debugging this allowed me to come up with a significantly simplified
> approach. Attached is a new version of the original fix. Details are
> in commit message -- there is no actual need to have
> search_indexed_tlist_for_var() care about V
On Sat, May 30, 2015 at 1:07 AM, Peter Geoghegan wrote:
> My fix for this issue
> (0001-Fix-bug-with-whole-row-Vars-in-excluded-targetlist.patch) still
> missed something. There needs to be additional handling in
> ruleutils.c:
Debugging this allowed me to come up with a significantly simplified
Hi,
On 05/30/15 23:16, Tom Lane wrote:
I wrote:
So what this seems to mean is that for SEMI/ANTI join cases, we have to
postpone all of the inner scan cost determination to final_cost_nestloop,
so that we can do this differently depending on whether
has_indexed_join_quals() is true. That's a l
On May 30, 2015 2:19:00 PM PDT, Tom Lane wrote:
>Andres Freund writes:
>> * The signal handling, sinval, client communication changes. Little
>to
>> none problems so far, but it's complex stuff. These changes are an
>> example of potential for problems due to changes to reduce
>> complexity
Andres Freund writes:
> * The signal handling, sinval, client communication changes. Little to
> none problems so far, but it's complex stuff. These changes are an
> example of potential for problems due to changes to reduce
> complexity...
As far as that goes, it's quite clear from the bui
I wrote:
> So what this seems to mean is that for SEMI/ANTI join cases, we have to
> postpone all of the inner scan cost determination to final_cost_nestloop,
> so that we can do this differently depending on whether
> has_indexed_join_quals() is true. That's a little bit annoying because it
> wil
On 05/30/15 21:50, Tom Lane wrote:
So what this seems to mean is that for SEMI/ANTI join cases, we have
to postpone all of the inner scan cost determination to
final_cost_nestloop, so that we can do this differently depending on
whether has_indexed_join_quals() is true. That's a little bit
annoy
On 2015-05-30 14:10:36 -0400, Robert Haas wrote:
> It's clear - at least to me - that we need to put more resources into
> stabilizing the new multixact system. This is killing us. If we can't
> stabilize this, people will go use some other database.
I agree. Perhaps I don't see things quite as d
Hi Bruce, Everyone,
On 2015-05-30 11:45:59 -0400, Bruce Momjian wrote:
> Let me share something that people have told me privately but don't want
> to state publicly (at least with attribution), and that is that we have
> seen great increases in feature development (often funded), without a
> corr
Tomas Vondra writes:
> I wonder whether the
> run_cost += inner_run_cost;
> is actually correct, because this pretty much means we assume scanning
> the whole inner relation (once). Wouldn't something like this be more
> appropriate?
> run_cost += inner_run_cost * inner_scan_fr
On Sat, May 30, 2015 at 11:10 AM, Robert Haas wrote:
>> Let me share something that people have told me privately but don't want
>> to state publicly (at least with attribution), and that is that we have
>> seen great increases in feature development (often funded), without a
>> corresponding incr
On Sat, May 30, 2015 at 5:56 AM, Bruce Momjian wrote:
> Frankly, based on how I feel now, I would have no problem doing 9.5 in
> 2016 and saying we have a lot of retooling to do. We could say we have
> gotten too far out ahead of ourselves and we need to regroup and
> restructure the code.
I wou
On Sat, May 30, 2015 at 11:45 AM, Bruce Momjian wrote:
> On Sat, May 30, 2015 at 10:06:52AM -0400, Robert Haas wrote:
>> If that means it's stable, +1 from me.
>>
>> I dispute, on every level, the notion that not releasing a beta means
>> that we can't work on things in parallel. We can work on a
On 05/30/15 03:52, Tomas Vondra wrote:
On 05/30/15 01:20, Tomas Vondra wrote:
Notice the cost - it's way lover than the previous plan (9.2 vs
~111k), yet this plan was not chosen. So either the change broke
something (e.g. by violating some optimizer assumption), or maybe
there's a bug somewh
On 05/30/15 16:47, Tom Lane wrote:
Another reason why that would be a bad place is that a pg_class update
forces relcache invalidation and thereby cached-plan invalidation.
You don't want that for anything except (1) DDL affecting the table or
(2) change in statistics that affect plan choices
Hi,
On 05/30/15 04:41, Andres Freund wrote:
On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
It occurs to me that there's no good reason for vacuum-derived stats to be
in the stats file; it's not like users run vacuum anywhere near as often as
other commands. It's stats could be kept in pg_class;
On Sat, May 30, 2015 at 10:06:52AM -0400, Robert Haas wrote:
> If that means it's stable, +1 from me.
>
> I dispute, on every level, the notion that not releasing a beta means
> that we can't work on things in parallel. We can work on all of the
> things on the open items list in parallel right n
Andres Freund writes:
> On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
>> It occurs to me that there's no good reason for vacuum-derived stats to be
>> in the stats file; it's not like users run vacuum anywhere near as often as
>> other commands. It's stats could be kept in pg_class; we're already
On 05/30/2015 06:11 AM, Bruce Momjian wrote:
2017? Really? Is there any need for that hyperbole?
Frankly, based on how I feel now, I would have no problem doing 9.5 in
2016 and saying we have a lot of retooling to do. We could say we have
gotten too far out ahead of ourselves and we need to
On Sat, May 30, 2015 at 12:08 AM, Tom Lane wrote:
> I think your position is completely nuts. The GROUPING SETS code is
> desperately in need of testing. The custom-plan code is desperately
> in need of fixing and testing. The multixact code is desperately
> in need of testing. The open-items
On Sat, May 30, 2015 at 08:56:53AM -0400, Bruce Momjian wrote:
> On Sat, May 30, 2015 at 12:08:07AM -0400, Tom Lane wrote:
> > desperately in need of testing. The custom-plan code is desperately
> > in need of fixing and testing. The multixact code is desperately
> > in need of testing. The open
On Sat, May 30, 2015 at 12:08:07AM -0400, Tom Lane wrote:
> desperately in need of testing. The custom-plan code is desperately
> in need of fixing and testing. The multixact code is desperately
> in need of testing. The open-items list has several other problems
> besides those. All of those p
Re: Michael Paquier 2015-05-28
> Attached is a doc patch among those lines.
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index 89a609f..6485b42 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -16233,7 +16233,7 @@ SELECT collation for ('foo' COLLATE "
On Sat, May 30, 2015 at 6:08 AM, Tom Lane wrote:
> I noticed that if you use "initdb -S", the code does its thing and
> exits without ever calling get_restricted_token(). It doesn't get
> to get_id() where the no-superuser check is, either. Is this OK,
> or should we reorder the operations so th
On Sat, May 30, 2015 at 11:47 AM, Peter Eisentraut wrote:
> It appears to be an omission that ALTER TABLE ... ENABLE TRIGGER and
> similar commands don't allow acting on views, even though we now have
> triggers on views.
True, now isn't it something that should be as well part of ALTER VIEW?
>
On Thu, May 28, 2015 at 2:37 PM, Peter Geoghegan wrote:
> Attached, revised version incorporates this small fix, while adding an
> additional big fix, and a number of small style tweaks.
>
> This is mainly concerned with fixing the bug I was trying to fix when
> I spotted the minor pfree() issue:
On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
wrote:
> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
> wrote:
>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
>> wrote:
>>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
39 matches
Mail list logo
