This is what Postgres-XC is doing between a coordinator and a
datanode.Coordinator may correspond to poolers/loadbalancers.
Does anyone think it makes sense to extract XC implementation of
snapshot shipping to PostgreSQL itself?
Cheers;
--
Koichi Suzuki
2010/12/7 Stefan
On 02.12.2010 12:31, Heikki Linnakangas wrote:
On 02.12.2010 13:25, Simon Riggs wrote:
On Thu, 2010-12-02 at 12:41 +0200, Heikki Linnakangas wrote:
On 02.12.2010 11:02, Simon Riggs wrote:
The cause of the issue is that replay starts at one LSN and there is a
delay until the RunningXacts WAL
Thanks for your reviewing.
The attached patch is a revised version.
I don't have any objections to your comments.
(2010/12/07 4:38), Robert Haas wrote:
2010/11/25 KaiGai Koheikai...@ak.jp.nec.com:
The attached patch is a revised one.
It provides two hooks; the one informs core PG whether the
Tom Lane t...@sss.pgh.pa.us writes:
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. It seems not
Tom Lane t...@sss.pgh.pa.us writes:
Topic branches defined that way seem like a pretty bad idea from here.
They would save no effort at all for committers, because if you're not
allowed to object to something after it's gone into a topic branch, then
it's just like master in terms of having to
On 12/07/2010 09:23 AM, Koichi Suzuki wrote:
This is what Postgres-XC is doing between a coordinator and a
datanode.Coordinator may correspond to poolers/loadbalancers.
Does anyone think it makes sense to extract XC implementation of
snapshot shipping to PostgreSQL itself?
well if there
On Dec6, 2010, at 22:53 , Kevin Grittner wrote:
The alternative seems to be to drop the guarantee that a
SERIALIZABLE READ ONLY DEFERRABLE won't be starved forever by a
stream of overlapping non-READ ONLY transactions. Then a flag in
the proc array that marks non-READ ONLY transactions should
Hey hackers@,
libpq execution function works with OIDs. In some cases it is
highly recommended specify OIDs of parameters according to
libpq documentation.
While developing a database application with libpq and if
application works with custom data types IMO reasonable to
provide developer
aaliya zarrin escreveu:
I want to signal the postmaster (User defined signal) once I created the
trigger file (for switch over).
Send a SIGHUP to postmaster. Have in mind that it doesn't work on all
supported platforms.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with our $_TD; local $_TD = shift;
Pre-extend stack for trigger arguments for slight performance gain.
Passes installcheck.
Tim.
diff --git a/src/pl/plperl/plperl.c
On 12/07/2010 09:24 AM, Tim Bunce wrote:
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with our $_TD; local $_TD = shift;
Pre-extend stack for trigger arguments for slight performance gain.
Passes installcheck.
Please
On Tue, Dec 7, 2010 at 9:10 AM, Dmitriy Igrishin dmit...@gmail.com wrote:
Hey hackers@,
libpq execution function works with OIDs. In some cases it is
highly recommended specify OIDs of parameters according to
libpq documentation.
While developing a database application with libpq and if
Alvaro Herrera wrote:
Why would multiple bgwriter processes worry you?
Of course, it wouldn't work to have multiple processes trying to execute
a checkpoint simultaneously, but what if we separated the tasks so that
one process is in charge of checkpoints, and another one is in charge of
the
On 12/07/2010 10:02 AM, Merlin Moncure wrote:
On Tue, Dec 7, 2010 at 9:10 AM, Dmitriy Igrishindmit...@gmail.com wrote:
Hey hackers@,
libpq execution function works with OIDs. In some cases it is
highly recommended specify OIDs of parameters according to
libpq documentation.
While developing
On Mon, Dec 6, 2010 at 2:36 PM, Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org wrote:
reason for a SERIALIZABLE READ ONLY transaction's snapshot to be
inconsistent that it sees some transaction A as committed and B as
uncommitted when on the other hand B must happen before A in any
serial schedule.
Precisely right, and very well stated.
On 12/07/2010 11:13 AM, Robert Haas wrote:
On Mon, Dec 6, 2010 at 2:36 PM, Tom Lanet...@sss.pgh.pa.us 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,
After reviewing the two ongoing threads about fixing the wal_sync_method
fiasco, I think there is general agreement on these two points:
1. open_datasync shouldn't be the default choice
2. O_DIRECT shouldn't be forcibly bundled in with O_DSYNC/O_SYNC
What I suggest we do about the latter is to
Andrew Dunstan and...@dunslane.net writes:
On 12/07/2010 11:13 AM, Robert Haas wrote:
Why not? This feature seems to be pretty heavily designed around the
assumption that everything's going to live in one schema, so is there
any harm in making that explicit?
In previous discussions IIRC the
On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan and...@dunslane.net wrote:
On 12/07/2010 10:02 AM, Merlin Moncure wrote:
On Tue, Dec 7, 2010 at 9:10 AM, Dmitriy Igrishindmit...@gmail.com
wrote:
Hey hackers@,
libpq execution function works with OIDs. In some cases it is
highly recommended
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan and...@dunslane.net wrote:
This doesn't strike me as very good advice. Those things are not exposed
generally for good reason. The right way to do this surely is to have the
app look up and cache the OIDs
On Sun, Dec 5, 2010 at 1:23 PM, Greg Smith g...@2ndquadrant.com wrote:
Jeff Janes wrote:
I've attached a tiny patch to apply over yours, to deal with this and
with the case where no files are synced.
Thanks for that. That obvious error eluded me because in most of the patch
update testing
On Tuesday 07 December 2010 17:24:14 Tom Lane wrote:
After reviewing the two ongoing threads about fixing the wal_sync_method
fiasco, I think there is general agreement on these two points:
1. open_datasync shouldn't be the default choice
2. O_DIRECT shouldn't be forcibly bundled in with
On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan and...@dunslane.net wrote:
This doesn't strike me as very good advice. Those things are not exposed
generally for good reason. The right
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Say what? He didn't say that, he said don't assume that user-defined
types have hard-wired OIDs.
Well, you're right, strictly speaking. Of course, the OP is not
assuming it, he is
On Tue, Dec 7, 2010 at 11:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Anyway the main problem at the moment is that the proposed design is
meant to allow relocatable extensions, but it doesn't behave
pleasantly in the case where somebody tries to relocate a
non-relocatable extension.
It also
On Mon, December 6, 2010 14:17, Boxuan Zhai wrote:
I send the original file directly this time.
I get some whitespace-warnings, followed by error:
$ git apply
/home/rijkers/download/pgpatches/0091/merge/20101206/merge_204_2010DEC06.patch
On Tue, Nov 30, 2010 at 10:36 PM, Andy Colson a...@squeakycode.net wrote:
[ review ]
Currently, if you create an unlogged table, restart PG, and vacuum the
table, you'll get this:
rhaas=# vacuum unlogged;
WARNING: relation unlogged page 0 is uninitialized --- fixing
VACUUM
The reason this
2010/12/7 Tom Lane t...@sss.pgh.pa.us:
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Say what? He didn't say that, he said don't assume that user-defined
types have hard-wired OIDs.
Well, you're right, strictly speaking. Of
On Tue, Dec 7, 2010 at 12:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Dec 7, 2010 at 11:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Say what? He didn't say that, he said don't assume that user-defined
types have hard-wired OIDs.
Well, you're
Robert Haas robertmh...@gmail.com writes:
I think you've gotten to the heart of the matter here. Extensions
need to either be schema objects, or not. If they are, let's go all
the way and compel everything in the extension to live in the schema
that owns it, and make the extension itself
On 10-12-06 09:00 PM, Josh Berkus wrote:
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.
Attached are runs against two different disk
The reasons are simple, particularly, I don't want to bloat SQL
with CAST or ::. Its not elegant and looks ugly. If I need to bind
e.g. int or short I don't want write ::integer or ::smallint in SQL,
because I can easily map int to integer via OID...
I don't clearly understand how
Robert Haas robertmh...@gmail.com writes:
I'm also going to go through and change all instances of the word
unlogged to volatile, per previous discussion. If this seems like
a bad idea to anyone, please object now rather than afterwards.
Hm... I thought there had been discussion of a couple
On 12/07/2010 08:24 AM, Tom Lane wrote:
Dropping open_datasync as the first-choice default is something we have
to back-patch, but I'm less sure about it being a good idea to
back-patch the rearrangement of O_DIRECT management. Somebody who'd
explicitly specified open_sync or open_datasync as
On Tue, Dec 7, 2010 at 1:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm also going to go through and change all instances of the word
unlogged to volatile, per previous discussion. If this seems like
a bad idea to anyone, please object now rather than
Hi,
no, no patch(es) yet. I'm going through plpython.c trying as best I can
to improve things there. I'll have a patch (or patches) ready for the
January commitfest, but I thought I'd open up a discussion already to
spare me having to redo features because the way I attacked the problem
is a dead
On Tuesday 07 December 2010 20:17:57 Jan Urbański wrote:
Hi,
no, no patch(es) yet. I'm going through plpython.c trying as best I can
to improve things there. I'll have a patch (or patches) ready for the
January commitfest, but I thought I'd open up a discussion already to
spare me having to
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 7, 2010 at 1:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm... I thought there had been discussion of a couple of different
flavors of table volatility. Is it really a good idea to commandeer
the word volatile for this particular one?
So
On 07/12/10 21:33, Andres Freund wrote:
On Tuesday 07 December 2010 20:17:57 Jan Urbański wrote:
* execute SPI calls in a subtransaction, report errors back to Python
as exceptions that can be caught etc.
Youre doing that unconditionally? I think the performance impact of this will
be too
David E. Wheeler da...@kineticode.com writes:
Overall I think the docs could use a lot more fleshing out. Some of
the stuff in the wiki would help a lot. At some point, though, I'll
work over the docs myself and either send a patch to you or to the
list (if it has been committed to core).
Ok,
Tom Lane t...@sss.pgh.pa.us writes:
I confess to not having paid a whole lot of attention to the threads
about this feature, so maybe this point has been addressed already, but:
what of the schema itself? That is, if an extension has some/all of its
objects in a given schema, is that schema
On Dec 7, 2010, at 8:00 AM, Dimitri Fontaine wrote:
You write a very simple contrib module exclusively for testing. It
doesn't have to actually do anything other than create a couple of
objects. A domain perhaps.
What about unaccent? Or lo (1 domain, 2 functions)?
Sure. Doesn't have to
On Dec 7, 2010, at 1:17 PM, Dimitri Fontaine wrote:
Anyway, in a less blue-sky vein: we could fix some of these problems by
having an explicit relocatable-or-not property for extensions. If it is
relocatable, it's required to keep all its owned objects in the target
schema, and ALTER
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Anyway, in a less blue-sky vein: we could fix some of these problems by
having an explicit relocatable-or-not property for extensions. If it is
relocatable, it's required to keep all its owned objects in the
On tis, 2010-12-07 at 20:17 +0100, Jan Urbański wrote:
no, no patch(es) yet. I'm going through plpython.c trying as best I can
to improve things there. I'll have a patch (or patches) ready for the
January commitfest, but I thought I'd open up a discussion already to
spare me having to redo
On 12/07/2010 04:50 PM, Peter Eisentraut wrote:
The code is on https://github.com/wulczer/postgres, in the plpython
branch. I'll be rebasing it regularly, so don't be surprised by commit
hashes changing.
I think rebasing published repositories isn't encouraged.
Indeed. See
On Tue, Dec 7, 2010 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 7, 2010 at 1:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm... I thought there had been discussion of a couple of different
flavors of table volatility. Is it really a good
Josh Berkus j...@agliodbs.com writes:
I agree for the backpatch that we should just swap to fdatasync as
default, and should not attempt to add the extra options.
I noticed while updating the documentation for this that the current
documentation is a flat-out lie. It claims that the
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 7, 2010 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think a more relevant question is how complicated it'll be to issue
those fsyncs --- do you have a concrete implementation in mind?
It can reuse most of the infrastructure we use for
On 12/7/10 2:28 PM, Tom Lane wrote:
Another point here is that it's not clear why we're selecting a
known-to-be-insecure default on OS X (where in fact all methods except
fsync_writethrough fail to push data to disk). We've been around on
that before, of course, and maybe now is not the time
2010/12/7 Robert Haas robertmh...@gmail.com:
On Tue, Dec 7, 2010 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 7, 2010 at 1:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hm... I thought there had been discussion of a couple of different
On 07/12/10 23:00, Andrew Dunstan wrote:
On 12/07/2010 04:50 PM, Peter Eisentraut wrote:
The code is on https://github.com/wulczer/postgres, in the plpython
branch. I'll be rebasing it regularly, so don't be surprised by commit
hashes changing.
I think rebasing published repositories isn't
On Tue, Dec 7, 2010 at 5:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Dec 7, 2010 at 3:44 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think a more relevant question is how complicated it'll be to issue
those fsyncs --- do you have a concrete
Josh Berkus j...@agliodbs.com writes:
On 12/7/10 2:28 PM, Tom Lane wrote:
Another point here is that it's not clear why we're selecting a
known-to-be-insecure default on OS X (where in fact all methods except
fsync_writethrough fail to push data to disk). We've been around on
that before, of
On 12/07/2010 06:11 PM, Tom Lane wrote:
Josh Berkusj...@agliodbs.com writes:
On 12/7/10 2:28 PM, Tom Lane wrote:
Another point here is that it's not clear why we're selecting a
known-to-be-insecure default on OS X (where in fact all methods except
fsync_writethrough fail to push data to
On Tue, 2010-12-07 at 18:11 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
On 12/7/10 2:28 PM, Tom Lane wrote:
Another point here is that it's not clear why we're selecting a
known-to-be-insecure default on OS X (where in fact all methods except
fsync_writethrough fail to
I wrote:
Some of us would make the same remark about Windows. But we go out of
our way to provide a safe default on that platform anyhow.
Oh, wait: that's not the case at all. As of recent releases, we support
open_datasync on Windows, and that's the default despite being unsafe.
You have to
Joshua D. Drake j...@commandprompt.com writes:
On Tue, 2010-12-07 at 18:11 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Because nobody sane uses OSX on the server?
Some of us would make the same remark about Windows. But we go out of
our way to provide a safe default on that
I am unclear as to the reason why there is a test for
HAVE_FSYNC_WRITETHROUGH_ONLY in pg_fsync(). Perhaps that is also
leftover from a previous vision of how this all works? Or does an
fsync() call actually fail on Windows?
No, fsync responds fine. It just don't actually sync to disk.
--
On Dec 7, 2010, at 2:43 PM, Josh Berkus wrote:
Because nobody sane uses OSX on the server?
The XServe running 10.5 server and 9.0.1 at the other end of the office takes
your remark personally. :)
--
-- Christophe Pettus
x...@thebuild.com
--
Sent via pgsql-hackers mailing list
Josh Berkus j...@agliodbs.com writes:
I am unclear as to the reason why there is a test for
HAVE_FSYNC_WRITETHROUGH_ONLY in pg_fsync(). Perhaps that is also
leftover from a previous vision of how this all works? Or does an
fsync() call actually fail on Windows?
No, fsync responds fine. It
Right, which is also an accurate description of its behavior on OS X,
as well as Linux (if you didn't change hdparm settings). So the real
question here is what's the point of treating Windows differently.
So, sounds like we should continue treating fsync_writethrough the same
as we have
Josh Berkus j...@agliodbs.com writes:
Right, which is also an accurate description of its behavior on OS X,
as well as Linux (if you didn't change hdparm settings). So the real
question here is what's the point of treating Windows differently.
So, sounds like we should continue treating
x...@thebuild.com (Christophe Pettus) writes:
On Dec 7, 2010, at 2:43 PM, Josh Berkus wrote:
Because nobody sane uses OSX on the server?
The XServe running 10.5 server and 9.0.1 at the other end of the
office takes your remark personally. :)
I'd heard that Apple had cancelled XServe.
On Tue, 2010-12-07 at 19:00 -0500, Chris Browne wrote:
x...@thebuild.com (Christophe Pettus) writes:
On Dec 7, 2010, at 2:43 PM, Josh Berkus wrote:
Because nobody sane uses OSX on the server?
The XServe running 10.5 server and 9.0.1 at the other end of the
office takes your remark
On 12/07/2010 07:32 PM, Joshua D. Drake wrote:
On Tue, 2010-12-07 at 19:00 -0500, Chris Browne wrote:
x...@thebuild.com (Christophe Pettus) writes:
On Dec 7, 2010, at 2:43 PM, Josh Berkus wrote:
Because nobody sane uses OSX on the server?
The XServe running 10.5 server and 9.0.1 at the
Tom Lane t...@sss.pgh.pa.us wrote:
I assume this would have to be a hard definition of READ ONLY,
not the rather squishy definition we use now?
Oh, I just went through the code on setting READ ONLY and discovered
that contrary to the standard *and* the PostgreSQL documentation,
you can change
Josh Berkus j...@agliodbs.com writes:
I am unclear as to the reason why there is a test for
HAVE_FSYNC_WRITETHROUGH_ONLY in pg_fsync(). Perhaps that is also
leftover from a previous vision of how this all works? Or does an
fsync() call actually fail on Windows?
No, fsync responds fine. It
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Oh, I just went through the code on setting READ ONLY and discovered
that contrary to the standard *and* the PostgreSQL documentation,
you can change the status of a transaction between READ ONLY and
READ WRITE at will. Yeah, that's a problem
On Tue, Dec 7, 2010 at 4:29 PM, David E. Wheeler da...@kineticode.com wrote:
IOW, if I install extension foo and it does *not* have the above
magic line, then this command will *not* do what I expect:
CREATE EXTENSION foo WITH SCHEMA bar;
Extension foo will be in the public schema
Hi, folks,
I trace the running postgres, and I found that there are some randoms writes
in xlog files!
To my impression, log file writing is always sequential, how come random
writes happen?
Thanks in advance!
On Thu, Dec 2, 2010 at 2:52 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, committed, with some small cleanup since the last patch I posted.
Could you update the directory-format patch on top of the committed version,
please?
Thanks for committing the first part. Here
I can not used SIGHUP, as it is already in use.
I want to wake up the postmaster once the trigger file is generated
and tell it to switch over from standby mode.
Is it possible?
On Wed, Dec 8, 2010 at 9:17 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Dec 7, 2010 at 4:22 PM, aaliya
Tom Lane wrote:
So actually, there is no difference between selecting fsync and
fsync_writethrough on Windows, this comment and the SGML documentation
to the contrary. Both settings result in invoking _commit() and
presumably are safe. One wonders why we bothered to invent a separate
On Wed, Dec 8, 2010 at 02:07, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
I am unclear as to the reason why there is a test for
HAVE_FSYNC_WRITETHROUGH_ONLY in pg_fsync(). Perhaps that is also
leftover from a previous vision of how this all works? Or does an
On 08.12.2010 06:12, aaliya zarrin wrote:
I can not used SIGHUP, as it is already in use.
I want to wake up the postmaster once the trigger file is generated
and tell it to switch over from standby mode.
Is it possible?
SIGHUP works precisely because it is already in use. When you send
77 matches
Mail list logo
