Jaime Casanova wrote:
> 2009/9/24 KaiGai Kohei :
>> Example)
>> postgres=# SET SESSION AUTHORIZATION ymj;
>> SET
>> postgres=> SELECT loread(lo_open(16453, x'4'::int), 20);
>> ERROR: permission denied for largeobject 16453
>>
>> postgres=# SET largeobject_compat_acl = on; <
Jaime Casanova wrote:
> 2009/9/23 KaiGai Kohei :
>> Jaime,
>>
>> KaiGai Kohei wrote:
>> | > ALTER LARGE OBJECT is working, but now that we can change the owner of
>> | > a LO we should be able to see who the actual owner is... i mean we
>> | > should add an owner column in \dl for psql (maybe \dl+)
2009/9/24 KaiGai Kohei :
>
> Example)
> postgres=# SET SESSION AUTHORIZATION ymj;
> SET
> postgres=> SELECT loread(lo_open(16453, x'4'::int), 20);
> ERROR: permission denied for largeobject 16453
>
> postgres=# SET largeobject_compat_acl = on; < enables
> compatible mode
>
2009/9/23 KaiGai Kohei :
> Jaime,
>
> KaiGai Kohei wrote:
> | > ALTER LARGE OBJECT is working, but now that we can change the owner of
> | > a LO we should be able to see who the actual owner is... i mean we
> | > should add an owner column in \dl for psql (maybe \dl+) and maybe an
> | > lo_owner()
> Now, I'm revising the patch as follows:
> - pg_largeobject_meta is renamed to pg_largeobject_metadata
> - The GUC of largeobject_compat_dac is renamed to largeobject_compat_acl
> - psql supports \dl to show owner of the largeobject
> - add documentation for the GUC, and add it to the postgresql.c
On Tue, Sep 22, 2009 at 11:51 AM, Tom Lane wrote:
> Robert Haas writes:
>> Right now, it looks like most of the code is being shared between all
>> three plan types. I'm pretty suspicious of how much code this patch
>> moves around and how little of it is actually changed. I can't really
>> tel
Robert Haas wrote:
> 2009/9/23 KaiGai Kohei :
>> Now, I'm revising the patch as follows:
>> - pg_largeobject_meta is renamed to pg_largeobject_metadata
>> - The GUC of largeobject_compat_dac is renamed to largeobject_compat_acl
>> - psql supports \dl to show owner of the largeobject
>> - add docume
On Wed, Sep 23, 2009 at 7:56 PM, Stef Walter wrote:
> Tom Lane wrote:
>> Stef Walter writes:
>>> Allowing host names in pg_hba.conf would also solve this problem,
>>> although the last person who tried to implement this it was a topic of
>>> contention. I asked if I should focus on reverse DNS ho
2009/9/23 KaiGai Kohei :
> Now, I'm revising the patch as follows:
> - pg_largeobject_meta is renamed to pg_largeobject_metadata
> - The GUC of largeobject_compat_dac is renamed to largeobject_compat_acl
> - psql supports \dl to show owner of the largeobject
> - add documentation for the GUC, and a
Jaime,
KaiGai Kohei wrote:
| > ALTER LARGE OBJECT is working, but now that we can change the owner of
| > a LO we should be able to see who the actual owner is... i mean we
| > should add an owner column in \dl for psql (maybe \dl+) and maybe an
| > lo_owner() function.
|
| I would like to buy you
> "David" == "David E Wheeler" writes:
David> Just a few thoughts for discussion:
David> * From my previous posts: Is it time to kill off `...@` and `~`,?
David> Not necessarily for your patch to handle, just wondering what
David> others think.
I'll take them out if people think that is
Stef Walter writes:
> But if you like I can add additional defensive checks in the code to
> ignore those obviously invalid netmasks like /0. Basically the OS would
> be giving postgres bad information. Does postgres generally try to guard
> against this? I'll follow the convention of the project.
On Sep 22, 2009, at 7:18 PM, Andrew Gierth wrote:
Hstore patch incorporating changes as previously discussed.
In addition the requested new features of conversions to and from
array formats have been added (with docs).
Thanks Andrew.
Just a few thoughts for discussion:
* From my previous po
Tom Lane wrote:
> Stef Walter writes:
>> Allowing host names in pg_hba.conf would also solve this problem,
>> although the last person who tried to implement this it was a topic of
>> contention. I asked if I should focus on reverse DNS host names in
>> pg_hba.conf or portability for this samenet
Tom Lane wrote:
> Mark Mielke writes:
>> Postfix has this capability and it works fine.
>
> Hmm, have we looked at the Postfix code to see exactly how they do it?
> I'd be a *lot* more comfortable adopting logic that's been proven in the
> field than something written from scratch.
Good idea.
A
On Mon, Sep 21, 2009 at 02:26:05PM -0400, Andrew Dunstan wrote:
>andrew=# select pg_get_viewdef('foo',true);
>pg_get_viewdef
>--
> SELECT 'a'::text AS b,
> ( SELECT 1
>FROM dual) AS x,
> random() AS
On 09/23/2009 05:40 PM, Tom Lane wrote:
I haven't looked at this "feature" at all, but I'd be inclined, on the
grounds you quite reasonably cite, to require a netmask with "samenet",
rather than just ask the interface for its netmask.
I was just thinking the same thing. Could we then unif
Mark Mielke writes:
> Postfix has this capability and it works fine.
Hmm, have we looked at the Postfix code to see exactly how they do it?
I'd be a *lot* more comfortable adopting logic that's been proven in the
field than something written from scratch.
regards, tom lan
On 09/23/2009 05:37 PM, Andrew Dunstan wrote:
Tom Lane wrote:
In this case what particularly scares me is the idea that 'samenet'
might be interpreted to let in a larger subnet than the user expected,
eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
after you'd been broke
Andrew Dunstan writes:
> Tom Lane wrote:
>> In this case what particularly scares me is the idea that 'samenet'
>> might be interpreted to let in a larger subnet than the user expected,
>> eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
>> after you'd been broken into ...
Tom Lane wrote:
In this case what particularly scares me is the idea that 'samenet'
might be interpreted to let in a larger subnet than the user expected,
eg 10/8 instead of 10.0.0/24. You'd likely not notice the problem until
after you'd been broken into ...
I haven't looked at this "fe
If looking for representation -
I consider the default pg_hba.conf to be problematic. Newbies start with
"trust" access, and then do silly things to open it up.
I would use samehost, and if samenet worked the same way it does for
Postfix, I would probably use samenet. This information can be
Stef Walter writes:
> Allowing host names in pg_hba.conf would also solve this problem,
> although the last person who tried to implement this it was a topic of
> contention. I asked if I should focus on reverse DNS host names in
> pg_hba.conf or portability for this samenet patch, and it was indi
On Wed, Sep 23, 2009 at 3:53 PM, Stef Walter wrote:
> Robert Haas wrote:
>> On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter
>> wrote:
>>> Currently people are adding 0.0.0.0 to a default pg_hba.conf file in
>>> order to allow access from nearby machines, without running into the
>>> maintenance pr
Robert Haas wrote:
> On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter
> wrote:
>> Currently people are adding 0.0.0.0 to a default pg_hba.conf file in
>> order to allow access from nearby machines, without running into the
>> maintenance problems of hard coding IP addresses. However using 0.0.0.0
>>
On 9/23/09, Peter Eisentraut wrote:
> On Wed, 2009-09-09 at 18:26 +0300, Marko Kreen wrote:
> > Unicode escapes for extended strings.
>
> Committed.
Thank you for handling the patch.
I looked at your code for U& and saw that you allow standalone
second half of the surrogate pair there, although
On Wed, Sep 23, 2009 at 3:03 PM, Bernd Helmle wrote:
>
>
> --On 23. September 2009 14:10:39 -0400 Tom Lane wrote:
>
>> FWIW, I looked the patch over quickly, and I think it will be fine once
>> Bernd's comments are addressed. In particular I agree with the
>> objection to the name "pg_setting" a
Jaime Casanova writes:
> i extracted the functions to connect that Heikki put on psql in his
> patch for determining client_encoding from client locale and put it in
> libpq so i follow the PQconnectdbParams(* params[]) approach.
I got around to looking at the actual patch a bit. I hadn't unders
--On 23. September 2009 14:10:39 -0400 Tom Lane wrote:
FWIW, I looked the patch over quickly, and I think it will be fine once
Bernd's comments are addressed. In particular I agree with the
objection to the name "pg_setting" as being confusingly close to
"pg_settings". But "pg_user_setting"
Jeff Janes wrote:
Will statement_timeout not suffice for that use case?
we tried to get around it without actually touching the core but we
really need this functionality.
patching the core here is not the primary desire we have. it is all
about modeling some functionality which was truly mis
Tom Lane wrote:
Josh Berkus writes:
Jeff,
Will statement_timeout not suffice for that use case?
Well, currently statement_timeout doesn't affect waiting for locks.
Sure it does.
And as a DBA, I don't think I'd want the same timeout for executing
queries as for
On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter wrote:
> Currently people are adding 0.0.0.0 to a default pg_hba.conf file in
> order to allow access from nearby machines, without running into the
> maintenance problems of hard coding IP addresses. However using 0.0.0.0
> is clearly suboptimal from
On Sep 23, 2009, at 11:08 AM, David E. Wheeler wrote:
I looked around and found the Public Software Group's utf8proc
project, which even includes some PostgreSQL support (not, alas, for
normalization). It has an MIT-licensed C library that offers these
functions:
Sorry, forgot the link:
On Sep 23, 2009, at 11:08 AM, David E. Wheeler wrote:
I just had a discussion on IRC about unicode normalization in
PostgreSQL. Apparently there is not support for it, currently.
BTW, the only reference I found on the [to do list](http://wiki.postgresql.org/wiki/Todo
) was:
More sensible
Alvaro Herrera writes:
> Robert Haas escribió:
>> So here's the followup question - do you intend to do one of those
>> things for this CommitFest, or should we mark this as Returned with
>> Feedback once Bernd posts the rest of his review?
> What feedback is it supposed to be returned with? Pre
Hackers,
I just had a discussion on IRC about unicode normalization in
PostgreSQL. Apparently there is not support for it, currently. Andrew
Gierth points out that it's part of the SQL spec to support it, though:
RhodiumToad:e.g. NORMALIZE(foo,NFC,len)
justatheory:Oh, just a function then
Tom,
> Well, that's exactly what Jeff is questioning. How big is the use-case
> for that exactly?
I think that it's not necessary to have a 2nd GUC, but for a different
reason than argued.
For the applications I work on, I tend to set statement_timeout to
something high designed just to catch r
Jeff Davis writes:
> We can either eliminate the USING variant from opt_class (unless it's
> necessary for some reason or I missed it in the documentation), or we
> can use another word (e.g. WITH or WITH OPERATOR) if you don't like
> CHECK.
Hmm ... we don't seem to have documented the USING nois
On Wed, Sep 23, 2009 at 18:41, Stef Walter wrote:
> Magnus Hagander wrote:
>> On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
>>
>>
>>
>>> Updated in attached patch.
>>
>> This patch does not build on Windows, the error is:
>> ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@
Magnus Hagander wrote:
> On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
>
>
>
>> Updated in attached patch.
>
> This patch does not build on Windows, the error is:
> ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@36
> referenced
> in function _pg_foreach_ifaddr
> ip.ob
Heikki,
> I think we should try to hammer this in in this commitfest. None of the
> issues found this far are too serious, nothing that requires major rewrites.
It would certainly be valuable to get users testing it starting with
Alpha2 instead of waiting 2 months.
--
Josh Berkus
PostgreSQL Exp
Josh Berkus wrote:
>> Patch withdrawn for correction and rework. Nothing serious, but not much
>> point doing further testing to all current issues resolved.
>
> :-(
>
> Good thing we went for 4 CFs.
I think we should try to hammer this in in this commitfest. None of the
issues found this far ar
Josh Berkus writes:
> Jeff,
>> Will statement_timeout not suffice for that use case?
> Well, currently statement_timeout doesn't affect waiting for locks.
Sure it does.
> And as a DBA, I don't think I'd want the same timeout for executing
> queries as for waiting for a lock.
Well, that's exact
Jeff,
> Will statement_timeout not suffice for that use case?
Well, currently statement_timeout doesn't affect waiting for locks.
And as a DBA, I don't think I'd want the same timeout for executing
queries as for waiting for a lock.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Simon,
> Patch withdrawn for correction and rework. Nothing serious, but not much
> point doing further testing to all current issues resolved.
:-(
Good thing we went for 4 CFs.
Is there a GIT branch of Simon's current working version up somewhere?
--
Josh Berkus
PostgreSQL Experts Inc.
www.p
Simon Riggs wrote:
> On Wed, 2009-09-23 at 12:07 +0300, Heikki Linnakangas wrote:
>> seems to be broken
>
> Agreed.
Looking at the relation lock stuff a bit more...
When someone tries to acquire an AccessExclusiveLock, but can't get it
immediately, we sleep while holding RecoveryInfoLock. That
Jeff Janes writes:
> Unfortunately, isolation level "serializable" is not truly
> serializable. Usually it is good enough, but when it isn't good
> enough and you need an explicit table lock (a very rare but not
> nonexistent situation), I think it should either lock the table in the
> manner it
On Mon, Sep 21, 2009 at 3:07 AM, Boszormenyi Zoltan wrote:
> Jeff Janes írta:
>>
>> Maybe I am biased in this because I am primarily thinking about how I
>> would use such a feature, rather than how Hans-Juergen intends to use
>> it, and maybe those uses differ. Hans-Juergen, could you describe
>
On Tue, Sep 22, 2009 at 10:02 AM, Alvaro Herrera
wrote:
> Heikki Linnakangas escribió:
>> Simon Riggs wrote:
>> > On Mon, 2009-09-21 at 19:42 -0700, Jeff Janes wrote:
>> >> jjanes=# begin;
>> >> BEGIN
>> >> jjanes=# lock table pgbench_history in access exclusive mode;
>> >> LOCK TABLE
>> >> jjanes
Petr Jelinek writes:
> Tom Lane napsal(a):
>> The do.sgml file was missing from both your submissions, so I cooked
>> up a very quick-and-dirty reference page. It could stand to be fleshed
>> out a bit, probably. If there's useful material in your original,
>> please submit a followon patch to a
On Wed, 2009-09-23 at 15:10 +0300, Peter Eisentraut wrote:
> Using CHECK as part of the syntax of an EXCLUSION constraint will surely
> confuse the whole thing with CHECK constraints.
>
> USING OPERATOR is available, I think.
USING won't work because one of the ways to specify the opclass in an
i
* Tom Lane wrote:
wombat, eukaryote, chinchilla: these are all failing with
...
I wonder how up-to-date their scripts are.
chinchilla's was ancient, until five minutes ago. Thanks for the
prodding. I'm running a --test HEAD now.
--
Christian Ullrich
--
Sent via pgsql-hackers mailing l
On Wed, 2009-09-23 at 10:20 -0400, Tom Lane wrote:
> comet_moth, gothic_moth: these are failing the new plpython_unicode
> test
> in locale cs_CZ.ISO8859-2. Somebody needs to do something about that.
> If it's left to me I'll probably just remove the test that has
> multiple
> results.
This is, a
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> On Wed, 2009-09-23 at 11:13 +0300, Heikki Linnakangas wrote:
>>> I note that we don't emit RunningXacts after a shutdown checkpoint. So
>>> if recovery starts at a shutdown checkpoint, we don't let read-only
>>> backends in until the first online ch
We have a number of buildfarm members that have been failing on HEAD
consistently for some time. It looks from here that the following
actions need to be taken:
tapir, cardinal: need a newer version of "flex" installed
wombat, eukaryote, chinchilla: these are all failing with
LOG: could
I made some more small adjustments - mainly renaming stuff after Tom's
comment on anonymous code blocks patch and removed one unused shared
dependency.
--
Regards
Petr Jelinek (PJMODOS)
defacl-2009-09-23.diff.gz
Description: Unix tar archive
--
Sent via pgsql-hackers mailing list (pgsql-ha
On Sun, 2009-09-20 at 19:42 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > I suppose I should just allow any index_elem. The only way I was able to
> > make the grammar for that work is by using a reserved keyword. The
> > possibilities that make the most sense to me are:
>
> > index_elem WITH
Simon Riggs wrote:
> On Wed, 2009-09-23 at 11:13 +0300, Heikki Linnakangas wrote:
>> I note that we don't emit RunningXacts after a shutdown checkpoint. So
>> if recovery starts at a shutdown checkpoint, we don't let read-only
>> backends in until the first online checkpoint. Could we treat a shutd
On Wed, 2009-09-23 at 12:07 +0300, Heikki Linnakangas wrote:
> seems to be broken
Agreed.
Patch withdrawn for correction and rework. Nothing serious, but not much
point doing further testing to all current issues resolved.
Tracking of issues raised and later solved via Wiki.
--
Simon Riggs
On Mon, Sep 21, 2009 at 20:12, Stef Walter wrote:
> Updated in attached patch.
This patch does not build on Windows, the error is:
ip.obj : error LNK2019: unresolved external symbol __imp__wsaio...@36 referenced
in function _pg_foreach_ifaddr
ip.obj : error LNK2019: unresolved external symbol
On Wed, 2009-09-23 at 12:07 +0300, Heikki Linnakangas wrote:
> it highlights that we
> need be careful to avoid putting any extra work into the normal
> recovery
> path. Otherwise bugs in hot standby related code can cause crash
> recovery to fail.
Excellent point. I will put in additional protec
On Wed, 2009-09-23 at 11:13 +0300, Heikki Linnakangas wrote:
> Looking at the way cache invalidations are handled in two-phase
> transactions, it would be simpler if we store the shared cache
> invalidation messages in the twophase state file header, like we store
> deleted relations and subxids.
On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote:
> Brad says:
>
>The patched code compiles without any additional warnings.
> Lint gripes about a trailing ',' in 'typedef enum printTextRule' in
> print.h. Other additional lint seem to be false positives. The
> regressio
The logic in the lock manager to track the number of held
AccessExclusiveLocks (with ProcArrayIncrementNumHeldLocks and
ProcArrayDecrementNumHeldLocks) seems to be broken. I added an Assertion
into ProcArrayDecrementNumHeldLocks:
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/
Looking at the way cache invalidations are handled in two-phase
transactions, it would be simpler if we store the shared cache
invalidation messages in the twophase state file header, like we store
deleted relations and subxids. This allows them to be copied to the
COMMIT_PREPARED WAL record, so th
On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
>
> It seems that Oracle reads formatting string from right-to-left. Here are
> few results:
> ('number','format') ==> Oracle PG
>
> ('34,50','999,99') ==> 3450340
> ('
66 matches
Mail list logo
