On 13/08/10 09:27, Boxuan Zhai wrote:
I have renewed the merge.sql and merge.out in regress. Please have a look.
Thanks.
Did you change the way DO INSTEAD rules are handled already?
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00151.php
--
Heikki Linnakangas
EnterpriseDB ht
On Thu, Aug 12, 2010 at 2:12 PM, Robert Haas 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 limit is these days. I
Robert Haas writes:
> On Thu, Aug 12, 2010 at 7:04 PM, Tom Lane 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 patch, we can be sure of removing ALL
Florian Pflug 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 able to i
On Fri, Aug 13, 2010 at 10:24 AM, Robert Haas wrote:
> On Thu, Aug 12, 2010 at 12:11 AM, Fujii Masao 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
On Fri, Aug 13, 2010 at 8:28 AM, Robert Haas 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 @@ TransactionIdSetStatus
On Thu, Aug 12, 2010 at 7:04 PM, Tom Lane 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 developers to di
On Thu, Aug 12, 2010 at 12:11 AM, Fujii Masao 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 pretty
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 us
On Thu, Aug 12, 2010 at 6:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera
>> 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 su
On Thu, Aug 12, 2010 at 5:02 AM, Fujii Masao 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:
--- a/src/backend/access/transam/clog.c
+++ b/src/backend/
On Aug12, 2010, at 19:48 , Tom Lane wrote:
> Greg Smith 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
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 rise
Robert Haas writes:
> On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera
> 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 conditions.
Well, autovacuum's willingness
On Thu, Aug 12, 2010 at 5:29 PM, Alvaro Herrera
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
>> SCHEMA ... CASCADE o
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 u
Robert Haas 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 process. Maybe an ordina
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
> wraparoun
Greg Smith 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 counters out of the
per-C
On Wed, Aug 11, 2010 at 10:25 AM, Robert Haas 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
EnterpriseDB: http://www
Greg Smith 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 it gives you pla
"Kevin Grittner" 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 at xml_is_well_formed
Dmitriy Igrishin 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 of a way to r
On Thu, Aug 12, 2010 at 2:06 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 12, 2010 at 12:27 PM, Tom Lane 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.
Robert Haas writes:
> On Thu, Aug 12, 2010 at 12:27 PM, Tom Lane 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 lead to dangling pg_class
>> referen
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 so
Greg Smith 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 am
wondering ju
>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 substr
On Thu, Aug 12, 2010 at 12:27 PM, Tom Lane wrote:
> Robert Haas 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
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 dif
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 writes:
> > > > Here's an updated patch, with the invalidation changes merged
> > > > in and hop
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 writes:
> > > Here's an updated patch, with the invalidation changes merged in and
> > > hopefully-suitable adjustments elsewhere.
> >
> > I haven't tested this patch
On Thu, Aug 12, 2010 at 12:27:45PM -0400, Tom Lane wrote:
> Robert Haas 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 il
Robert Haas 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
close to commitable,
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 reject
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
Dmitriy Igrishin 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 they give back a
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
On 08/12/2010 10:22 AM, Tom Lane wrote:
Peter Eisentraut 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
On Thu, Aug 12, 2010 at 2:24 AM, Boxuan Zhai 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 is that you should
Peter Eisentraut 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. The abo
"Bozena Potempa" 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 substr(fc,1,2)::varchar(2) from test
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 t
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 th
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".
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
>From: Tom Lane [mailto:t...@sss.pgh.pa.us]
[..]
>"Bozena Potempa" 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 the
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 (pgsql-hacke
2010/8/12 Dimitri Fontaine :
>> 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
49 matches
Mail list logo
