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
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
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
[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
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
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
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
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
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
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
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
[ 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
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
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.
> >> >
> >
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
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
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
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
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
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
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
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
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: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
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
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.
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
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
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
> 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 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 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 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
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 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
> 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 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
> unused syscache does n
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
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 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
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
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: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:
> 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
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
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
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 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 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
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 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
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 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.
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 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
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 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
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
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
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 (
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
62 matches
Mail list logo
