On 2011-07-09 09:14, Kohei KaiGai wrote:
OK, I'll try to modify the patch according to the flag of pg_proc design.
As long as the default of user-defined function is off, and we provide
built-in functions
with appropriate configurations, it seems to me the burden of DBA is
quite limited.
A diff
2011/7/19 Yeb Havinga :
> On 2011-07-19 22:39, Heikki Linnakangas wrote:
>>
>> On 19.07.2011 12:28, Yeb Havinga wrote:
>>>
>>> On 2011-07-18 22:21, Kohei KaiGai wrote:
The Scientific Linux 6 is not suitable, because its libselinux version
is a bit older
than this patch expects (
2011/7/20 Yeb Havinga :
> On 2011-07-09 09:14, Kohei KaiGai wrote:
>>
>> OK, I'll try to modify the patch according to the flag of pg_proc design.
>> As long as the default of user-defined function is off, and we provide
>> built-in functions
>> with appropriate configurations, it seems to me the b
And I thought I should mention: a big thank you to the the reviewers and
interested parties, Cedric, Tatsuo, Robert and Tom who did a review +
fixes as he committed the patch - nice work guys!
regards
Mark
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On Jul20, 2011, at 01:42 , Tom Lane wrote:
> Florian Pflug writes:
>> Updated patch attached. Do you think this is "Ready for Committer"?
>
> I've been looking through this patch. While it's mostly good, I'm
> pretty unhappy with the way that the pg_xml_init/pg_xml_done code is
> deliberately de
On Jul20, 2011, at 06:40 , Joey Adams wrote:
> On Wed, Jul 20, 2011 at 12:32 AM, Robert Haas wrote:
>>> Thanks for the input. I'm leaning in this direction too. However, it
>>> will be a tad tricky to implement the conversions efficiently, ...
>>
>> I'm a bit confused, because I thought what I
On Tue, Jul 19, 2011 at 6:10 AM, Kohei Kaigai wrote:
>> >> /etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid
>> >> object
>> >> type db_blobs
>> > It is not an error, but just a notification to inform users that
>> > sepgsql_contexts
>> > file contains invalid lines. It is har
2011/7/20 Robert Haas :
> On Tue, Jul 19, 2011 at 6:10 AM, Kohei Kaigai
> wrote:
>>> >> /etc/selinux/targeted/contexts/sepgsql_contexts: line 33 has invalid
>>> >> object
>>> >> type db_blobs
>>> > It is not an error, but just a notification to inform users that
>>> > sepgsql_contexts
>>> > fil
On Wed, Jul 20, 2011 at 8:50 AM, Kohei KaiGai wrote:
>> Does all of this apply to both 9.1 and 9.2devel?
>>
> This update came from feedbacks when people tried to install contrib/sepgsql
> of v9.1 and got troubled.
> So, I think it is helpful to apply v9.1 also.
OK, done, with some corrections.
On 2011-07-14 21:46, Kohei KaiGai wrote:
Sorry, the syscache part was mixed to contrib/sepgsql part
in my previous post.
Please see the attached revision.
Although its functionality is enough simple (it just reduces
number of system-call invocation), its performance
improvement is obvious.
So, I
On Wed, Jul 20, 2011 at 09:02:59AM +0200, Yeb Havinga wrote:
> On 2011-07-09 09:14, Kohei KaiGai wrote:
>> OK, I'll try to modify the patch according to the flag of pg_proc design.
>> As long as the default of user-defined function is off, and we provide
>> built-in functions
>> with appropriate co
I wrote:
> Alvaro Herrera writes:
>> I was thinking that maybe it's time for this module to hook onto the
>> cleanup stuff for the xact error case; or at least have a check that it
>> has been properly cleaned up elesewhere. Maybe this can be made to work
>> reentrantly if there's a global var ho
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not about
access rules to views, since it was mention
On 2011-07-20 16:15, Yeb Havinga wrote:
On 2011-07-20 16:06, Noah Misch wrote:
The SQL-level semantics of the view define the access rules in
question. How
would you translate that into tests to apply at a lower level?
I assumed the leaky view thread was about row level security, not
about
On Wed, Jul 20, 2011 at 04:23:10PM +0200, Yeb Havinga wrote:
> On 2011-07-20 16:15, Yeb Havinga wrote:
>> On 2011-07-20 16:06, Noah Misch wrote:
>>>
>>> The SQL-level semantics of the view define the access rules in
>>> question. How
>>> would you translate that into tests to apply at a lower le
On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga wrote:
> * I run SELECT sepgsql_restorecon(NULL) and saw comparable numbers in speed
> gain and also backend process memory increase as indicated by KaiGai-san.
> The vmsize without the patch increases from running restorecon 3864kB, with
> the patch is
I wrote a FDW for Oracle to a) learn some server coding
and b) see how well the FDW API works for me.
I came up with three questions/experiences:
1) GetUserMapping throws an error if there is no
user mapping for the user (or PUBLIC).
I think that it would be much more useful if
it would
Florian Pflug writes:
> On Jul20, 2011, at 01:42 , Tom Lane wrote:
>> 1. If you forget pg_xml_done in some code path, you'll find out from
>> an Assert at the next pg_xml_init, which is probably far away from where
>> the actual problem is.
> Very true. In fact, I did miss one pg_xml_done() call
On Jul20, 2011, at 17:08 , Tom Lane wrote:
> Florian Pflug writes:
>> On Jul20, 2011, at 01:42 , Tom Lane wrote:
>>> 1. If you forget pg_xml_done in some code path, you'll find out from
>>> an Assert at the next pg_xml_init, which is probably far away from where
>>> the actual problem is.
>
>> Bu
Florian Pflug writes:
> I'm fine with having pg_xml_init() palloc the state and pg_xml_done()
> pfree it, but I'm kinda curious about why you prefer that over making it
> the callers responsibility and letting callers use a stack-allocated
> struct if they wish to.
We could do it that way, but it
On Jul20, 2011, at 17:37 , Tom Lane wrote:
> Florian Pflug writes:
>> I'm fine with having pg_xml_init() palloc the state and pg_xml_done()
>> pfree it, but I'm kinda curious about why you prefer that over making it
>> the callers responsibility and letting callers use a stack-allocated
>> struct
On 2011-07-20 16:54, Robert Haas wrote:
As to the first point, the other big problem with adding a syscache
here is that it could get really big. I've worried about that issue
previously, and Yev's perplexity about where the memory is going is
not too reassuring.
Yeah I just realized that #buck
Yeb, Thanks for your volunteering.
> On 2011-07-14 21:46, Kohei KaiGai wrote:
> > Sorry, the syscache part was mixed to contrib/sepgsql part
> > in my previous post.
> > Please see the attached revision.
> >
> > Although its functionality is enough simple (it just reduces
> > number of system-call
On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
wrote:
> The sepgsql_restorecon(NULL) assigns default security label on all the
> database objects being controlled, thus, its workload caches security
> label (including text data) of these objects.
> So, ~5MB of difference is an upper limit of sysca
On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
wrote:
> One question is why InitCatalogCache() should be invoked from InitPostgres()?
> If we initialize syscache on starting up postmaster process, I think
> all the syscache buckets will be ready on child process forks, and
> unused syscache does n
On Wed, Jul 20, 2011 at 6:49 AM, Florian Pflug wrote:
> Hm, I agree that we need to handle \u escapes in JSON input.
> We won't ever produce them during output though, right?
We could, to prevent transcoding errors if the client encoding is
different than the server encoding (and neither is S
> On Wed, Jul 20, 2011 at 12:40 PM, Kohei Kaigai
> wrote:
> > One question is why InitCatalogCache() should be invoked from
> > InitPostgres()?
> > If we initialize syscache on starting up postmaster process, I think
> > all the syscache buckets will be ready on child process forks, and
> > unuse
> On Wed, Jul 20, 2011 at 12:04 PM, Kohei Kaigai
> wrote:
> > The sepgsql_restorecon(NULL) assigns default security label on all the
> > database objects being controlled, thus, its workload caches security
> > label (including text data) of these objects.
> > So, ~5MB of difference is an upper li
I've committed this patch with the discussed changes and some other
editorialization. I have to leave for an appointment and can't write
anything now about the changes, but feel free to ask questions if you
have any.
regards, tom lane
--
Sent via pgsql-hackers mailing li
On 07/20/2011 05:24 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Petr_Jel=EDnek?= writes:
But, I think we should add valitation hook to plpgsql plugin structure
so that you don't have to actually execute the function to check it -
curretly there are only executing hooks which is why the plugin only
works
On Tue, Jul 19, 2011 at 8:45 PM, Bruce Momjian wrote:
> Gurjeet Singh wrote:
>
> [ CC to general removed --- emailing only hackers; cross-posting is
> frowned upon. ]
>
I thought these questions were of interest to the general public too.
>
> > .) Is Streaming Replication supported across mi
On Wed, Jul 6, 2011 at 1:25 AM, Kohei KaiGai wrote:
> 2011/7/5 Alvaro Herrera :
>> Excerpts from Kohei Kaigai's message of mar jul 05 11:46:06 -0400 2011:
>>> > On Tue, Jul 5, 2011 at 10:49 AM, Alvaro Herrera
>>> > wrote:
>>> > > Excerpts from Robert Haas's message of mar jul 05 10:19:18 -0400 20
> On Wed, Jul 20, 2011 at 9:47 AM, Yeb Havinga wrote:
> > * I run SELECT sepgsql_restorecon(NULL) and saw comparable numbers in speed
> > gain and also backend process memory increase as indicated by KaiGai-san.
> > The vmsize without the patch increases from running restorecon 3864kB, with
> > th
On 20.07.2011 18:00, Albe Laurenz wrote:
2) If I decide to close remote database connections after
use, I would like to do so where reasonable.
I would like to keep the connection open between query
planning and query execution and close it when the
scan is done.
The exception
I took another look at v2 of my lazy vxid locks patch and realized
that it was pretty flaky in a couple of different ways. Here's a
version that I think is a bit more robust, but considering the extent
of the revisions, it probably needs another round of review from
someone before I commit it.
An
Excerpts from Peter Eisentraut's message of sáb jul 09 14:45:23 -0400 2011:
> On tor, 2011-07-07 at 17:34 -0400, Alvaro Herrera wrote:
> > The attached patch introduces pg_constraint rows for NOT NULL
> > column constraints.
>
> The information schema views check_constraints and table_constraints
Tom Lane wrote:
> I've committed this patch with the discussed changes and some other
> editorialization. I have to leave for an appointment and can't write
> anything now about the changes, but feel free to ask questions if you
> have any.
Did this fix any of the XML TODOs?
http://wiki.
Gurjeet Singh wrote:
> On Tue, Jul 19, 2011 at 8:45 PM, Bruce Momjian wrote:
>
> > Gurjeet Singh wrote:
> >
> > [ CC to general removed --- emailing only hackers; cross-posting is
> > frowned upon. ]
> >
>
> I thought these questions were of interest to the general public too.
What I usually
On Wed, Jul 20, 2011 at 2:53 PM, Bruce Momjian wrote:
>> I am assuming that's a "yes" to both the directions: older -> newer , and
>> newer -> older minor releases.
>
> Yes, I believe both directions would work unless we mentioned it the
> release notes, in which cases it might not work, or might
We're nearing completion of testing the migration of a lot of code
which used our custom Java framework into PostgreSQL functions and
triggers. Yesterday our testers ran into surprising behavior
related to delete triggers. A test case is presented on the -bugs
list, but basically it amounts to th
On Wed, Jul 20, 2011 at 2:58 PM, Kevin Grittner
wrote:
> So basically, the goal of this patch is to ensure that a BEFORE
> DELETE trigger doesn't silently fail to delete a row because that
> row was updated during the BEFORE DELETE trigger firing (in our case
> by secondary trigger firing).
I've
Robert Haas wrote:
> On Wed, Jul 20, 2011 at 2:53 PM, Bruce Momjian wrote:
> >> I am assuming that's a "yes" to both the directions: older -> newer , and
> >> newer -> older minor releases.
> >
> > Yes, I believe both directions would work unless we mentioned it the
> > release notes, in which cas
Robert Haas wrote:
> I think this problem also occurs if you have a BEFORE
> UPDATE trigger that does an UPDATE on the same row.
I'm pretty sure you're right, and I do intend to cover that in the
final patch.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On Wed, Jul 20, 2011 at 3:29 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Wed, Jul 20, 2011 at 2:53 PM, Bruce Momjian wrote:
>> >> I am assuming that's a "yes" to both the directions: older -> newer , and
>> >> newer -> older minor releases.
>> >
>> > Yes, I believe both directions would w
Bruce Momjian writes:
> Did this fix any of the XML TODOs?
> http://wiki.postgresql.org/wiki/Todo#XML
No, not that I know of.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
Kaigai,
> I'd like to have a discussion about syscache towards next commit-fest.
> The issues may be:
> - Initial bucket allocation on most cases never be referenced.
> - Reclaim cache entries on growing up too large.
Should I move this patch to the next CF?
--
Josh Berkus
PostgreSQL Experts
On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus wrote:
> Kaigai,
>
>> I'd like to have a discussion about syscache towards next commit-fest.
>> The issues may be:
>> - Initial bucket allocation on most cases never be referenced.
>> - Reclaim cache entries on growing up too large.
>
> Should I move
On Wed, Jul 20, 2011 at 4:19 PM, Robert Haas wrote:
> On Wed, Jul 20, 2011 at 4:06 PM, Josh Berkus wrote:
>> Kaigai,
>>
>>> I'd like to have a discussion about syscache towards next commit-fest.
>>> The issues may be:
>>> - Initial bucket allocation on most cases never be referenced.
>>> - Recl
Robert Haas wrote:
> On Wed, Jul 20, 2011 at 3:29 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Wed, Jul 20, 2011 at 2:53 PM, Bruce Momjian wrote:
> >> >> I am assuming that's a "yes" to both the directions: older -> newer ,
> >> >> and
> >> >> newer -> older minor releases.
> >> >
> >
Kohei Kaigai writes:
> I'd like to have a discussion about syscache towards next commit-fest.
> The issues may be:
> - Initial bucket allocation on most cases never be referenced.
> - Reclaim cache entries on growing up too large.
There used to be support for limiting the number of entries in a
[ having now read the relevant threads a bit more carefully ... ]
Florian Pflug writes:
> On Jul18, 2011, at 22:19 , Tom Lane wrote:
>> Yeah, it's not clear to me either which of those are still reasonable
>> candidates for committing as-is.
> There are actually three XML-related patches from me
On Wed, Jul 20, 2011 at 4:48 PM, Tom Lane wrote:
> Kohei Kaigai writes:
>> I'd like to have a discussion about syscache towards next commit-fest.
>> The issues may be:
>> - Initial bucket allocation on most cases never be referenced.
>> - Reclaim cache entries on growing up too large.
>
> There
On Jul20, 2011, at 23:35 , Tom Lane wrote:
> I find your argument against XPATH_STRING() a bit unconvincing.
> The use case for that is not where you are trying to evaluate an
> unknown, arbitrary XPath expression; it's where you are evaluating an
> expression that you *know* returns string (ie, it
Florian Pflug writes:
> There's a small additional concern, though, which is that there's an
> XPath 2.0 spec out there, and it modifies the type system and data model
> rather heavily. So before we go adding functions, it'd probably be wise
> to check that we're not painting ourselves into a corn
I have fixed the bug below with the attached patches for 9.0, 9.1, and
9.2. I did a minimal patch for 9.0 and 9.1, and a more thorough patch
for 9.2.
The use of -l/log was tested originally in pg_migrator (for 8.4) and
reported to be working, but it turns out it only worked in 'check' mode,
and
For the last week or so, in between various other tasks, I've been
trying to understand why performance drops off when you run pgbench -n
-S -c $CLIENTS -j $CLIENTS -T $A_FEW_MINUTES at very high client
counts. The answer, in a word, is SIGetDataEntries(). I believe we
need to bite the bullet and
On Wed, Jul 20, 2011 at 08:26:19PM +0300, Heikki Linnakangas wrote:
> On 20.07.2011 18:00, Albe Laurenz wrote:
> >2) If I decide to close remote database connections after
> >use, I would like to do so where reasonable.
> >I would like to keep the connection open between query
> >planni
On Mon, Jul 18, 2011 at 6:38 AM, Pavel Golub wrote:
> 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.
So I finally got
[Resending with gzip'ed patch this time, I think the last attempt got eaten.]
On Mon, Jul 18, 2011 at 11:15 PM, Robert Haas wrote:
> On Mon, Jul 18, 2011 at 10:57 PM, Josh Kupershmidt wrote:
1.) For now, I'm just ignoring the issue of visibility checks; I
didn't see a simple way to sup
Hello
the basic issue is deployment of plpgsql plugins - they needs to
include "plpgsql.h", but this include file is not public. Next
significant issue is impossibility to serialize plpgsql plugins. Only
one should be supported. A limit is a access to persistent data via
estate->plugin_info. Other
Excerpts from Noah Misch's message of sáb jul 16 13:25:03 -0400 2011:
> On Sat, Jul 16, 2011 at 05:50:45PM +0200, Rémi Zara wrote:
> > Isolation tests seem to deadlock on buildfarm member coypu (NetBSD/powerpc
> > 5.1).
>
> Thanks for the report and detailed analysis. I believe the patch here wi
Hi Albe,
(2011/07/21 0:00), Albe Laurenz wrote:
> 1) GetUserMapping throws an error if there is no
> user mapping for the user (or PUBLIC).
> I think that it would be much more useful if
> it would return NULL or something similar instead.
> Otherwise one would have to check for ex
62 matches
Mail list logo
