Hi,
I found two typos in xlog.c. Could you apply the attached patch?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi,
Walsender doesn't need the periodic wakeups anymore, thanks to
the latch feature. So wal_sender_delay is basically useless now.
How about dropping wal_sender_delay or increasing the default
value?
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
Tom Lane t...@sss.pgh.pa.us writes:
Why is there a variadic replace() in this patch at all? It seems just
about entirely unrelated to the stated purpose of the patch, as well
as being of dubious usefulness.
It used not to being exposed at the SQL level, but just an internal loop
in
2010/11/25 Shigeru HANADA han...@metrosystems.co.jp:
Hi, hackers,
Attached is a patch that adds file_fdw, FDW which reads records from
files on the server side, as a contrib module. This patch is based on
SQL/MED core functionality patch.
[SQL/MED - core functionality]
On 06.12.2010 09:01, Fujii Masao wrote:
I found two typos in xlog.c. Could you apply the attached patch?
Applied.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut pete...@gmx.net wrote:
Here is an updated patch to address the issues discussed during this
commitfest.
Here are comments and questions after I tested the latest patch:
Issues
* initdb itself seems to be succeeded, but it says could not
On sön, 2010-09-19 at 14:28 -0400, Tom Lane wrote:
Or maybe we could implement that function, call it like this
CAST((pg_sequence_parameters(c.oid)).max_value AS
cardinal_number) AS maximum_value,
and plan on optimizing the view when we get LATERAL.
Here is an implementation of
On Mon, Dec 6, 2010 at 2:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.12.2010 02:55, Robert Haas wrote:
On Sun, Dec 5, 2010 at 1:28 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I'm wondering if we should reconsider the pass-it-through-the-client
approach, because if
On Mon, Dec 6, 2010 at 5:48 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
I think it is better to add encoding option to FileFdwOption. In the
patch the encoding of file is assumed as client_encoding, but we may
want to SELECT from different-encoded csv in a query.
Apart from the issue with
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer m...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves similar to PQexec, but it allows for printf
On 06.12.2010 14:57, Robert Haas wrote:
On Mon, Dec 6, 2010 at 2:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The client doesn't need to know anything about the snapshot blob that the
server gives it. It just needs to pass it back to the server through the
other
On Sat, 4 Dec 2010, Greg Stark wrote:
On Sat, Dec 4, 2010 at 6:07 PM, Oleg Bartunov o...@sai.msu.su wrote:
We'll sync contrib/btree_gist with current API. Also, we're thinking
about distance for ltree, boxes, circles. I'm not sure about polygons,
though.
So, we'll have rather complete set of
On Mon, Dec 6, 2010 at 9:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.12.2010 14:57, Robert Haas wrote:
On Mon, Dec 6, 2010 at 2:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
The client doesn't need to know anything about the snapshot
On 06.12.2010 08:51, Fujii Masao wrote:
On Mon, Dec 6, 2010 at 3:42 PM, Fujii Masaomasao.fu...@gmail.com wrote:
On Fri, Oct 15, 2010 at 9:41 PM, Fujii Masaomasao.fu...@gmail.com wrote:
The timeout doesn't oppose to 'wait-forever'. Even if you choose 'wait
-forever' (i.e., you set
Am 06.12.10 15:37, schrieb Merlin Moncure:
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer m...@msys.ch wrote:
I am suggesting adding a function to libpq:
PGresult *PQvexec(PGconn *conn, const char *fmt, ...);
It behaves
On 06.12.2010 15:53, Robert Haas wrote:
I guess. It still seems far too much like exposing the server's guts
for my taste. It might not be as bad as the expression tree stuff,
but there's nothing particularly good about it either.
Note that we already have txid_current_snapshot() function,
Fujii Masao masao.fu...@gmail.com writes:
Walsender doesn't need the periodic wakeups anymore, thanks to
the latch feature. So wal_sender_delay is basically useless now.
How about dropping wal_sender_delay or increasing the default
value?
If we don't need it, we should remove it.
On Mon, Dec 6, 2010 at 9:55 AM, Marc Balmer m...@msys.ch wrote:
Am 06.12.10 15:37, schrieb Merlin Moncure:
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer m...@msys.ch wrote:
I am suggesting adding a function to libpq:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Why is there a variadic replace() in this patch at all? It seems just
about entirely unrelated to the stated purpose of the patch, as well
as being of dubious usefulness.
It used not to being exposed at the
On Mon, Dec 6, 2010 at 9:54 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
This occurred to me that the timeout would be required even for
asynchronous streaming replication. So, how about implementing the
replication timeout feature before synchronous replication itself?
On Mon, Dec 6, 2010 at 9:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.12.2010 15:53, Robert Haas wrote:
I guess. It still seems far too much like exposing the server's guts
for my taste. It might not be as bad as the expression tree stuff,
but there's nothing
Excerpts from Andrew Dunstan's message of dom dic 05 14:41:20 -0300 2010:
What I would like to see is people publishing the location of
development repos so that they can be pulled from or merged, especially
for any large patch.
Yes, this is pretty useful. Dimitri published his repos for
On Mon, Dec 06, 2010 at 10:14:55AM -0500, Merlin Moncure wrote:
On Mon, Dec 6, 2010 at 9:55 AM, Marc Balmer m...@msys.ch wrote:
Am 06.12.10 15:37, schrieb Merlin Moncure:
On Sun, Dec 5, 2010 at 5:10 AM, Magnus Hagander mag...@hagander.net
wrote:
On Sun, Dec 5, 2010 at 10:22, Marc Balmer
That would be a *HUGE* piece of software compared the relatively small
thing I am suggesting...
Sometimes complex and large solutions are required for the simplest of
ideas. I believe this is one of those cases. You can't solve the
printf style PQexec properly by merely implementing a
On 12/06/2010 10:22 AM, Robert Haas wrote:
On Mon, Dec 6, 2010 at 9:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.12.2010 15:53, Robert Haas wrote:
I guess. It still seems far too much like exposing the server's guts
for my taste. It might not be as bad as the
On Mon, Dec 6, 2010 at 10:35 AM, Andrew Dunstan and...@dunslane.net wrote:
On 12/06/2010 10:22 AM, Robert Haas wrote:
On Mon, Dec 6, 2010 at 9:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 06.12.2010 15:53, Robert Haas wrote:
I guess. It still seems far too much
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 6, 2010 at 9:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Well, then you need some sort of cross-backend communication, which is
always a bit clumsy.
A temp file seems quite sufficient, and not at all difficult.
On Mon, Dec 6, 2010 at 10:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 6, 2010 at 9:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Well, then you need some sort of cross-backend communication, which is
always a bit
On 12/06/2010 10:40 AM, Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
On Mon, Dec 6, 2010 at 9:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Well, then you need some sort of cross-backend communication, which is
always a bit clumsy.
A temp file seems
IMO, it would be better to implement some utility functions to
make it easy to construct arrays dynamically for PQexecParams
and PQexecPrepared. This seems to me more universal solution
and it is useful for both -- high level libpq-libraries authors and for
those who like to use libpq directly.
On 12/6/2010 11:40 AM, Dmitriy Igrishin wrote:
IMO, it would be better to implement some utility functions to
make it easy to construct arrays dynamically for PQexecParams
and PQexecPrepared. This seems to me more universal solution
and it is useful for both -- high level libpq-libraries authors
2010/12/6 Andrew Chernow a...@esilo.com
On 12/6/2010 11:40 AM, Dmitriy Igrishin wrote:
IMO, it would be better to implement some utility functions to
make it easy to construct arrays dynamically for PQexecParams
and PQexecPrepared. This seems to me more universal solution
and it is useful
Andrew Dunstan and...@dunslane.net writes:
Attached is a patch that allows CopyReadAttibutesText() and
CopyReadAttributesCSV() to read arbitrary numbers of attributes.
Underflowing attributes are recorded as null, and space is made for
overflowing attributes on a line.
Why are you still
I wrote:
Tom Lane wrote:
I assume this would have to be a hard definition of READ ONLY,
not the rather squishy definition we use now?
I'm excluding temporary tables from SSI on the grounds that they
are only read and written by a single transaction and therefore
can't be a source of
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 5, 2010 at 12:41 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, ISTM that amounts to not having official topic branches :-) I agree
that this is supposed to be one of git's strengths (or more exactly a
strength of distributed SCM's
Andrew Dunstan and...@dunslane.net writes:
Yeah. I'm still not convinced that using shared memory is a bad way to
pass these around. Surely we're not talking about large numbers of them.
What am I missing here?
They're not of a very predictable size.
Robert's idea of publish() returning a
Andrew Dunstan and...@dunslane.net writes:
Why not just say give me the snapshot currently held by process ?
There's not a unique snapshot held by a particular process. Also, we
don't want to expend the overhead to fully publish every snapshot.
I think it's really necessary that the sending
Robert Haas robertmh...@gmail.com writes:
One possible way to do make an improvement in this area would be to
move the responsibility for accepting connections out of the
postmaster. Instead, you'd have a group of children that would all
call accept() on the socket, and the OS would
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 5, 2010 at 6:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Why is there a variadic replace() in this patch at all? It seems just
about entirely unrelated to the stated purpose of the patch, as well
as being of dubious usefulness. When would
On 12/06/2010 09:38 AM, Tom Lane wrote:
Another issue that would require some thought is what algorithm the
postmaster uses for deciding to spawn new children. But that doesn't
sound like a potential showstopper.
We'd probably want a couple of different ones, optimized for different
On 12/06/2010 12:28 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Yeah. I'm still not convinced that using shared memory is a bad way to
pass these around. Surely we're not talking about large numbers of them.
What am I missing here?
They're not of a very predictable size.
On Mon, Dec 6, 2010 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One possible way to do make an improvement in this area would be to
move the responsibility for accepting connections out of the
postmaster. Instead, you'd have a group of children
At some point Hackers should look at pg vs MySQL multi tenantry but it
is way tangential today.
My understanding is that our schemas work like MySQL databases; and
our databases are an even higher level of isolation. No?
That's correct. Drizzle is looking at implementing a feature like
On Dec 6, 2010, at 4:06 AM, Itagaki Takahiro wrote:
* contrib/citext raises an encoding error when COLLATE is specified
even if it is the collation as same as the database default.
We might need some special treatment for C locale.
I've been wondering if this patch will support
On Dec 6, 2010, at 7:19 AM, Tom Lane wrote:
On the whole I'd prefer not to have any substitution functionality
hard-wired into pg_execute_file either, though I can see the argument
that it's necessary for practical use. Basically I'm concerned that
replace-equivalent behavior is not going to
On Mon, Dec 6, 2010 at 12:57 PM, Josh Berkus j...@agliodbs.com wrote:
At some point Hackers should look at pg vs MySQL multi tenantry but it
is way tangential today.
My understanding is that our schemas work like MySQL databases; and
our databases are an even higher level of isolation. No?
On Mon, Dec 6, 2010 at 12:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Dec 5, 2010 at 6:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Why is there a variadic replace() in this patch at all? It seems just
about entirely unrelated to the stated purpose
On 12/06/2010 12:11 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
Attached is a patch that allows CopyReadAttibutesText() and
CopyReadAttributesCSV() to read arbitrary numbers of attributes.
Underflowing attributes are recorded as null, and space is made for
overflowing
2010/12/6 David E. Wheeler da...@kineticode.com:
On Dec 6, 2010, at 4:06 AM, Itagaki Takahiro wrote:
* contrib/citext raises an encoding error when COLLATE is specified
even if it is the collation as same as the database default.
We might need some special treatment for C locale.
I've been
Tom Lane t...@sss.pgh.pa.us wrote:
I'm still not convinced that using shared memory is a bad way to
pass these around. Surely we're not talking about large numbers
of them. What am I missing here?
They're not of a very predictable size.
Surely you can predict that any snapshot is no
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I reviewed the documentation and played around with this a bit and
can't find any areas where the current PostgreSQL implementation of
READ ONLY is incompatible with what is needed for the SSI
optimizations where it is used. There are a large
Andrew Dunstan and...@dunslane.net writes:
On 12/06/2010 12:11 PM, Tom Lane wrote:
Also, why did you change the setup code to
not compute nfields in binary mode? That seems at best an unnecessary
change, and at worst a breakage of the binary path --- did you test it?
AFAICT it's not used in
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
I'm still not convinced that using shared memory is a bad way to
pass these around. Surely we're not talking about large numbers
of them. What am I missing here?
They're not of a very predictable size.
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Surely you can predict that any snapshot is no larger than a fairly
small fixed portion plus sizeof(TransactionId) * MaxBackends?
No. See subtransactions.
Subtransactions are included in snapshots?
On 12/06/2010 01:23 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 12/06/2010 12:11 PM, Tom Lane wrote:
Also, why did you change the setup code to
not compute nfields in binary mode? That seems at best an unnecessary
change, and at worst a breakage of the binary path ---
David E. Wheeler da...@kineticode.com writes:
On Dec 6, 2010, at 7:19 AM, Tom Lane wrote:
On the whole I'd prefer not to have any substitution functionality
hard-wired into pg_execute_file either, though I can see the argument
that it's necessary for practical use. Basically I'm concerned
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
No. See subtransactions.
Subtransactions are included in snapshots?
Sure, see GetSnapshotData(). You could avoid it by setting
suboverflowed, but that comes at a nontrivial performance cost.
On Dec 6, 2010, at 10:43 AM, Tom Lane wrote:
That's an interesting idea, but I'm not sure it's wise to design around
the assumption that we won't need substitutions ever. What I was
thinking was that we should try to limit knowledge of the substitution
behavior to the extension definition
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
No. See subtransactions.
Subtransactions are included in snapshots?
Sure, see GetSnapshotData(). You could avoid it by setting
suboverflowed, but that comes at a
David E. Wheeler da...@kineticode.com writes:
On Dec 6, 2010, at 10:43 AM, Tom Lane wrote:
(On the other hand, if we *could* avoid using any explicit
substitutions, it would certainly ease testing of extension files no?
They'd be sourceable into psql then.)
Yes. And extension authors would
On Dec 6, 2010, at 11:12 AM, Tom Lane wrote:
Well, I don't put any stock in the idea that it's important for existing
module .sql files to be usable as-is as extension definition files. If
it happens to fall out that way, fine, but we shouldn't give up anything
else to get that.
I agree,
On mån, 2010-12-06 at 21:06 +0900, Itagaki Takahiro wrote:
On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut pete...@gmx.net wrote:
Here is an updated patch to address the issues discussed during this
commitfest.
Here are comments and questions after I tested the latest patch:
Issues
On mån, 2010-12-06 at 10:01 -0800, David E. Wheeler wrote:
I've been wondering if this patch will support case-insensitve
collations. If so, then citext should probably be revised to use one.
This has been touch upon several times during the discussions on past
patches.
Essentially, the
David E. Wheeler da...@kineticode.com writes:
The other question I have, though, is how important is it to have extensions
live in a particular schema since there seems to be no advantage to doing so.
With the current patch, I can put extension foo in schema bar, but I
can't put any other
On Dec 6, 2010, at 11:29 AM, Peter Eisentraut wrote:
This has been touch upon several times during the discussions on past
patches.
Essentially, the current patch only arranges that you can specify a sort
order for data. The system always breaks ties using a binary
comparison. This could
2010/11/25 KaiGai Kohei kai...@ak.jp.nec.com:
The attached patch is a revised one.
It provides two hooks; the one informs core PG whether the supplied
function needs to be hooked, or not. the other is an actual hook on
prepare, start, end and abort of function invocations.
typedef bool
Please explain more precisely what is wrong with SET SESSION
AUTHORIZATION / SET ROLE.
1) Session GUCS do not change with a SET ROLE (this is a TODO I haven't
had any time to work on)
2) Users can always issue their own SET ROLE and then hack into other
users' data.
--
Please
It would be very important to us that the Brazilian LIKE collate worked
with, and possible case-insensitive and accent-insensitive
Tank's
Alexandre Riveira
Brazil
Peter Eisentraut escreveu:
On mån, 2010-12-06 at 10:01 -0800, David E. Wheeler wrote:
I've been wondering if this
On Dec 6, 2010, at 11:36 AM, Tom Lane wrote:
There's a difference between whether an extension as such is considered
to belong to a schema and whether its contained objects do. We can't
really avoid the fact that functions, operators, etc must be assigned to
some particular schema.
Right,
On Dec5, 2010, at 16:11 , Kevin Grittner wrote:
The simple way to implement SERIALIZABLE READ ONLY DEFERRABLE under
SSI would be to have each non-read-only serializable transaction
acquire a heavyweight lock which can coexist with other locks at the
same level (SHARE looks good) on some common
On Sun, Dec 5, 2010 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
IIRC, in old discussions of this problem we first considered allowing
clients to pull down an explicit representation of their snapshot (which
actually is an existing feature now, txid_current_snapshot()) and then
upload that
Greg Smith g...@2ndquadrant.com writes:
Regardless, I'm now leaning heavily toward the idea of avoiding
open_datasync by default given this bug, and backpatching that change to
at least 8.4. I'll do some more database-level performance tests here
just as a final sanity check on that. My
On 06.12.2010 21:48, marcin mank wrote:
On Sun, Dec 5, 2010 at 7:28 PM, Tom Lanet...@sss.pgh.pa.us wrote:
IIRC, in old discussions of this problem we first considered allowing
clients to pull down an explicit representation of their snapshot (which
actually is an existing feature now,
marcin mank marcin.m...@gmail.com writes:
On Sun, Dec 5, 2010 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
IIRC, in old discussions of this problem we first considered allowing
clients to pull down an explicit representation of their snapshot (which
actually is an existing feature now,
Florian Pflug f...@phlo.org wrote:
On Dec5, 2010, at 16:11 , Kevin Grittner wrote:
The simple way to implement SERIALIZABLE READ ONLY DEFERRABLE
under SSI would be to have each non-read-only serializable
transaction acquire a heavyweight lock which can coexist with
other locks at the same
On 06.12.2010 22:53, Kevin Grittner wrote:
What would be the correct way for a process to put itself to sleep,
and for another process to later wake it up?
See ProcWaitSignal/ProcSendSignal. Or the new 'latch' code.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 06.12.2010 22:53, Kevin Grittner wrote:
What would be the correct way for a process to put itself to
sleep, and for another process to later wake it up?
See ProcWaitSignal/ProcSendSignal. Or the new 'latch' code.
Is there a
However, if you were doing something like parallel pg_dump you could
just run the parent and child instances all against the slave, so the
pg_dump scenario doesn't seem to offer much of a supporting use-case for
worrying about this. When would you really need to be able to do it?
If you had
Tom Lane wrote:
The various testing that's been reported so far is all for
Linux and thus doesn't directly address the question of whether other
kernels will have similar performance properties.
Survey of some popular platforms:
Linux: don't want O_DIRECT by default for reliability reasons,
Hi, folks,
in src/template/darwin:
# Select appropriate semaphore support. Darwin 6.0 (Mac OS X 10.2) and up
# support System V semaphores; before that we have to use POSIX semaphores,
# which are less good for our purposes because they eat a file descriptor
# per backend per max_connection
Josh Berkus j...@agliodbs.com writes:
However, if you were doing something like parallel pg_dump you could
just run the parent and child instances all against the slave, so the
pg_dump scenario doesn't seem to offer much of a supporting use-case for
worrying about this. When would you really
On 12/5/10 2:12 PM, Greg Smith wrote:
Josh Berkus wrote:
I modified test_fsync in two ways to run this; first, to make it support
O_DIRECT, and second to make it run in the *current* directory.
Patch please? I agree with the latter change; what test_fsync does is
surprising.
Attached.
On 10-12-06 06:56 PM, Greg Smith wrote:
Tom Lane wrote:
The various testing that's been reported so far is all for
Linux and thus doesn't directly address the question of whether other
kernels will have similar performance properties.
Survey of some popular platforms:
snip
So my guess is
Greg Smith g...@2ndquadrant.com writes:
So my guess is that some small percentage of Windows users might notice
a change here, and some testing on FreeBSD would be useful too. That's
about it for platforms that I think anybody needs to worry about.
To my mind, O_DIRECT is not really the key
Josh Berkus j...@agliodbs.com writes:
Making it support O_DIRECT would be possible but more complex; I don't
see the point unless we think we're going to have open_sync_with_odirect
as a seperate option.
Whether it's complex or not isn't really the issue. The issue is that
what test_fsync is
On 12/06/2010 08:38 PM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
Making it support O_DIRECT would be possible but more complex; I don't
see the point unless we think we're going to have open_sync_with_odirect
as a seperate option.
Whether it's complex or not isn't really the
Steve,
If you tell me which options to pgbench and which .conf file settings
you'd like to see I can probably arrange to run some tests on AIX.
Compile and run test_fsync in PGSRC/src/tools/fsync.
--
-- Josh Berkus
On Mon, Dec 6, 2010 at 11:54 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, that's actually a quite different timeout than what's required for
synchronous replication. In synchronous replication, you need to get an
acknowledgment within a timeout. This patch only puts a
Mac OS X: Like Solaris, there's a similar mechanism but it's not
O_DIRECT; see
http://stackoverflow.com/questions/2299402/how-does-one-do-raw-io-on-mac-os-x-ie-equivalent-to-linuxs-o-direct-flag
for notes about the F_NOCACHE feature used. Same basic situation as
Solaris; there's an API,
Whether it's complex or not isn't really the issue. The issue is that
what test_fsync is testing had better match what the backend does, or
people will be making choices based on not-comparable test results.
I think we should have test_fsync just automatically fold in O_DIRECT
the same way
On Mon, Dec 6, 2010 at 9:04 PM, Josh Berkus j...@agliodbs.com wrote:
Mac OS X: Like Solaris, there's a similar mechanism but it's not
O_DIRECT; see
http://stackoverflow.com/questions/2299402/how-does-one-do-raw-io-on-mac-os-x-ie-equivalent-to-linuxs-o-direct-flag
for notes about the
On Mon, Dec 6, 2010 at 2:47 PM, Josh Berkus j...@agliodbs.com wrote:
Please explain more precisely what is wrong with SET SESSION
AUTHORIZATION / SET ROLE.
1) Session GUCS do not change with a SET ROLE (this is a TODO I haven't
had any time to work on)
2) Users can always issue their own
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 6, 2010 at 9:04 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, on OSX 10.5.8, o_dsync and fdatasync aren't even available.
From my run, it looks like even so regular fsync might be better than
open_sync.
But I think you need to use
On 12/6/10 6:10 PM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 6, 2010 at 9:04 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, on OSX 10.5.8, o_dsync and fdatasync aren't even available.
From my run, it looks like even so regular fsync might be better than
Josh Berkus j...@agliodbs.com writes:
OK, patch coming then. Right now test_fsync aborts when O_DIRECT fails.
What should I have it do instead?
Report that it fails, and keep testing the other methods.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Excerpts from Greg Smith's message of dom dic 05 20:02:48 -0300 2010:
When ends up happening if you push toward fully sync I/O is the design
you see in some other databases, where you need multiple writer
processes. Then requests for new pages can continue to allocate as
needed, while
All,
Geirth's results from his FreeBSD 7.1 server using 8.4's test_fsync:
Simple write timing:
write0.007081
Compare fsync times on write() and non-write() descriptor:
If the times are similar, fsync() can sync data written
on a different descriptor.
write,
Excerpts from Robert Haas's message of lun dic 06 23:09:56 -0300 2010:
On Mon, Dec 6, 2010 at 2:47 PM, Josh Berkus j...@agliodbs.com wrote:
Please explain more precisely what is wrong with SET SESSION
AUTHORIZATION / SET ROLE.
1) Session GUCS do not change with a SET ROLE (this is a
On Tue, Dec 7, 2010 at 12:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Walsender doesn't need the periodic wakeups anymore, thanks to
the latch feature. So wal_sender_delay is basically useless now.
How about dropping wal_sender_delay or increasing the
On Sun, Dec 5, 2010 at 01:04, Peter Eisentraut pete...@gmx.net wrote:
Here is an updated patch to address the issues discussed during this
commitfest.
I found another issue in the patch; ILIKE in WHERE clause doesn't work.
It was surprising because LIKE in WHERE clause and ILIKE in SELECT list
1 - 100 of 114 matches
Mail list logo
