Yusuf Goolamabbas wrote:
I sent this to Bruce but forgot to cc pgsql-hackers, The patches are
likely to go into 2.6.6. People interested in extremely safe fsync
writes should also follow the IDE barrier thread and the true fsync() in
Linux on IDE thread
Actually the most interesting part of
Yusuf Goolamabbas [EMAIL PROTECTED] writes:
Bruce, haven't followed the thread completely. Accessing the web archive
is slow from Hong Kong but I just wanted to point you to this lkml post
which shows why O_SYNC is much faster than fsync (at least on ext3)
Marc G. Fournier [EMAIL PROTECTED] writes:
Pointers to docs that I'm not finding most acceptable ...
There aren't any, because at the time the 7.4 docs were being prepared,
we didn't have enough field experience to know whether its version of
index compaction would eliminate the practical need
Kevin == Kevin Brown [EMAIL PROTECTED] writes:
The bigger problem though with this is that it makes the
problem of list overflow much worse. The hard part about
shared memory management is not so much that the available
space is small, as that the available space is fixed
Would it be possible to have the command completion tag for EXECUTE return
the affected row count? The JDBC API says you should be able to get the
affected row count for any statement and I'm working on integrating a
patch that transforms regular statements to server side prepared
statements,
Marc G. Fournier [EMAIL PROTECTED] writes:
Pointers to docs that I'm not finding most acceptable ...
There aren't any, because at the time the 7.4 docs were being prepared,
we didn't have enough field experience to know whether its version of
index compaction would eliminate the practical
I've been fooling with adding a report of the executing query to the
CONTEXT stack when an error happens within a query submitted by a
plpgsql function. Since plpgsql submits all its queries through SPI,
the most convenient place to do this is in spi.c, and so the behavior
will also apply to
Fabien COELHO [EMAIL PROTECTED] writes:
I agree with you that both reports should not look the same.
The good news is that they already do not look the same, thanks
to the CONTEXT information.
Right, but you quite properly didn't like my quick-hack to psql that
assumes that the presence of
Tom Lane wrote:
Although this is quite reasonable for queries submitted by
user-written C functions, I'm worried that plpgsql programmers will
be confused because they've never heard of SPI. I toyed with saying
SQL query instead, but that seems pretty nearly content-free ... it
doesn't
On 21-Mar-04, at 11:39 AM, Kris Jurka wrote:
Would it be possible to have the command completion tag for EXECUTE
return
the affected row count?
Yes, this has been suggested before -- for example:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg26787.html
I agree it would be a good idea,
Bruce Momjian [EMAIL PROTECTED] wrote:
[snip]
OK, patch attached and applied. It adds configure tests for the 5-arg
version of getpwuid_r() and properly falls back to the Posix draft
version you have on Solaris. Seems Solaris 9 also still has the draft
version.
[snip]
Well, yes and no.
Lately I have been thinking about the next steps for the pg_autovacuum
daemon. I have written up a document that describes what I'm planning
to do next. Please read the attached and response as I would really
like some feedback.
Thanks,
Matthew O'Connor
pg_autovacuum_v2_writeup.rtf
Neil Conway [EMAIL PROTECTED] writes:
On 21-Mar-04, at 11:39 AM, Kris Jurka wrote:
Would it be possible to have the command completion tag for EXECUTE
return
the affected row count?
Yes, this has been suggested before -- for example:
http://www.mail-archive.com/[EMAIL
Matthew T. O'Connor [EMAIL PROTECTED] writes:
Lately I have been thinking about the next steps for the pg_autovacuum
daemon. I have written up a document that describes what I'm planning
to do next. Please read the attached and response as I would really
like some feedback.
[ rtf document
, 22.03.2004, 00:12, Tom Lane :
Please repost in some less proprietary format. Plain text is generally
considered the thing to use on this list.
--
Markus Bertheau [EMAIL PROTECTED]
pg_autovacuum Version 2
Design Document:
Exec Summary:
pg_autovacuum was initially released as a contrib
Matthew T. O'Connor wrote:
Lately I have been thinking about the next steps for the
pg_autovacuum daemon. I have written up a document that describes
what I'm planning to do next. Please read the attached and response
as I would really like some feedback.
I think these configuration issues
I think these configuration issues will become a lot easier if you make
the autovacuum daemon a subprocess of the postmaster (like, say, the
checkpoint process). Then you have access to a host of methods for
storing state, handling configuration, etc.
Yeah - why delay making it a backend
On Sun, 21 Mar 2004, Tom Lane wrote:
On 21-Mar-04, at 11:39 AM, Kris Jurka wrote:
Would it be possible to have the command completion tag for EXECUTE
return
the affected row count?
However, does this really solve Kris' problem? JDBC generally likes to
think that it works with old
On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
I think these configuration issues will become a lot easier if you make
the autovacuum daemon a subprocess of the postmaster (like, say, the
checkpoint process). Then you have access to a host of methods for
storing state,
Neil Conway wrote:
On 21-Mar-04, at 11:39 AM, Kris Jurka wrote:
Would it be possible to have the command completion tag for EXECUTE
return
the affected row count?
Yes, this has been suggested before -- for example:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg26787.html
I
On Sun, 2004-03-21 at 18:12, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
[ rtf document ]
Please repost in some less proprietary format. Plain text is generally
considered the thing to use on this list.
I don't think RTF is proprietary but I should have just posted
On Sun, 21 Mar 2004, Matthew T. O'Connor wrote:
On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
I think these configuration issues will become a lot easier if you make
the autovacuum daemon a subprocess of the postmaster (like, say, the
checkpoint process). Then you have
B) Perhaps people like the idea of it being a client app (I don't think
so.)
I'd like to see it as part of the backend.
C) Most importantly, I'm not backend hacker. If someone wants to do the
initial work of getting it running as a backend process, I can take it
from there. A
Jim Seymour wrote:
Bruce Momjian [EMAIL PROTECTED] wrote:
[snip]
OK, patch attached and applied. It adds configure tests for the 5-arg
version of getpwuid_r() and properly falls back to the Posix draft
version you have on Solaris. Seems Solaris 9 also still has the draft
version.
Larry Rosenman wrote:
The a.out (not any library) should be linked with -Kpthread (not
-lpthread).
This will force libthread to be linked in the right order relative to
libc, libC, networking libraries, etc.
In other words, the entire application either is or is not linked with
threads;
On Fri, Mar 19, 2004 at 09:54:37AM -0500, Tom Lane wrote:
Karel Zak [EMAIL PROTECTED] writes:
The problem with CSV is that it will correctly work with new protocol
only. Because old versions of clients are newline sensitive.
Why? The client-side code doesn't have any real say over
26 matches
Mail list logo
