On Thu, Aug 12, 2010 at 12:49 AM, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
Do we really think this is anywhere near committable now?
There's a relatively objective standard for the first thing needed for
commit--does it work?--in the form of the regression tests Simon put
2010/8/11 Robert Haas robertmh...@gmail.com:
On Wed, Aug 11, 2010 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, at least in the usage in that loop,
Really?
FOR var IN SELECT UNNEST(arr) LOOP ... END LOOP
I mean, doing everything is sort of clunky in PL/pgsql, but this
doesn't seem particularly bad as PL/pgsql idioms go.
this simple construction can take much more memory than other. I
proposed two or three years ago FOREACH statement
I definitely agree that PL/pgsql could be more usable. Or if not,
then some other PL with a better overall design could be more usable.
I am not entirely sure how to create such a thing, however.
Would the standard plpsm be just that? Pavel maintains a pg implémentation of
it, I believe.
2010/8/12 Dimitri Fontaine dfonta...@hi-media.com:
I definitely agree that PL/pgsql could be more usable. Or if not,
then some other PL with a better overall design could be more usable.
I am not entirely sure how to create such a thing, however.
Would the standard plpsm be just that? Pavel
Hi,
When I was enjoying reading the HS source code,
I found some typos. Attached patch fixes them.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
hs_typo_v1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
[..]
Bozena Potempa bozena.pote...@otc.pl writes:
I have a test table with varchar(40) column. After executing the
following
query:
select substr(fc,1,2) from test
PQftype returns for the result column PG_TYPE_TEXT and
PQfsize returns -1.
Is it
On ons, 2010-08-11 at 16:17 -0400, Tom Lane wrote:
We should have the buildfarm configuration such that any one run uses
the same port number for both installed and uninstalled regression
tests.
I'm getting lost here what the actual requirements are. The above is
obviously not going to work
On ons, 2010-08-11 at 15:06 -0400, Andrew Dunstan wrote:
You original email said:
For some historic reasons, I have my local scripts set up so
that they build development instances using the hardcoded port
65432.
I think my response would be Don't do that.
Do you
On 08/12/2010 08:43 AM, Peter Eisentraut wrote:
On ons, 2010-08-11 at 15:06 -0400, Andrew Dunstan wrote:
You original email said:
For some historic reasons, I have my local scripts set up so
that they build development instances using the hardcoded port
65432.
I
Hello
attached updated \sf implementation. It is little bit simplyfied with
support a pager and output forwarding. Formating was updated per Tom's
request.
Regards
Pavel Stehule
BTW, the last I looked, \sf+ was using what I thought to be a quite ugly
and poorly-considered formatting for the
Bozena Potempa bozena.pote...@otc.pl writes:
Thank you. In this case (substring) there is no much to predict, just a
simple calculation, but I understand that it is a part of larger and more
complicated functionality. I tried to find a workaround with a type cast:
select
Peter Eisentraut pete...@gmx.net writes:
On ons, 2010-08-11 at 16:17 -0400, Tom Lane wrote:
We should have the buildfarm configuration such that any one run uses
the same port number for both installed and uninstalled regression
tests.
I'm getting lost here what the actual requirements are.
On Thu, Aug 12, 2010 at 2:24 AM, Boxuan Zhai bxzhai2...@gmail.com wrote:
Sorry for the mismatch problem of regress. In fact, I am still unable to
make the regression test run on my machine. When I try the command
pg_regreess in /src/test/regress/, it always gives a FATAL error:
The intention
On 08/12/2010 10:22 AM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net writes:
On ons, 2010-08-11 at 16:17 -0400, Tom Lane wrote:
We should have the buildfarm configuration such that any one run uses
the same port number for both installed and uninstalled regression
tests.
I'm getting
Hey all,
Is it guaranteed that functions, which accept PGconn* (PGresult*)
properly works if PGconn* (PGresult*) is NULL or is it better to check
on NULL the value of the pointer before calling those functions?
Regards,
Dmitriy
Dmitriy Igrishin dmit...@gmail.com writes:
Is it guaranteed that functions, which accept PGconn* (PGresult*)
properly works if PGconn* (PGresult*) is NULL or is it better to check
on NULL the value of the pointer before calling those functions?
I think they all do check for NULL, but whether
Hey all,
It seams, that all of the error codes should be obtained by calling
PQresultErrorField().
But this function works only with results. So in what situations
TOO MANY CONNECTIONS error may be thrown after successfully connection ? :)
In case of dblink?
Regards,
Dmitriy
New numbers on where we are with this CommitFest, at the end of the
fourth week:
72 patches were submitted
3 patches were withdrawn (deleted) by their authors
12 patches were moved to CommitFest 2010-09
--
57 patches in CommitFest 2010-07
--
3 committed to 9.0
--
54 patches for 9.1
--
1
Robert Haas robertmh...@gmail.com writes:
Here's an updated patch, with the invalidation changes merged in and
hopefully-suitable adjustments elsewhere.
I haven't tested this patch, but I read through it (and have I mentioned
how unbelievably illegible -u format patches are?). It seems to be
On Thu, Aug 12, 2010 at 12:27:45PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Here's an updated patch, with the invalidation changes merged in and
hopefully-suitable adjustments elsewhere.
I haven't tested this patch, but I read through it (and have I mentioned
how
On Thu, 2010-08-12 at 09:44 -0700, David Fetter wrote:
On Thu, Aug 12, 2010 at 12:27:45PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Here's an updated patch, with the invalidation changes merged in and
hopefully-suitable adjustments elsewhere.
I haven't tested
On Thu, Aug 12, 2010 at 09:53:54AM -0700, Joshua D. Drake wrote:
On Thu, 2010-08-12 at 09:44 -0700, David Fetter wrote:
On Thu, Aug 12, 2010 at 12:27:45PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Here's an updated patch, with the invalidation changes merged
in
Excerpts from David Fetter's message of jue ago 12 12:59:33 -0400 2010:
On Thu, Aug 12, 2010 at 09:53:54AM -0700, Joshua D. Drake wrote:
I was under the impression that the project guideline was that we
only accepted context diffs?
Since they're trivially producible from unified diffs,
On Thu, Aug 12, 2010 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Here's an updated patch, with the invalidation changes merged in and
hopefully-suitable adjustments elsewhere.
I haven't tested this patch, but I read through it (and have I
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Thank you. In this case (substring) there is no much to
predict, just
a simple calculation, but I understand that it is a part of
larger and
more complicated functionality. I tried to find a workaround
with a type cast:
select
Greg Smith g...@2ndquadrant.com writes:
Florian Pflug wrote:
Attached is an updated version (v4).
I've attached a v5. No real code changes from Florian's version, just
some wording/style fixes and rework on the documentation.
I'm looking through this patch now. It looks mostly good, but I
Hello
I checked last version:
* there are not a problem with regress and contrib regress tests
* the design is simple and clean now - well documented
notes:
* don't get a patch via copy/paste from mailing list archive - there
are a broken xml2 tests via this access!
* I didn't find a sentence
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 12, 2010 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Lastly, it bothers me that you've put in code to delete files belonging
to temp rels during crash restart, without any code to clean up their
catalog entries. This will therefore
On Thu, Aug 12, 2010 at 2:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 12, 2010 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Lastly, it bothers me that you've put in code to delete files belonging
to temp rels during crash restart, without
Dmitriy Igrishin dmit...@gmail.com writes:
It seams, that all of the error codes should be obtained by calling
PQresultErrorField().
But this function works only with results. So in what situations
TOO MANY CONNECTIONS error may be thrown after successfully connection ? :)
It isn't.
The lack
Kevin Grittner kevin.gritt...@wicourts.gov writes:
With about 56 hours left until the close of the CommitFest, we're
down to two Ready for Committer and three other potentially
committable patches.
I'm working on the pgbench latency patch now, and expect to have it
committed today. I'll look
Greg Smith g...@2ndquadrant.com writes:
Florian Pflug wrote:
Attached is an updated version (v4).
I've attached a v5.
BTW, I discovered a rather nasty shortcoming of this patch on platforms
without ENABLE_THREAD_SAFETY. It doesn't work, and what's worse, it
*looks* like it's working, because
On Wed, Aug 11, 2010 at 10:25 AM, Robert Haas robertmh...@gmail.com wrote:
[request form more information]
Per off-list discussion with Alanoly, we've determined the following:
dblink was compiled with the same flags as libpqwalreciever
dblink works
libpqwalreceiver crashes
--
Robert Haas
Greg Smith g...@2ndquadrant.com writes:
I've attached a v5. No real code changes from Florian's version, just
some wording/style fixes and rework on the documentation.
I've committed this with some editorialization. The main non-cosmetic
change was that I pulled the latency statistics
Excerpts from Robert Haas's message of jue ago 12 13:29:57 -0400 2010:
We have two existing mechanisms for removing the catalog entries: when
a backend is first asked to access a temporary file, it does a DROP
SCHEMA ... CASCADE on any pre-existing temp schema. And a table is in
wraparound
Robert Haas robertmh...@gmail.com writes:
Per off-list discussion with Alanoly, we've determined the following:
dblink was compiled with the same flags as libpqwalreciever
dblink works
libpqwalreceiver crashes
I wonder if the problem is not so much libpqwalreceiver as the
walreceiver
I wrote:
I wonder if the problem is not so much libpqwalreceiver as the
walreceiver process. Maybe an ordinary backend process does some
prerequisite initialization that walreceiver is missing. Hard to
guess what, though ... I can't think of anything dlopen() depends on
that should be under
On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of jue ago 12 13:29:57 -0400 2010:
We have two existing mechanisms for removing the catalog entries: when
a backend is first asked to access a temporary file, it does a DROP
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
What about having autovacuum silenty drop the catalog entry if it's a
temp entry for which the underlying file does not exist?
I think that would be subject to race
One other thought about all this: in the past, one objection that's been
raised to deleting files during crash restart is the possible loss of
forensic evidence. It might be a good idea to provide some fairly
simple way for developers to disable that deletion subroutine. I'm not
sure that it
On Aug12, 2010, at 19:48 , Tom Lane wrote:
Greg Smith g...@2ndquadrant.com writes:
Florian Pflug wrote:
Attached is an updated version (v4).
I've attached a v5. No real code changes from Florian's version, just
some wording/style fixes and rework on the documentation.
I'm looking
On Thu, Aug 12, 2010 at 5:02 AM, Fujii Masao masao.fu...@gmail.com wrote:
When I was enjoying reading the HS source code,
I found some typos. Attached patch fixes them.
I've committed all of this except for the following, which I'm not
certain is correct:
---
On Thu, Aug 12, 2010 at 6:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
What about having autovacuum silenty drop the catalog entry if it's a
temp entry for which the
Tom Lane wrote:
It could be fixed with enough effort, by having the child threads pass
back their numbers through the child-to-parent pipes. I'm not
interested in doing that myself though.
That does seem an improvement with a very limited user base it's
applicable to. Probably the next
On Thu, Aug 12, 2010 at 12:11 AM, Fujii Masao masao.fu...@gmail.com wrote:
It appears to me that RecordTransactionCommit() only needs to WAL-log
shared invalidation messages when wal_level is hot_standby, but I
don't see a guard to prevent it from doing it in all cases.
[...]
The fix looks
On Thu, Aug 12, 2010 at 7:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One other thought about all this: in the past, one objection that's been
raised to deleting files during crash restart is the possible loss of
forensic evidence. It might be a good idea to provide some fairly
simple way for
On Fri, Aug 13, 2010 at 8:28 AM, Robert Haas robertmh...@gmail.com wrote:
I've committed all of this except for the following, which I'm not
certain is correct:
Thanks for the commit.
--- a/src/backend/access/transam/clog.c
+++ b/src/backend/access/transam/clog.c
@@ -355,10 +355,10 @@
On Fri, Aug 13, 2010 at 10:24 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 12, 2010 at 12:11 AM, Fujii Masao masao.fu...@gmail.com wrote:
It appears to me that RecordTransactionCommit() only needs to WAL-log
shared invalidation messages when wal_level is hot_standby, but I
don't
Florian Pflug f...@phlo.org writes:
On Aug12, 2010, at 19:48 , Tom Lane wrote:
I'm looking through this patch now. It looks mostly good, but I am
wondering just exactly what is the rationale for adding comment
statements to the data structures, rather than ignoring them as before.
To be
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 12, 2010 at 7:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One other thought about all this: in the past, one objection that's been
raised to deleting files during crash restart is the possible loss of
forensic evidence.
... With this
On Thu, Aug 12, 2010 at 2:12 PM, Robert Haas robertmh...@gmail.com wrote:
That seems like a good idea. I'll post an updated patch.
Here is an updated patch. It's in context-diff format this time, but
that made it go over 100K, so I gzip'd it because I can't remember
what the attachment size
52 matches
Mail list logo
