Stephen Frost wrote:
Mark,
Your last email on this patch, from August 9th, indicates that you've
still got TODO: redo pg_stat_lock_waits Has you updated this
patch since then?
Stephen,
No - that is still a TODO for me - real life getting in the way :-)
Cheers
Mark
--
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
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
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
+++
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
regression
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 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 protective
On Mon, Sep 21, 2009 at 20:12, Stef Walter stef-l...@memberwebs.com wrote:
snip
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
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
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 shutdown
On Sun, 2009-09-20 at 19:42 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com 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:
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
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
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 checkpoint.
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, at
* 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
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
Petr Jelinek pjmo...@pjmodos.net 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
On Tue, Sep 22, 2009 at 10:02 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, Sep 21, 2009 at 3:07 AM, Boszormenyi Zoltan z...@cybertec.at 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
Jeff Janes jeff.ja...@gmail.com 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
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
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.
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
--
Josh Berkus j...@agliodbs.com 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,
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 are too
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
Magnus Hagander wrote:
On Mon, Sep 21, 2009 at 20:12, Stef Walter stef-l...@memberwebs.com wrote:
snip
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
On Wed, Sep 23, 2009 at 18:41, Stef Walter stef-l...@memberwebs.com wrote:
Magnus Hagander wrote:
On Mon, Sep 21, 2009 at 20:12, Stef Walter stef-l...@memberwebs.com wrote:
snip
Updated in attached patch.
This patch does not build on Windows, the error is:
ip.obj : error LNK2019:
Jeff Davis pg...@j-davis.com 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
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
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
Alvaro Herrera alvhe...@commandprompt.com 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
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
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 Wed, Sep 23, 2009 at 12:41 PM, Stef Walter stef-l...@memberwebs.com 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
Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
--On 23. September 2009 14:10:39 -0400 Tom Lane t...@sss.pgh.pa.us 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
Jaime Casanova jcasa...@systemguards.com.ec 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
On Wed, Sep 23, 2009 at 3:03 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 23. September 2009 14:10:39 -0400 Tom Lane t...@sss.pgh.pa.us 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
On 9/23/09, Peter Eisentraut pete...@gmx.net 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
Robert Haas wrote:
On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter stef-l...@memberwebs.com
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
On Wed, Sep 23, 2009 at 3:53 PM, Stef Walter stef-l...@memberwebs.com wrote:
Robert Haas wrote:
On Wed, Sep 23, 2009 at 12:41 PM, Stef Walter stef-l...@memberwebs.com
wrote:
Currently people are adding 0.0.0.0 to a default pg_hba.conf file in
order to allow access from nearby machines,
Stef Walter stef-l...@memberwebs.com 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
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
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
Andrew Dunstan and...@dunslane.net 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
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
Mark Mielke m...@mark.mielke.cc 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.
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 unify
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 y,
Tom Lane wrote:
Mark Mielke m...@mark.mielke.cc 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.
Tom Lane wrote:
Stef Walter stef-l...@memberwebs.com 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
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
Stef Walter stef-l...@memberwebs.com 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
David == David E Wheeler da...@kineticode.com 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
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 your
2009/9/23 KaiGai Kohei kai...@ak.jp.nec.com:
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
On Wed, Sep 23, 2009 at 7:56 PM, Stef Walter stef-l...@memberwebs.com wrote:
Tom Lane wrote:
Stef Walter stef-l...@memberwebs.com 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
Robert Haas wrote:
2009/9/23 KaiGai Kohei kai...@ak.jp.nec.com:
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
-
On Tue, Sep 22, 2009 at 11:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
2009/9/23 KaiGai Kohei kai...@ak.jp.nec.com:
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
|
64 matches
Mail list logo
