It means I will go ahead and apply it once I have looked it over once
more.
Thanks for review+testing!
You may now move on to the next ssl patch if you're interested ;)
/Magnus
On 12 nov 2008, at 17.05, Alex Hunsaker [EMAIL PROTECTED] wrote:
OK now that im using the right env var
I am sending patch, that adds FOUND and GET DIAGNOSTICS support for
RETURN QUERY statement
Regards
Pavel Stehule
2008/11/10 Andrew Gierth [EMAIL PROTECTED]:
Pavel == Pavel Stehule [EMAIL PROTECTED] writes:
Well, changing the semantics of an already-released statement
carries a risk of
On Thu, 2008-11-13 at 18:55 +0800, [EMAIL PROTECTED] wrote:
Hi all:
I am a fresh men in PostgreSQL. And i work on benchmark study
these days using PostgreSQL.
Now i have a question: Is there some way to show the lock contention
of PostgreSQL?
As I know, you can use show mutex
Charlie Savage wrote:
Just wanted to close off this thread.
Previously I reported that building 8.3.4 with MingW on Windows resulted
in an initdb executable that couldn't create new databases due to
security restrictions in creating global file mappings in Vista.
I'm happy to say that the
Bruce Momjian wrote:
Yes, my defines were very messed up; updated version attached.
Hi,
I've not done a review of this patch, however I did backport it to 8.3
(as attached in unified diff). The patch wasn't made for PG purposes, so
it's not in context diff. I tested the backported patch and
Hello Stephen,
Stephen Frost wrote:
Attached patch has this fixed and still passes all regression tests,
etc.
Do you have an up-to-date patch laying around? The current one conflicts
with some CVS tip changes.
I didn't get around writing some docu, yet. Sorry.
Regards
Markus Wanner
--
--- On Wed, 12/11/08, Tony Fernandez [EMAIL PROTECTED] wrote:
Date: Wednesday, 12 November, 2008, 10:52 PM
Hello lists,
I am trying to run Slony on a Master Postgres 8.1.11
replicating to a
Slave same version and 2nd Slave Postgres 8.3.4.
I am getting the following error:
Attached patch implements client certificate authentication.
I kept this sitting in my tree without sending it in before the
commitfest because it is entirely dependent on the
not-yet-reviewed-and-applied patch for how to configure client
certificate requesting. But now that I learned how to do
Hi,
Hannu Krosing wrote:
As I know, you can use show mutex status in MySQL to find which mutex
is hot. But i don't know in PostgreSQL.
look at pg_locks system view
Or read about dtrace to analyze lower level locking contention:
http://www.postgresql.org/docs/8.3/static/dynamic-trace.html
2008/11/5 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
2008/11/4 Tom Lane [EMAIL PROTECTED]:
Pavel Stehule [EMAIL PROTECTED] writes:
a) server crash after creating tsearch2 function (I use tsearch2
contrib from 8.3)
I couldn't reproduce that with the script you gave.
Hi, Pgsql-hackers.
many seem (to me) to be overly tied to an all XML all the time view.
Only for hierarchical result sets. Even in case of
http://computer20.euro.ru/site/computer20/en/author/communication_eng.htm
Dmitry (SQL50, HTML60)
--
Sent via pgsql-hackers mailing list
Hi all:
I am a fresh men in PostgreSQL. And i work on benchmark study these
days using PostgreSQL.
Now i have a question: Is there some way to show the lock contention of
PostgreSQL?
As I know, you can use *show mutex status* in MySQL to find which mutex is
hot. But i don't know in
Bruce Momjian wrote:
Magnus Hagander wrote:
I have developed the attached patch, which documents the inability to
use MD5 with db_user_namespace, and throws an error when it is used:
psql: FATAL: MD5 authentication is not supported when
db_user_namespace is enabled
IMHO it would be
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I am unsure of exactly where this thing hacks into the authentication
stream, but is it really only MD5 that fails?
The problem with md5 is that the username is part of the encryption salt
for the stored password, so changing it
Alvaro Herrera [EMAIL PROTECTED] writes:
Who is in charge of pg_filedump now?
It's usually me that fixes it for new PG versions. I don't normally
try to track CVS HEAD, just update it at release time.
I noticed that the latest version (for 8.3) does not play nice with
HEAD, because of
Andrew Chernow wrote:
Tom Lane wrote:
Andrew Chernow [EMAIL PROTECTED] writes:
Just noticed that the last libpqtypes release was broken on windows
when dynamically linking. The problem is that windows has two
addresses for functions, the import library uses a stub ordinal
address while the
Hi,
Who is in charge of pg_filedump now?
I noticed that the latest version (for 8.3) does not play nice with
HEAD, because of changes in ControlFileData. The attached patch fixes
that, allowing it to compile.
I didn't look if there were other changes needed for it to actually
work; any clues?
--On Dienstag, November 11, 2008 23:06:08 -0500 Robert Haas
[EMAIL PROTECTED] wrote:
Thanks for your look at this. Unfortunately i was travelling the last 2
days, so i didn't have time to reply earlier, sorry for that.
I haven't done a full review of this patch, but here are some thoughts
Hello.
Why pg_dump dumps CONSTRAINT ... CHECK together with CREATE TABLE queries,
but NOT at the end of dump file (as FOREIGN KEY)?
Sometimes it causes the generation of invalid dumps which cannot be
restored. Details follow.
1. I use database-dedicated search_path:
ALTER DATABASE d SET
On Wed, Nov 12, 2008 at 02:28:56PM -0800, Ron Mayer wrote:
Merging of the interval style into ecpg attached.
Thanks for caring about the ecpg changes too.
I know little enough about ecpg that I can't really tell if these changes
are for the better or worse.
The closer pgtypeslib is to the
Jeff Davis wrote:
Here's an updated patch for just array_accum() with some simple docs.
I have committed a best of Robert Haas and Jeff Davis array_agg()
function with standard SQL semantics. I believe this gives the best
consistency with other aggregate functions for the no-input-rows
I did this:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00156.php
to try to fix this:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhaldt=2008-11-12%2021:00:01
only to get this:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=narwhaldt=2008-11-13%2015:00:01
Anybody know
Per bug #4528, I'm thinking we should do $SUBJECT. I'm inclined to
put a tz_acceptable() check into pg_tzenumerate_next, which is currently
only used by that view but might be used for other purposes later.
Any objections?
regards, tom lane
--
Sent via pgsql-hackers
Magnus Hagander [EMAIL PROTECTED] writes:
I am unsure of exactly where this thing hacks into the authentication
stream, but is it really only MD5 that fails?
The problem with md5 is that the username is part of the encryption salt
for the stored password, so changing it breaks that --- the
Gregory Stark wrote:
I think we're talking past each other. Martin and I are talking about doing
something like:
for (...)
...
crc(word including hint bits)
...
for (each line pointer)
crc-negated(word LP_DEAD15)
Because CRC is a cyclic checksum it's possible to add or
Greg,
Attached version takes all its input via command line switches. If you
don't specify an explict number of connections, it also implements
setting max_connections via some of the logic from your calcfactors
spreadsheet.
OK, I'll review. What follows is a review of the *previous*
Dmitry Koterov [EMAIL PROTECTED] writes:
3. The function a() calls any OTHER function b() from OTHER namespace (or
uses operators from other namespaces), but does not specify the schema name,
because it is in database search_path:
CREATE FUNCTION a(i integer) RETURNS boolean AS $$
BEGIN
Josh Berkus [EMAIL PROTECTED] writes:
DW:
default_statistics_target = 400
Mixed:
default_statistics_target = 100
You, my friend, are certifiably insane.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm still testing this; please beware that this likely has an even
higher bug density than my regular patches (and some debugging printouts
as well).
This seems impossibly fragile ... and the non-modular assumptions about
what is in a disk page aren't
Gregory Stark wrote:
Josh Berkus [EMAIL PROTECTED] writes:
DW:
default_statistics_target = 400
Mixed:
default_statistics_target = 100
You, my friend, are certifiably insane.
Hmmm? Why? I've used those settings in the field, fairly frequently.
I was actually wondering if
On Nov 11, 2008, at 10:06 PM, Robert Haas wrote:
- Should this be an optional behavior? What if I don't WANT my view
to be updateable?
That seems like a deal-breaker to me... many users could easily be
depending on views not being updateable. Views are generally always
thought of as
Greg,
BTW, I think this is still in enough flux that we really ought to make
it a pgfoundry project. I don't think we'll have anything ready for 8.4
contrib.
--Josh
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Decibel! [EMAIL PROTECTED] writes:
That seems like a deal-breaker to me... many users could easily be
depending on views not being updateable. Views are generally always
thought of as read-only, so you should need to explicitly mark a view
as being updateable/insertable/deleteable.
The
Josh,
Actually that is a poorly worded page. It really should be something
like, How to submit a patch or How to get your patch committed.
Yeah, I told Bruce I was going to re-write that page but seem to have
been short some Round Tuits.
--Josh
--
Sent via pgsql-hackers mailing list
Tom Lane wrote:
And it's not even
clear to me that it fixes the problem: wouldn't you get two different
handles if you supplied the internal and external addresses of an
eventproc?
Both #1 and #4 suffer from this issue, internal external register
methods. They also require the same
Josh Berkus [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Josh Berkus [EMAIL PROTECTED] writes:
DW:
default_statistics_target = 400
Mixed:
default_statistics_target = 100
You, my friend, are certifiably insane.
Hmmm? Why? I've used those settings in the field, fairly frequently.
I think I'm missing something...
In this patch, I see you writing WAL records for hint-bits (bufmgr.c
FlushBuffer). But doesn't XLogInsert then make a backup block record (unless
it's already got one since last checkpoint)?
Once there's a backup block record, the torn-page problem that causes
Tom Lane wrote:
Basically, you can't make any critical changes to a shared buffer
if you haven't got exclusive lock on it. But that's exactly what
this patch is assuming it can do.
It seems to me that the only possible way to close this hole is to
acquire an exclusive lock before calling
Aidan Van Dyk wrote:
I think I'm missing something...
In this patch, I see you writing WAL records for hint-bits (bufmgr.c
FlushBuffer). But doesn't XLogInsert then make a backup block record
(unless
it's already got one since last checkpoint)?
I'm not causing a backup block to be
Jeff Davis [EMAIL PROTECTED] writes:
Thanks! This patch is ready to go, as far as I'm concerned.
This patch seems to contain a subset of the contrib infrastructure
patch that's listed separately on the commitfest page. While I have
no strong objection to what's here, I'm wondering what sort of
A statistic target of 400 fir a specific column may make sense but
even then I would recommend monitoring performance to ensure it
doesn't cause problems. As a global setting it's, IMHO, ridiculous.
Even for the smaller data types (except boolean and char) and array
of 400 will be large
Gregory Stark wrote:
Josh Berkus [EMAIL PROTECTED] writes:
DW:
default_statistics_target = 400
Mixed:
default_statistics_target = 100
You, my friend, are certifiably insane.
I almost fell off the chair because of that comment, but after I stopped
laughing and actually
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Basically, you can't make any critical changes to a shared buffer
if you haven't got exclusive lock on it. But that's exactly what
this patch is assuming it can do.
It seems to me that the only possible way to close this hole is to
Alvaro Herrera wrote:
Tom Lane wrote:
Basically, you can't make any critical changes to a shared buffer
if you haven't got exclusive lock on it. But that's exactly what
this patch is assuming it can do.
It seems to me that the only possible way to close this hole is to
acquire an
Heikki Linnakangas [EMAIL PROTECTED] writes:
A lot of people have suggested raising our default_statistics target,
and it has been rejected because there's some O(n^2) behavior in the
planner, and it makes ANALYZE slower, but it's not that crazy.
I think everyone agrees it ought to be
Alvaro Herrera wrote:
XFS, for example, zeroes out during recovery any block
that was written to but not fsync'ed before a crash. This means that if
we change a hint bit after a checkpoing and mark the page dirty, the
system can write the page. Suppose we crash at this point. On
recovery, XFS
Hi,
since my last email seems to have disappeared, here we go again. Here's my
current patch that includes the changes to the build system. Thanks to Magnus
for the Windows part.
Comments anyone?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
A lot of people have suggested raising our default_statistics target,
and it has been rejected because there's some O(n^2) behavior in the
planner, and it makes ANALYZE slower, but it's not that crazy.
I think everyone agrees it
Heikki Linnakangas wrote:
Alvaro Herrera wrote:
XFS, for example, zeroes out during recovery any block
that was written to but not fsync'ed before a crash. This means that if
we change a hint bit after a checkpoing and mark the page dirty, the
system can write the page. Suppose we crash at
Michael Meskes [EMAIL PROTECTED] writes:
since my last email seems to have disappeared, here we go again. Here's my
current patch that includes the changes to the build system. Thanks to Magnus
for the Windows part.
Comments anyone?
+ $(srcdir)/preproc.y:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Another idea would be to take a large sample in ANALYZE, but if the
distribution looks regular enough, store less samples in the
Most-Common-Values list and fewer histograms, to make the planning faster.
Yeah, some flexibility at that end might
On 2008-11-13, at 19:33, Greg Stark wrote:
A statistic target of 400 fir a specific column may make sense but
even then I would recommend monitoring performance to ensure it
doesn't cause problems. As a global setting it's, IMHO, ridiculous.
If that's the situation, me thinks you guys
Andrew Chernow [EMAIL PROTECTED] writes:
Here are the options we see:
1. PQregisterEventProc returns a handle, synchronized counter
incremented by libpq. A small table could map handle value to proc
address, so register always returns the same handle for a provided
eventproc. Only
Michael Meskes [EMAIL PROTECTED] writes:
That's what I did first, but Magnus had a good reasoning to not keep preproc.y
if we keep preproc.c in our tarball. And I agreed that there doesn't seem to
be
an advantage.
Other than whether it *works*, you mean?
make will not be happy if it has a
On Thu, Nov 13, 2008 at 03:10:04PM -0500, Tom Lane wrote:
clean distclean:
! rm -f keywords.c *.o ecpg$(X) preproc.y
Actually, we want to fix it so that preproc.y is treated like preproc.c,
ie, it's part of the shipped tarballs even though it's no longer in CVS.
That's what I did
On Thu, Nov 13, 2008 at 3:20 PM, Grzegorz Jaskiewicz
[EMAIL PROTECTED] wrote:
If that's the situation, me thinks you guys have to start thinking about
some sort of automated way to increase this param per column as needed.
Is there any way planner could actually tell, that it would do better
* Tom Lane [EMAIL PROTECTED] [081113 14:43]:
Well, if we adopt the double buffering approach then the ex-lock would
only need to be held for long enough to copy the page contents to local
memory. So maybe this would be acceptable. It would certainly be a
heck of a lot simpler than any
- make check fails 16 of 118 tests for me with this patch applied.
Most of them are caused by additional NOTICE messages or unexpected
additional rules in the rewriter regression tests. I don't see anything
critical here.
Possible; in that case you should patch the expected regression output
On Thu, 2008-11-13 at 14:31 -0500, Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Thanks! This patch is ready to go, as far as I'm concerned.
This patch seems to contain a subset of the contrib infrastructure
patch that's listed separately on the commitfest page. While I have
no
On Thu, Nov 13, 2008 at 01:45:52PM -0500, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I'm still testing this; please beware that this likely has an even
higher bug density than my regular patches (and some debugging printouts
as well).
This seems impossibly fragile ... and
On Thu, 13 Nov 2008, Josh Berkus wrote:
don't bother with os.sysconf, or make it optional and error-trap it.
Right, I've moved in that direction in the updated rev I already
sent--memory is an input value, but if you leave it out it tries to guess.
Just need a bit more error trapping around
On Thu, 2008-11-13 at 20:33 +0100, Greg Stark wrote:
A statistic target of 400 fir a specific column may make sense but
even then I would recommend monitoring performance to ensure it
doesn't cause problems. As a global setting it's, IMHO, ridiculous.
Even for the smaller data types
Martijn van Oosterhout [EMAIL PROTECTED] writes:
Actually, the real problem to me seems to be that to check the checksum
when you read the page in, you need to look at the contents of the page
and assume some of the values in there are correct, before you can
even calculate the checksum. If
Tom,
Even though we all agree default_statistics_target = 10 is too low,
proposing a 40X increase in the default value requires more evidence
than this. In particular, the prospect of a 1600-fold increase in
the typical cost of eqjoinsel() is a mite scary.
It's a *completely* acceptable
Simon,
In any case, saying that somebody is certifiably insane in a public
forum is at best questionable. I would like to see the comment
withdrawn.
Thanks for defending me. I think Greg threw that at me because he knows
I'm very difficult to offend, though. I assume that Greg wouldn't make
On Thu, 13 Nov 2008, Josh Berkus wrote:
Even though we all agree default_statistics_target = 10 is too low,
proposing a 40X increase in the default value requires more evidence
than this. In particular, the prospect of a 1600-fold increase in
the typical cost of eqjoinsel() is a mite scary.
listen_addresses = '*'
This doesn't seem like a good thing to autogenerate from a security
perspective. I think we should not attempt to guess the user's
requirements in this area.
max_fsm_pages = DBsize / PageSize / 8
Isn't this moot for 8.4?
...Robert
--
Sent via
Peter Eisentraut [EMAIL PROTECTED] writes:
Jeff Davis wrote:
Here's an updated patch for just array_accum() with some simple docs.
I have committed a best of Robert Haas and Jeff Davis array_agg()
function with standard SQL semantics. I believe this gives the best
consistency with other
On 2008-11-08 09:25, Benedek László wrote:
Does this work if the role name contains a ' ?
Right, this one fails with ' in the role name. An update coming soon
closing this issue.
Here is an updated patch, which deals with 's in the rolename.
Please review.
doc/src/sgml/ref/pg_dump.sgml
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Attached patch has this fixed and still passes all regression tests,
etc.
Do you have an up-to-date patch laying around? The current one conflicts
with some CVS tip changes.
No, not yet. I suspect the array_agg
Tom Lane wrote:
Still, I agree that the whole thing looks too Rube Goldbergian to count
as a reliability enhancer, which is what the point is after all.
Agreed.
I think the argument is about whether we increase our vulnerability to
torn-page problems if we just add a CRC and don't do
Josh Berkus wrote:
Thanks for defending me. I think Greg threw that at me because he knows
I'm very difficult to offend, though. I assume that Greg wouldn't make a
post like that to other members of the community.
I would print it and frame it to hang somewhere in the office ... or
maybe
Tom Lane wrote:
The original reason for doing this work, I think, was to let us
deprecate contrib/intagg, or at least turn it into a thin wrapper
around core-provided functionality. We now have the means to do that
for int_array_aggregate, but what about int_array_enum?
And what about the
On Thu, 2008-11-13 at 17:21 -0500, Greg Smith wrote:
On Thu, 13 Nov 2008, Josh Berkus wrote:
BTW, I think this is still in enough flux that we really ought to make
it a pgfoundry project. I don't think we'll have anything ready for 8.4
contrib.
I find your lack of faith disturbing.
On Thu, 2008-11-13 at 18:07 -0500, Greg Smith wrote:
On Thu, 13 Nov 2008, Josh Berkus wrote:
Since Josh's latest parameter model takes a database size as an input,
perhaps a reasonable way to proceed here is to put the DW model into size
tiers. Something like this:
DW
On Thu, 13 Nov 2008, Robert Haas wrote:
listen_addresses = '*'
This doesn't seem like a good thing to autogenerate from a security
perspective. I think we should not attempt to guess the user's
requirements in this area.
Yeah, I don't want to be the guy who flips the switch for
It seems that it would be an easy evening's work to implement unnest(),
at least in the simple form
function unnest(anyarray) returns setof anyelement
without the WITH ORDINALITY syntax proposed by the SQL spec. Then
we could eliminate intagg's C code altogether, and just write it
- StrategyFileStrategy doesn't handle the recently added BAS_BULKWRITE
strategy. I'm not sure whether it needs to, but it seems to me that
this a trap for the unwary: we should probably add a comment where the
BAS_* constants are defined warning that any changes here may/will
also
I was trying to call the array_in() function using the
DirectFunctionCall3() interface. It fails as the code in array_in()
tries to refer to fcinfo-flinfo-fnextra where flinfo is set to NULL by
the DirectFunctionCall3() interface. I am not sure if this is a bug or
that we are not supposed to
I was pretty leery about reviewing this one due to the feeling that I
might well be in over my head, but they talked me into it, so here
goes nothin'. Apologies in advance for any deficiencies in this
review.
- Overall, this looks pretty clean. The style appears to be
consistent with the
Simon Riggs [EMAIL PROTECTED] writes:
Your factual comments are accurate, but for Josh's stated target of Data
Warehousing, a stats target of 400 is not unreasonable in some cases.
What you forget to mention is that sample size is also determined by
stats target and for large databases this
It looks to me like section 34.10 of the docs might benefit from some
sort of update in light of this patch, since the builtin array_agg now
does the same thing as the proposed user-defined array_accum, only
better. Presumably we should either pick a different example, or add
a note that a
So I went off to convert contrib/intagg to a wrapper around the new core
functions, along this line:
CREATE OR REPLACE FUNCTION int_agg_state (internal, int4)
RETURNS internal
AS 'array_agg_transfn'
LANGUAGE INTERNAL;
CREATE OR REPLACE FUNCTION int_agg_final_array (internal)
RETURNS int4[]
AS
In any case, saying that somebody is certifiably insane in a public
forum is at best questionable. I would like to see the comment
withdrawn.
I'm not too nervous that Josh might have actually thought I thought he was
really insane. (Or for that matter that anyone else reading it might have
Ashish Kamra [EMAIL PROTECTED] writes:
I was trying to call the array_in() function using the
DirectFunctionCall3() interface. It fails as the code in array_in()
tries to refer to fcinfo-flinfo-fnextra where flinfo is set to NULL by
the DirectFunctionCall3() interface. I am not sure if this
Stephen Frost wrote:
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Attached patch has this fixed and still passes all regression tests,
etc.
Do you have an up-to-date patch laying around? The current one conflicts
with some CVS tip changes.
No, not
Jonah H. Harris wrote:
On Thu, Nov 13, 2008 at 3:20 PM, Grzegorz Jaskiewicz
[EMAIL PROTECTED] wrote:
If that's the situation, me thinks you guys have to start thinking about
some sort of automated way to increase this param per column as needed.
Is there any way planner could actually tell,
87 matches
Mail list logo
