On Tue, Nov 25, 2008 at 1:42 AM, Robert Treat
[EMAIL PROTECTED] wrote:
We actually have such a database on pgfoundry already
(http://pgfoundry.org/frs/download.php/1719/pagila-0.10.1.zip), which i think
devrim may have packaged into an rpm; it wouldn't hurt to add it to the win32
installer,
Hiroshi Saito [EMAIL PROTECTED] wrote:
Umm, format operand seems to be a wide character sequence.
Here is a patch to work around the wide character format string.
The hack is the following line:
+#define strftime(a,b,c,d) strftime_win32(a,b,L##c,d)
We use only literals in the format
On Tue, Nov 25, 2008 at 11:42 AM, ITAGAKI Takahiro
[EMAIL PROTECTED] wrote:
Fujii Masao [EMAIL PROTECTED] wrote:
On Fri, Nov 14, 2008 at 7:15 PM, Fujii Masao [EMAIL PROTECTED] wrote:
Attached is the latest version of Synch Rep patch. Sorry for my late
posting.
I fixed some bugs in v1patch
Dave Page wrote:
On Tue, Nov 25, 2008 at 1:42 AM, Robert Treat
[EMAIL PROTECTED] wrote:
We actually have such a database on pgfoundry already
(http://pgfoundry.org/frs/download.php/1719/pagila-0.10.1.zip), which i think
devrim may have packaged into an rpm; it wouldn't hurt to add it to the
The following sequence of commands causes server crash.
postgres=# BEGIN TRANSACTION READ WRITE ;
BEGIN
postgres=# SELECT * FROM pg_class FOR UPDATE;
FATAL: cannot assign TransactionIds during recovery
STATEMENT: SELECT * FROM pg_class FOR UPDATE;
FATAL: cannot assign TransactionIds during
While hacking on parser/gram.y just now I noticed in passing that the
automatically generated ecpg parser had 402 shift/reduce conflicts.
(Don't panic, the parser in CVS is fine.) If you don't pay very close
attention, it is easy to miss this. Considering also that we frequently
have to
Peter Eisentraut wrote:
Looks very good, please continue.
Thanks, will do :)
On your wiki page, you have this example:
CREATE SERVER userdb TYPE 'plproxy_cluster'
FOREIGN DATA WRAPPER plproxy
OPTIONS (
server='dbname=userdb_p0 host=127.0.0.1 port=6000',
Peter Eisentraut wrote:
Here is an implementation of distinct types,
I'm withdrawing this patch from the current commit fest for further
work. For the record, I have attached the current patch, including the
documentation work by Jeff Davis.
Index: doc/src/sgml/ref/create_domain.sgml
On Tue, Nov 25, 2008 at 7:31 PM, Dave Page [EMAIL PROTECTED] wrote:
I'm in favour of including it by default (at initdb), so it's there
for new users to play with on any fresh install ...
Could we perhaps punt on the issue of whether to install the
sampledb by default. It could be controlled
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be an internal module name
but it should be a feature name (ex. 'replication').
Agreed. The name 'replication' is more suitable, I also think.
Any
Exporting PGINTERVALSTYLE causes errors of the following kind when
connecting to an older server version:
psql: FATAL: unrecognized configuration parameter intervalstyle
Should the processing of this variable be made conditional upon the
server version?
(What is the use case for this
Magnus Hagander wrote:
Heikki Linnakangas wrote:
Magnus Hagander wrote:
Log Message:
---
Silence compiler warning about ignored return value. Our comment already
clearly stated that we are aware that we're ignoring it.
I think the usual way is to call the function like:
(void)
Hi ITAGAKI-san.
Um, It was not supported.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
The test of my various past is reproduced. Then, I proposed the management
regarded as best in them. and, to Magnus-san.
Does the reason for persisting in wsftime exceed
Peter Eisentraut [EMAIL PROTECTED] writes:
While hacking on parser/gram.y just now I noticed in passing that the
automatically generated ecpg parser had 402 shift/reduce conflicts.
(Don't panic, the parser in CVS is fine.) If you don't pay very close
attention, it is easy to miss this.
Pavan Deolasee [EMAIL PROTECTED] writes:
I think we should disallow starting a read-write transaction during
recovery. The patch attempts to do that by setting transaction mode to
read-only, but not enough to prevent somebody to explicitly mark the
transaction as read-write.
Huh? The read
Dave Page [EMAIL PROTECTED] writes:
I'm in favour of including it by default (at initdb), so it's there
for new users to play with on any fresh install - however, there is
only a point to that if all the documentation examples are based on
that database to allow copy-paste-play.
You would
Peter Eisentraut [EMAIL PROTECTED] writes:
Exporting PGINTERVALSTYLE causes errors of the following kind when
connecting to an older server version:
psql: FATAL: unrecognized configuration parameter intervalstyle
Ooops.
(What is the use case for this variable anyway? Is it there just
On Tue, Nov 25, 2008 at 1:23 PM, Tom Lane [EMAIL PROTECTED] wrote:
Dave Page [EMAIL PROTECTED] writes:
I'm in favour of including it by default (at initdb), so it's there
for new users to play with on any fresh install - however, there is
only a point to that if all the documentation examples
On Tue, Nov 25, 2008 at 6:55 PM, Tom Lane [EMAIL PROTECTED] wrote:
Huh? The read only transaction mode is not hard read-only anyway,
so if that's the only step being taken, it's entirely useless.
I think there are explicit checks for some utility statements (like VACUUM),
but I haven't
Peter Eisentraut wrote:
== removing existing temp installation==
== creating temporary installation==
== initializing database system ==
== starting postmaster
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be an internal module name
but it should be a feature name (ex. 'replication').
Agreed. The name 'replication' is
Peter Eisentraut [EMAIL PROTECTED] writes:
I played around a little with signal handling to collect the dying
postmaster and report and error; see attached rough patch. I'm not
exactly understanding how this works though. I would expect lots of
psql zombies for example, because those go
On Tue, Nov 25, 2008 at 8:23 AM, Tom Lane [EMAIL PROTECTED] wrote:
Dave Page [EMAIL PROTECTED] writes:
I'm in favour of including it by default (at initdb), so it's there
for new users to play with on any fresh install - however, there is
only a point to that if all the documentation examples
Tom Lane wrote:
Better to provide the sample database in a
form in which it can be easily dropped/reloaded. I'm envisioning that
there's a source file in $sharedir and we tell people
createdb example
psql -f $sharedir/example.sql example
This
I wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
(What is the use case for this variable anyway? Is it there just
because PGDATESTYLE was there previously?)
Pretty much. I'd be fine with taking it out entirely.
Actually ... I started to take this out and replace
***
Hi,
In current pg_standby, the presence of the trigger file causes
recovery to end whether or not the next WAL file is available.
Thereby, some transactions in the available WAL files will be
lost. So, we cannot use this trigger file to promote the standby
to the primary.
I'd like to add new
Tom Lane wrote:
One thing we should do is have pg_regress.c, not the Makefile,
select the default port to use. The concatenate-5 behavior is
just not intelligent enough.
How about something like this, constructing a port number from the
version and a timestamp? We could also take 2 more
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be an internal module name
but it should be a
Fujii Masao escribió:
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be an internal module
Peter Eisentraut wrote:
Tom Lane wrote:
One thing we should do is have pg_regress.c, not the Makefile,
select the default port to use. The concatenate-5 behavior is
just not intelligent enough.
How about something like this, constructing a port number from the
version and a timestamp?
I've been chewing on the problem described here:
http://archives.postgresql.org/pgsql-general/2008-11/msg01220.php
It's not particularly easy to fix without making annoyingly large
changes to the API for PQExpBuffer. The best idea I have come up
with so far goes like this:
* Upon failure to
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
One thing we should do is have pg_regress.c, not the Makefile,
select the default port to use. The concatenate-5 behavior is
just not intelligent enough.
How about something like this, constructing a port number from the
version
On Wed, Nov 26, 2008 at 12:23 AM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Fujii Masao escribió:
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use
(I'm still downloading Fedora-10)
Even though Tom is subscribed to the list below, I thought I should
forward this e-mail to this list:
Forwarded Message
From: Itamar - IspBrasil [EMAIL PROTECTED]
Reply-To: Development discussions related to Fedora
[EMAIL PROTECTED]
To:
Peter Eisentraut [EMAIL PROTECTED] wrote:
Additional processing information as discussed later in the thread
can
now be added easily, but I think there was no consensus on what
exactly
to print.
Since I use CLUSTER almost exclusively to eliminate bloat, I'd like to
see the before and
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
I think the fundamental bug here is that you tried to skip using the
ResourceOwner mechanism for snapshot references. That's basically
not gonna work.
Right :-( I'll see how to go about this.
It
Alvaro Herrera escribió:
The only thing I'm now missing is SnapshotResetXmin(). It currently
looks like this:
After the patch we don't have any way to detect whether resowner.c has
any snapshot still linked to. I assume there's no objection to adding a
new entry point in resowner.c for
Alvaro Herrera [EMAIL PROTECTED] writes:
After the patch we don't have any way to detect whether resowner.c has
any snapshot still linked to. I assume there's no objection to adding a
new entry point in resowner.c for this.
Hmm, that's a bit problematic because resowner.c doesn't have any
Alvaro Herrera wrote:
Fujii Masao escribió:
On Tue, Nov 25, 2008 at 10:57 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
Dickson S. Guedes escribió:
Fujii Masao escreveu:
(...)
Even if we need to have the database in real, I'd like to use another
name for it. The name 'walsender' seems to be
On Tue, 2008-11-25 at 19:02 +0530, Pavan Deolasee wrote:
On Tue, Nov 25, 2008 at 6:55 PM, Tom Lane [EMAIL PROTECTED] wrote:
Huh? The read only transaction mode is not hard read-only
anyway,
so if that's the only step being taken, it's entirely useless.
On Mon, Nov 24, 2008 at 10:25 AM, Marko Kreen [EMAIL PROTECTED] wrote:
On 11/24/08, Tom Lane [EMAIL PROTECTED] wrote:
Marko Kreen [EMAIL PROTECTED] writes:
It was brought to my attention that DISCARD ALL
does not release advisory locks:
What is the argument that it should?
DISCARD ALL
On Tuesday 25 November 2008 15:09:37 Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
While hacking on parser/gram.y just now I noticed in passing that the
automatically generated ecpg parser had 402 shift/reduce conflicts.
(Don't panic, the parser in CVS is fine.) If you don't
On Tuesday 25 November 2008 16:42:57 Tom Lane wrote:
--- 716,722
*/
putenv(PGTZ=PST8PDT);
putenv(PGDATESTYLE=Postgres, MDY);
! putenv(PGOPTIONS=--intervalstyle=postgres_verbose);
if (temp_install)
{
when it struck me that that's going
Stephen R. van den Berg wrote:
... it would be orders of magnitude more difficult for
a novice to create the sample database from contrib or anywhere else.
It seems to me that *this* is the more serious problem that
we should fix instead.
If, from the psql command prompt I could type:
psql=#
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
After the patch we don't have any way to detect whether resowner.c has
any snapshot still linked to. I assume there's no objection to adding a
new entry point in resowner.c for this.
Hmm, that's a bit problematic because
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
Hmm, that's a bit problematic because resowner.c doesn't have any global
notion of what resource owners exist. I think you still need to have
snapmgr.c maintain a list of all known snapshots. resowner.c can only
help you with
Peter Eisentraut [EMAIL PROTECTED] writes:
On Tuesday 25 November 2008 16:42:57 Tom Lane wrote:
! putenv(PGOPTIONS=--intervalstyle=postgres_verbose);
So I guess the real question is what is the
use case for having pg_regress talk to older servers?
There is no use. I was just
Dear PostgreSQL developers,
1
I stumbled upon an obscure bug (or undesirable feature:-) in the schema
metadata accessible through the information_schema, and possibly
pg_catalog as well. As it was mixed in a bug in some in my code, it was
hard for me to identify it.
The issue is that
Fabien COELHO [EMAIL PROTECTED] writes:
The issue is that when one does (in pg 8.3.5)
ALTER TABLE foo ADD CONSTRAINT xxx UNIQUE ON (...);
this results in a constraint *and* an index, but when one does only the
corresponding:
CREATE UNIQUE INDEX foo(...);
then the index is
Dear Tom,
The issue is that when one does (in pg 8.3.5)
ALTER TABLE foo ADD CONSTRAINT xxx UNIQUE ON (...);
this results in a constraint *and* an index, but when one does only the
corresponding:
CREATE UNIQUE INDEX foo(...);
then the index is created but there is no constraint.
Pavan Deolasee escribió:
Following test case gives a warning of snapshot not destroyed at commit
time.
CREATE TABLE test (a int);
INSERT INTO test VALUES (1);
BEGIN;
DECLARE c CURSOR FOR SELECT * FROM test FOR update;
SAVEPOINT A;
FETCH -2 FROM c;
ROLLBACK TO SAVEPOINT A;
COMMIT;
Hi,
I'm very new to hacking postgresql but am using on a very big site (
http://ojp.nationalrail.co.uk). One of the issues that we have is moving
data from a live database to a reports one. I've hacked an extra option to
pg_dump to delete from tables rather than dropping them.
Once I'm happy
On Tue, Nov 25, 2008 at 8:39 PM, Rob Kirkbride [EMAIL PROTECTED] wrote:
Hi,
I'm very new to hacking postgresql but am using on a very big site
(http://ojp.nationalrail.co.uk). One of the issues that we have is moving
data from a live database to a reports one. I've hacked an extra option to
Dave,
Ok thanks. Yes, we've got over 1/2 billion rows in one of our tables which
is interesting!
Will post back soon.
Rob
2008/11/25 Dave Page [EMAIL PROTECTED]
On Tue, Nov 25, 2008 at 8:39 PM, Rob Kirkbride [EMAIL PROTECTED]
wrote:
Hi,
I'm very new to hacking postgresql but am using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 25 nov. 08 à 20:29, Ron Mayer a écrit :
psql=# install module sampledb;
Downloading sampledb from pgfoundry...
Installing sampledb
Connecting to sampledb
sampledb=#
This could be part of an installer for PostgreSQL extensions. See
Rob Kirkbride [EMAIL PROTECTED] writes:
Once I'm happy with it (I'm a bit rusty at C!), do I post the patch here?
I would say you should post *before* you have a patch you're happy with. As
soon as you have a specific plan of what you want to do it's best to post an
outline of it. That way you
Alvaro,
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
I had a look at aclchk.c and didn't like your change to
objectNamesToOids; seems rather baroque. I changed it per the attached
patch.
I've incorporated this change.
Moreover I didn't very much like the way aclcheck_error_col is dealing
OK thanks for the advice.
What I'm trying to overcome is where we've got a long report running and the
process that is taking data from the main database cannot complete because
of the drop table. I believe a DELETE (and possibly TRUNCATE?) doesn't need
an exclusive lock on the table and
On Nov 14, 2008, at 12:12 PM, Tom Lane wrote:
hernan gonzalez [EMAIL PROTECTED] writes:
I've added an option to pg_dump to reorder
columns in the ouput CREATE TABLE dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool for reproducing your
Dimitri Fontaine [EMAIL PROTECTED] writes:
What do you dear readers think about the extension vocabulary?
+1 ... we should stay away from package unless we are going to
implement an Oracle-compatible facility. Which I don't particularly
wish to do, but we should leave it open for the future.
On Tue, Nov 25, 2008 at 11:46 AM, Devrim GÜNDÜZ [EMAIL PROTECTED] wrote:
(I'm still downloading Fedora-10)
Even though Tom is subscribed to the list below, I thought I should
forward this e-mail to this list:
Why?
Unless I'm missing something, there's far too little information here
to draw
On Tue, Nov 25, 2008 at 03:10:30PM -0600, Decibel! wrote:
IIRC the community did come to a consensus on allowing for a
different logical ordering from physical ordering, it was an issue of
actually doing the work. If this is an itch you want to scratch, you
might look into fixing that
It appears that the mingw faction of the buildfarm doesn't like this
patch:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00289.php
The failures look like the regression tests are being run with
intervalstyle = iso (the default) rather than postgres_verbose
as they ought to be.
Hitoshi Harada wrote:
2008/11/20 David Rowley [EMAIL PROTECTED]:
-- The following query gives incorrect results on the
-- maxhighbid column
SELECT auctionid,
category,
description,
highestbid,
reserve,
MAX(highestbid) OVER (ORDER BY auctionid) AS
On Nov 19, 2008, at 11:51 PM, Tom Lane wrote:
Dann Corbit [EMAIL PROTECTED] writes:
I think the idea that there IS a magic number is the problem.
No amount of testing is ever going to refute the argument that,
under
some other workload, a different value might better.
But that doesn't
On Nov 23, 2008, at 3:18 PM, Tom Lane wrote:
So it seems like we do indeed want to rejigger autovac's rules a bit
to account for the possibility of wanting to apply vacuum to get
visibility bits set.
That makes the idea of not writing out hint bit updates unless the
page is already dirty a
On Mon, 2008-11-24 at 22:09 +0900, KaiGai Kohei wrote:
I removed the two hooks at the r1244 patch set.
As you said, it is fundamentally danger to load uncertain binary modules.
Thus, what we should do is checks on module loading.
The default security policy requires loadable modules to be
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Tue, Nov 25, 2008 at 03:10:30PM -0600, Decibel! wrote:
IIRC the community did come to a consensus on allowing for a
different logical ordering from physical ordering, it was an issue of
actually doing the work. If this is an itch you want
Decibel! [EMAIL PROTECTED] writes:
The thought occurs to me that we're looking at this from the wrong
side of the coin. I've never, ever seen query plan time pose a
problem with Postgres, even without using prepared statements.
That tells more about the type of queries you tend to run than
Simon Riggs wrote:
On Mon, 2008-11-24 at 22:09 +0900, KaiGai Kohei wrote:
I removed the two hooks at the r1244 patch set.
As you said, it is fundamentally danger to load uncertain binary modules.
Thus, what we should do is checks on module loading.
The default security policy requires
Decibel! [EMAIL PROTECTED] writes:
Is there even a good way to find out what planning time was? Is there a way
to
gather that stat for every query a session runs?
\timing
explain select ...
The thought occurs to me that we're looking at this from the wrong side of
the
coin. I've
-Original Message-
From: Greg Stark [mailto:[EMAIL PROTECTED] On Behalf Of
Gregory Stark
Sent: Tuesday, November 25, 2008 5:06 PM
To: Decibel!
Cc: Tom Lane; Dann Corbit; Robert Haas; Bruce Momjian; Mark Wong;
Heikki Linnakangas; Josh Berkus; Greg Smith; pgsql-
[EMAIL PROTECTED]
Merlin Moncure [EMAIL PROTECTED] writes:
On Mon, Nov 24, 2008 at 10:25 AM, Marko Kreen [EMAIL PROTECTED] wrote:
IOW, DISCARD ALL should be functionally equivalent to backend exit.
Having done a lot of work with advisory locks, I support this change.
Advisory locks are essentially session
Dann Corbit [EMAIL PROTECTED] writes:
I also do not believe that there is any value that will be the right
answer. But a table of data might be useful both for people who want to
toy with altering the values and also for those who want to set the
defaults. I guess that at one time such a
On Tue, 2008-11-25 at 20:33 -0500, Tom Lane wrote:
Dann Corbit [EMAIL PROTECTED] writes:
I also do not believe that there is any value that will be the right
answer. But a table of data might be useful both for people who want to
toy with altering the values and also for those who want to
On Tue, Nov 25, 2008 at 8:38 PM, Joshua D. Drake [EMAIL PROTECTED] wrote:
I don't this is not empirical but really, 150 is very reasonable. Let's
just set it to that by default and be done with it. It won't hurt
anything and if they need more than that, they are already investigating
either
The ultimate conclusion was that a three-way split (identity, logical
position, physical position) could work because most of the code only
cares about column identity; the places where logical or physical
positions are important are pretty narrowly circumscribed, or could
be made so.
I
Robert Haas escribió:
After some thought, it seems pretty clear, at least to me, that the
third (hypothetical) command should not change the result of SELECT *
FROM tricky (the contrary conclusion gives rise to a lot of problems,
especially if there are other views depending on it). But what
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 25, 2008 5:33 PM
To: Dann Corbit
Cc: Gregory Stark; Decibel!; Robert Haas; Bruce Momjian; Mark Wong;
Heikki Linnakangas; Josh Berkus; Greg Smith; pgsql-
[EMAIL PROTECTED]
Subject: Re: [HACKERS]
Hiroshi Saito [EMAIL PROTECTED] wrote:
Um, It was not supported.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
Hmm... the implementation of wcsftime() in msvcrt seems to be
completely broken.
I ran the attached test (localetest.c) and got the following
On Tue, Nov 25, 2008 at 9:18 PM, Alvaro Herrera
[EMAIL PROTECTED] wrote:
After some thought, it seems pretty clear, at least to me, that the
third (hypothetical) command should not change the result of SELECT *
FROM tricky (the contrary conclusion gives rise to a lot of problems,
especially if
2008/11/26 David Rowley [EMAIL PROTECTED]:
Hitoshi Harada wrote:
2008/11/20 David Rowley [EMAIL PROTECTED]:
-- The following query gives incorrect results on the
-- maxhighbid column
SELECT auctionid,
category,
description,
highestbid,
reserve,
Bernd,
Do you intend to submit an updated version of this patch for this commitfest?
If not, I will move this to Returned with feedback.
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Zdenek -
I am a bit murky on where we stand with upgrade-in-place in terms of
reviewing. Initially, you had submitted four patches for this
commitfest:
1. htup and bufpage API clean up
2. HeapTuple version extension + code cleanup
3. In-place online upgrade
4. Extending pg_class info + more
井上です。
ITAGAKI Takahiro wrote:
Hiroshi Saito [EMAIL PROTECTED] wrote:
Um, It was not supported.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt
Hmm... the implementation of wcsftime() in msvcrt seems to be
completely broken.
I ran the attached test
Hi.
I think that MinGW does not have a direct relation.
#define_UNICODE is required for wcsftime.
Probably, ITAGAKI-san has only forgotten it.:-)
P.S)
日本語になっていましたです:-)
Regards,
Hiroshi Saito
- Original Message -
From: Hiroshi Inoue [EMAIL PROTECTED]
井上です。
ITAGAKI Takahiro
2008/11/25 Hitoshi Harada [EMAIL PROTECTED]:
2008/11/25 Heikki Linnakangas [EMAIL PROTECTED]:
Here's an updated patch, where the rows are fetched on-demand.
Good! And I like the fetching args by number better. Let me take more
time to look in detail...
I read more, and your spooling approach
On Tue, Nov 11, 2008 at 02:59:01PM +0100, Magnus Hagander wrote:
Gianni Ciolli wrote:
WARNING: detected write past chunk end in Postmaster 0x9b13650
Yes, that's a stupid bug:
(...)
Attached is an updated version of the patch that fixes this.
Hi Magnus,
please find below the review
88 matches
Mail list logo
