2009/11/15 Andrew Gierth and...@tao11.riddles.org.uk:
Hitoshi == Hitoshi Harada umi.tan...@gmail.com writes:
Hitoshi Hi, During reviewing aggregates ORDER BY, I was reading spec
Hitoshi and found description like:
Hitoshi == snip ==
Hitoshi Of the rows in the aggregation, the following
After some time thinking about the best way forward for Hot Standby, I
have some observations and proposals.
First, the project is very large. We have agreed ways to trim the patch,
yet it remains large. Trying to do everything in one lump is almost
always a bad plan, so we need to phase things.
On Sun, Nov 15, 2009 at 09:06, Simon Riggs si...@2ndquadrant.com wrote:
* Issues relating to handling of prepared transactions
There are some delicate issues surrounding what happens at the end of
recovery if there is a prepared transaction still holding an access
exclusive lock. It is
After consulting with some other members of the community, I tried to
post my fk error string patch to the current commitfest, but
mistakenly posted it to the current commitfest, not the open one.
When I tried to correct this by moving the patch to the open 2010-01
commitfest, I could not submit
On Sat, Nov 14, 2009 at 21:07, u235sentinel u235senti...@gmail.com wrote:
I'm curious if anyone has tried to link postgres authentication with a
product called likewise.
Likesoft software will allow a linux/unix system to authenticate against a
windows domain. I have it working on several
On Sun, 2009-11-15 at 10:00 +0100, Magnus Hagander wrote:
What does the time depend on?
We need to wait for all current transactions to complete. (i.e. any
backend that has (or could) take an xid or an AccessExclusiveLock before
it commits.). Similar-ish to the wait for a CREATE INDEX
On Sunday, November 15, 2009, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2009-11-15 at 10:00 +0100, Magnus Hagander wrote:
What does the time depend on?
We need to wait for all current transactions to complete. (i.e. any
backend that has (or could) take an xid or an AccessExclusiveLock
On Sat, 2009-11-14 at 08:43 -0800, Robert Hodges wrote:
I can help set up automated basic tests for hot standby using 1+1 setups on
Amazon. I¹m already working on tests for warm standby for our commercial
Tungsten implementation and need to solve the problem of creating tests that
adapt
Here's my first review.
The patch was in context diff format and applied cleanly with a little
3 hunks in parse_expr.c. make succeeded without any warnings and make
check passed all 121 tests.
It implements as advertised, following SQL spec with extension of both
DISTINCT clause and ORDER BY
Simon Riggs wrote:
On Sat, 2009-11-14 at 14:59 +0200, Heikki Linnakangas wrote:
I can't see any obvious way around that.
Huh? We're only doing this strict locking approach because you insisted
that the looser approach was not acceptable.
Take it easy, Simon. By obvious, I meant trivial or
On Sun, Nov 15, 2009 at 4:21 AM, George Gensure wer...@gmail.com wrote:
After consulting with some other members of the community, I tried to
post my fk error string patch to the current commitfest, but
mistakenly posted it to the current commitfest, not the open one.
When I tried to correct
Oh, forgot to mention another thing that I've been pondering:
Currently, the running-xacts record is written to the WAL after the
checkpoint record. There's a small chance that you get an xlog switch in
between. If that happens, it might take a long time after the checkpoint
record until the
On fre, 2009-11-13 at 11:27 -0700, James Pye wrote:
Some are TODOs, so in part by other people. Some were briefly touched
on in the recent past discussions(around the time that I announced the
WIP). Native typing vs conversion, function fragments vs function
modules.
I'm of course only one
Simon Riggs wrote:
We need to wait for all current transactions to complete. (i.e. any
backend that has (or could) take an xid or an AccessExclusiveLock before
it commits.). Similar-ish to the wait for a CREATE INDEX CONCURRENTLY.
The standby already performs this wait in the case where we
Simon Riggs wrote:
* Issues relating to handling of prepared transactions
There are some delicate issues surrounding what happens at the end of
recovery if there is a prepared transaction still holding an access
exclusive lock.
Can you describe in more detail what problem this is again? We
On Sun, Nov 15, 2009 at 3:06 AM, Simon Riggs si...@2ndquadrant.com wrote:
Please can we agree a way forwards?
I don't have a strong position on the technical issues, but I am very
much in favor of getting something committed, even something with
limitations, as soon as we practically can.
Simon Riggs wrote:
There are two remaining areas of significant thought/effort:
Here's a list of other TODO items I've collected so far. Some of them
are just improvements or nice-to-have stuff, but some are more serious:
- If WAL recovery runs out of lock space while acquiring an
On Sun, 2009-11-15 at 14:43 +0200, Heikki Linnakangas wrote:
This isn't absolutely necessary for the first version, but it's
something to keep in mind...
Do I take that as agreement to the phased plan?
In general, I'd like to remove as many as possible of those cases
where the standby
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
There are two remaining areas of significant thought/effort:
Here's a list of other TODO items I've collected so far. Some of them
are just improvements or nice-to-have stuff, but some are more serious:
- If
On Sun, Nov 15, 2009 at 2:32 PM, Simon Riggs si...@2ndquadrant.com wrote:
- The standby delay is measured as current timestamp - timestamp of
last replayed commit record. If there's little activity in the master,
that can lead to surprising results. For example, imagine that
max_standby_delay
Simon Riggs wrote:
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
- If WAL recovery runs out of lock space while acquiring an
AccessExclusiveLock on behalf of a transaction that ran in the master,
it will FATAL and abort recovery, bringing down the standby. Seems like
it should
On Sun, 2009-11-15 at 14:47 +, Greg Stark wrote:
On Sun, Nov 15, 2009 at 2:32 PM, Simon Riggs si...@2ndquadrant.com wrote:
- The standby delay is measured as current timestamp - timestamp of
last replayed commit record. If there's little activity in the master,
that can lead to
On Sun, 2009-11-15 at 16:50 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
- If WAL recovery runs out of lock space while acquiring an
AccessExclusiveLock on behalf of a transaction that ran in the master,
it will FATAL and
On Sun, Nov 15, 2009 at 9:50 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
- If WAL recovery runs out of lock space while acquiring an
AccessExclusiveLock on behalf of a transaction that ran in
On Thu, 12 Nov 2009 11:22:32 -0500
Andrew Chernow a...@esilo.com wrote:
However I share Greg's concerns that people are trying to use NOTIFY
as a message queue which it is not designed to be.
When you have an established libpq connection waiting for notifies it
is not unreasonable to
George Gensure wer...@gmail.com writes:
I've put together a small patch to provide a schema name in an fk
violation in deference to the todo item Report the schema along table
name in a referential failure error message
This is not the way forward; if it were, we would have done it years
ago.
Robert Haas wrote:
OK, but... there will always be things that will bring down the
stand-by, just as there will always be things that can bring down the
primary. A bucket of ice-water will probably do it, for example. I
mean, it would be great to make it better, but is it so bad that we
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
The assumption that b-tree vacuum records don't need conflict
resolution because we did that with the additional cleanup-info record
works ATM, but it hinges on the fact that we don't delete any tuples
marked as killed while we do
Simon Riggs wrote:
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
The assumption that b-tree vacuum records don't need conflict
resolution because we did that with the additional cleanup-info record
works ATM, but it hinges on the fact that we don't delete any tuples
marked as
At Tom's suggestion I am looking at allowing use of parameter names in
SQL functions instead of requiring use of $1 etc. That raises the
question of how we would disambiguate a parameter name from a column
name. Essentially, ISTM, we could use some special marker such as @
(c.f. SQL Server)
Andrew Dunstan wrote:
At Tom's suggestion I am looking at allowing use of parameter names in
SQL functions instead of requiring use of $1 etc. That raises the
question of how we would disambiguate a parameter name from a column
name. Essentially, ISTM, we could use some special marker such
2009/11/15 Andrew Dunstan and...@dunslane.net:
At Tom's suggestion I am looking at allowing use of parameter names in SQL
functions instead of requiring use of $1 etc. That raises the question of
how we would disambiguate a parameter name from a column name. Essentially,
ISTM, we could use
On Sun, 2009-11-15 at 19:36 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
The assumption that b-tree vacuum records don't need conflict
resolution because we did that with the additional cleanup-info record
works ATM,
2009/11/15 Andrew Chernow a...@esilo.com:
Andrew Dunstan wrote:
At Tom's suggestion I am looking at allowing use of parameter names in SQL
functions instead of requiring use of $1 etc. That raises the question of
how we would disambiguate a parameter name from a column name. Essentially,
On Sun, Nov 15, 2009 at 12:37 PM, Andrew Dunstan and...@dunslane.net wrote:
At Tom's suggestion I am looking at allowing use of parameter names in SQL
functions instead of requiring use of $1 etc. That raises the question of
how we would disambiguate a parameter name from a column name.
On Sun, Nov 15, 2009 at 11:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
George Gensure wer...@gmail.com writes:
I've put together a small patch to provide a schema name in an fk
violation in deference to the todo item Report the schema along table
name in a referential failure error message
On Sun, Nov 15, 2009 at 11:49 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Agreed. Believe me, I'd like to have this committed as much as everyone
else. But once I do that, I'm also committing myself to fix all the
remaining issues before the release. The criteria for
On Sun, Nov 15, 2009 at 5:49 PM, Andrew Chernow a...@esilo.com wrote:
Andrew Dunstan wrote:
At Tom's suggestion I am looking at allowing use of parameter names in SQL
functions instead of requiring use of $1 etc. That raises the question of
how we would disambiguate a parameter name from a
We still need to decide what to do with queue full situations in the proposed
listen/notify implementation. I have a new version of the patch to allow for a
variable payload size. However, the whole notification must fit into one page so
the payload needs to be less than 8K.
I have also added the
On Nov 15, 2009, at 10:19 AM, Greg Stark wrote:
I like the special marker idea. A '$' would be nice because its already in
use for similar purposes, but I think that would lead to ambiguity with
dollar quoting.
I think that would be a big break with everything else and very
non-sql-ish.
Simon Riggs wrote:
On Sun, 2009-11-15 at 19:36 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 16:07 +0200, Heikki Linnakangas wrote:
The assumption that b-tree vacuum records don't need conflict
resolution because we did that with the additional cleanup-info record
On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote:
3. Every distinct notification is delivered.
Regarding performance, the slru-queue is not fsync-ed to disk
These two statements seem to be in opposition. How do you know a
notification will be delivered if the queue is
Robert Haas wrote:
But a
query getting canceled because it touches a lot of tables sounds more
like a limitation than an outright bug,
It's not that the query might get canceled. It will abort WAL recovery,
kill all backends, and bring the whole standby down.
--
Heikki Linnakangas
2009/11/15 David E. Wheeler da...@kineticode.com:
On Nov 15, 2009, at 10:19 AM, Greg Stark wrote:
I like the special marker idea. A '$' would be nice because its already in
use for similar purposes, but I think that would lead to ambiguity with
dollar quoting.
I think that would be a big
George Gensure wrote:
This begs a bigger question: what's *really* easy or low barrier to
entry for very light contributors like myself? - I've got time, I like
the product, I need to know what's going to get you a win, I may not
be gunning particularly for the feature myself.
The TODO
On Sun, 2009-11-15 at 13:15 -0500, Robert Haas wrote:
I know Simon has said that he feels that the effort
to finish the HS and SR patches for 9/15 was somewhat of an artificial
deadline, but ISTM that with only 3 months remaining until the close
of the final CommitFest for this release, and
On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
Personally, I like $var, but @var would be okay, and @@var is acceptable.
But I'm JAPH, so my biases should be obvious.
@var or @@var should be a break for people from MySQL. @var are r/w in
MySQL and @@var are
On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler da...@kineticode.com wrote:
Personally, I like $var, but @var would be okay, and @@var is acceptable. But
I'm JAPH, so my biases should be obvious.
I'm japh too -- but that doesn't mean grabbing one little aesthetic
from Perl without copying
On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote:
The LSN doesn't help there, because when an itemid is marked as dead,
the LSN is not updated.
I was thinking we could update the index block LSN without writing WAL
using the LSN of the heap block that leads to the killed tuple.
2009/11/16 Andrew Dunstan and...@dunslane.net:
At Tom's suggestion I am looking at allowing use of parameter names in SQL
functions instead of requiring use of $1 etc. That raises the question of
how we would disambiguate a parameter name from a column name. Essentially,
ISTM, we could use
2009/11/15 Greg Stark gsst...@mit.edu:
On Sun, Nov 15, 2009 at 6:42 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Personally, I like $var, but @var would be okay, and @@var is acceptable.
But I'm JAPH, so my biases should be obvious.
@var or @@var should be a break for people from
On Nov 15, 2009, at 10:54 AM, Greg Stark wrote:
I'm japh too -- but that doesn't mean grabbing one little aesthetic
from Perl without copying the whole concept behind it makes any sense.
Perl sigils are an important part of the language and are a basic part
of the syntax. They aren't just a
I like the special marker idea. A '$' would be nice because its already in
use for similar purposes, but I think that would lead to ambiguity with
dollar quoting.
no, it should be safe (if you don't use for dollar quoting some like
$variablename$)
Actually, I was thinking of something
2009/11/15 Andrew Chernow a...@esilo.com:
I like the special marker idea. A '$' would be nice because its already
in
use for similar purposes, but I think that would lead to ambiguity with
dollar quoting.
no, it should be safe (if you don't use for dollar quoting some like
$variablename$)
Simon Riggs wrote:
On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote:
The LSN doesn't help there, because when an itemid is marked as dead,
the LSN is not updated.
I was thinking we could update the index block LSN without writing WAL
using the LSN of the heap block that leads
On Sun, Nov 15, 2009 at 6:26 PM, David E. Wheeler da...@kineticode.com wrote:
Moreover you would still have conflicts possible because sql can quote
identifiers so people can have columns named $foo. You would have a
weird syntactic detail where $foo would mean something different
than $foo
On Nov 15, 2009, at 11:21 AM, Greg Stark wrote:
No, that's not the same.
The point is that $ is a perfectly valid SQL identifier character and
$foo is a perfectly valid identifier. You can always quote any
identifier (yes, after case smashing) so you would expect if $foo is a
valid
On Sun, 2009-11-15 at 20:37 +0200, Heikki Linnakangas wrote:
Robert Haas wrote:
But a
query getting canceled because it touches a lot of tables sounds more
like a limitation than an outright bug,
It's not that the query might get canceled. It will abort WAL recovery,
kill all backends,
Tom Lane wrote:
It looks to me like the code in AlterSetting() will allow an ordinary
user to blow away all settings for himself. Even those that are for
SUSET variables and were presumably set for him by a superuser. Isn't
this a security hole? I would expect that an unprivileged user
On Sun, Nov 15, 2009 at 7:25 PM, David E. Wheeler da...@kineticode.com wrote:
On Nov 15, 2009, at 11:21 AM, Greg Stark wrote:
$foo should be killed off as a valid identifier, IMNSHO.
But failing that, some other sigil would be most welcome.
I don't think SQL is the height of language design
On Sun, Nov 15, 2009 at 7:29 PM, Simon Riggs si...@2ndquadrant.com wrote:
You agree there should be two phases?
I don't understand this repeated suggestion of phases. Nobody's
every suggested that we would refuse to add new features to HS after
the initial commit or the 8.5 release. Of course
David E. Wheeler wrote:
$foo should be killed off as a valid identifier, IMNSHO.
It's only legal when quoted. Unquoted indetifiers can't begin with $.
see scan.l:
ident_start [A-Za-z\200-\377_]
ident_cont [A-Za-z\200-\377_0-9\$]
identifier
On Sun, 2009-11-15 at 21:20 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote:
The LSN doesn't help there, because when an itemid is marked as dead,
the LSN is not updated.
I was thinking we could update the index block
Simon Riggs wrote:
You agree there should be two phases?
I'm hesitant to say 'yes', because then you will harass me with but you
said that you would be OK with fixing X, Y, Z later! Why don't you
commit already!.
Of course there should be several phases! We've *already* punted a lot
of stuff
The point is that $ is a perfectly valid SQL identifier character and
$foo is a perfectly valid identifier. You can always quote any
identifier (yes, after case smashing) so you would expect if $foo is a
valid identifier then $foo would refer to the same identifier.
This case already exists
Hitoshi == Hitoshi Harada umi.tan...@gmail.com writes:
Hitoshi Questions here:
Hitoshi - agglevelsup?
Hitoshi We have aggregate capability that all arguments from upper
Hitoshi level query in downer level aggregate makes aggregate call
Hitoshi itself to upper level call, as a constant
On Sun, Nov 15, 2009 at 7:56 PM, Andrew Chernow a...@esilo.com wrote:
The point is that $ is a perfectly valid SQL identifier character and
$foo is a perfectly valid identifier. You can always quote any
identifier (yes, after case smashing) so you would expect if $foo is a
valid identifier
Simon Riggs wrote:
On Sun, 2009-11-15 at 21:20 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 20:30 +0200, Heikki Linnakangas wrote:
The LSN doesn't help there, because when an itemid is marked as dead,
the LSN is not updated.
I was thinking we could update the
On Sun, 2009-11-15 at 21:37 +0200, Heikki Linnakangas wrote:
Am I missing anything?
Will review.
I also experimented with including the running-xacts information in the
checkpoint record itself. That somehow feels more straightforward to me,
but it wasn't really any less code, and it
On Nov 15, 2009, at 12:09 PM, Greg Stark wrote:
1) Error messages which mention column names are supposed to quote the
column name to set it apart from the error string. This also
guarantees that weird column names are referenced correctly as foo
bar or $foo so the reference in the error
On Nov 15, 2009, at 11:35 AM, Greg Stark wrote:
I don't think SQL is the height of language design either. But trying
to turn it into another language piece by piece is not gong to make it
any nicer.
I don't know of anyone suggesting such a thing.
A sigil here doesn't accomplish anything.
Simon Riggs wrote:
On Sun, 2009-11-15 at 21:37 +0200, Heikki Linnakangas wrote:
Am I missing anything?
Will review.
Thanks! Please use the head of git branch, I already found one major
oversight in what I posted that's fixed there... I should go to bed already.
--
Heikki Linnakangas
On Sun, 2009-11-15 at 21:56 +0200, Heikki Linnakangas wrote:
If you actually want to help, can you please focus on fixing the
must-fix bugs we know about? We can then discuss which of the
remaining known issues we're willing to live with.
I intend to work on all of the issues, so not sure
Simon Riggs wrote:
Right now, I don't know which you
consider to be the must-fix issues, hence the thread.
Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the
index pages after the last b-tree vacuum record? Thanks.
--
Heikki Linnakangas
EnterpriseDB
Robert Haas wrote:
(Maybe I should automatically create a Miscellaneous topic when each new CF
is added?)
I'm surprised you're populating each one from scratch every time, that
seems like duplicated effort begging to be automated. Couldn't you just
come up with a stock list of the most
On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Right now, I don't know which you
consider to be the must-fix issues, hence the thread.
Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the
index pages after the last b-tree vacuum record?
On 11/15/09 12:58 PM, Simon Riggs wrote:
On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Right now, I don't know which you
consider to be the must-fix issues, hence the thread.
Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the
index pages
On Sun, 2009-11-15 at 23:14 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Right now, I don't know which you
consider to be the must-fix issues, hence the thread.
Ok, could you tackle the b-tree vacuum
I wrote:
Attached is the latest version of this patch.
Here's that same patch in context diff format. Sorry for the noise.
Regards,
Marko Tiikkaja
*** a/doc/src/sgml/queries.sgml
--- b/doc/src/sgml/queries.sgml
***
*** 1499,1505 SELECT 3, 'three';
synopsis
SELECT
With some lazy Sunday slack, the 2009-11 CommitFest is now officially
closed. Due to a bumper crop of review volunteers, almost all patches
are already assigned an initial reviewer. Here are the notable exceptions:
SE-PostgreSQL/Lite: It's hard to find a reviewer willing to take on a
patch
Andrew Dunstan and...@dunslane.net writes:
At Tom's suggestion I am looking at allowing use of parameter names in
SQL functions instead of requiring use of $1 etc. That raises the
question of how we would disambiguate a parameter name from a column
name.
Throw error if ambiguous. We
Simon Riggs wrote:
On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Right now, I don't know which you
consider to be the must-fix issues, hence the thread.
Ok, could you tackle the b-tree vacuum bug, where we neglect to pin the
index pages after the last b-tree
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote:
3. Every distinct notification is delivered.
Regarding performance, the slru-queue is not fsync-ed to disk
These two statements seem to be in opposition. How do you know a
notification will be
Andrew Dunstan and...@dunslane.net writes:
George Gensure wrote:
This begs a bigger question: what's *really* easy or low barrier to
entry for very light contributors like myself?
The TODO list at http://wiki.postgresql.org/wiki/Todo doesn't seem to
have a huge number or [E] items. Maybe
Hello
I propose to add possibility to use psql variables as real query
parameters. The goal of this proposal is simplification of creating
psql based commands. Current using of psql variables based on
substitution has large area of using, but has some risks. a) there are
possible sql injection,
David Fetter da...@fetter.org writes:
On Sun, Nov 15, 2009 at 10:09:14AM -0500, Andrew Dunstan wrote:
Peter Eisentraut wrote:
/home/peter/commit-msg
er, what?
I'm suspecting a misfired script somewhere.
No doubt cvs commit -m ~/commit-msg instead of cvs commit -F ~/commit-msg
... I think
Josh Berkus j...@agliodbs.com writes:
So I'm in favor of committing part of the HS code even if there are
known failure conditions, as long as those conditions are well-defined.
If we're thinking of committing something that is known broken, I would
want to have a clearly defined and
2009/11/16 Tom Lane t...@sss.pgh.pa.us:
The real problem with the entry that George picked up on was that it was
misdescribed and mislabeled as easy because whoever put it in ignored
the fact that there was not a consensus to do a half-baked fix ...
this is a problem with a wiki TODO list :-(
On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2009-11-11 at 22:25 +0100, Joachim Wieland wrote:
3. Every distinct notification is delivered.
Regarding performance, the slru-queue is not fsync-ed to disk
These two statements seem to
Brendan Jurd dire...@gmail.com writes:
However, I'm not sure how productive the [E]asy marker can really be.
Items end up on the TODO generally because a) we couldn't settle on a
way forward, or b) nobody was keen to do it right away. There just
aren't many genuinely easy items in there, easy
Simon Riggs si...@2ndquadrant.com writes:
On Sun, 2009-11-15 at 16:48 -0500, Tom Lane wrote:
You misunderstand the requirements. LISTEN notifications are *not*
meant to survive a database crash, and never have been. However,
so long as both client and server stay up, they must be reliable.
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Andrew Performance.
Andrew tuplesort_getdatum etc. seems to be substantially faster than
Andrew tuplesort_gettupleslot especially for the case where you're
Andrew sorting a pass-by-value datum such as an integer (since the
Andrew
On Nov 15, 2009, at 2:17 PM, Tom Lane wrote:
So I'm in favor of committing part of the HS code even if there are
known failure conditions, as long as those conditions are well-defined.
If we're thinking of committing something that is known broken, I would
want to have a clearly defined and
David E. Wheeler da...@kineticode.com writes:
On Nov 15, 2009, at 2:17 PM, Tom Lane wrote:
I agree with Heikki that it would be better not to commit as long as
any clear showstoppers remain unresolved.
If ever there were an argument for topic branches, *this is it*.
How so? They've got a
On Nov 15, 2009, at 4:19 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2009-11-15 at 23:14 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-11-15 at 22:45 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Right now, I don't know which you
consider to be the must-fix
On 11/15/09 2:25 AM PST, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2009-11-14 at 08:43 -0800, Robert Hodges wrote:
I can help set up automated basic tests for hot standby using 1+1 setups on
Amazon. I¹m already working on tests for warm standby for our commercial
Tungsten
On Sun, Nov 15, 2009 at 12:50:14AM +, Roger Leigh wrote:
On Sat, Nov 14, 2009 at 01:31:29PM -0500, Tom Lane wrote:
Roger Leigh rle...@codelibre.net writes:
The side effect from this change is that some of the testsuite
expected data will need updating due to the extra pad spaces
On Sun, Nov 15, 2009 at 11:23 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Future performance enhancements (which I have no particular plans to
tackle) would involve having the planner consult the desired aggregate
orderings and estimating the cost of sorting as opposed to the cost of
Magnus Hagander wrote:
On Sat, Nov 14, 2009 at 13:35, Robert Haas robertmh...@gmail.com wrote:
On Sat, Nov 14, 2009 at 4:11 AM, Magnus Hagander mag...@hagander.net
wrote:
How about we add specific feature(s) about tihs to the commitfest
management tool? Like the possibility to directly
Tom Lane wrote:
Yeah, that is a real problem for new would-be contributors --- there
simply isn't that much low-hanging fruit waiting for them, unless
they focus on areas that no one else has taken much interest in;
and even then there are few really small tasks.
1 - 100 of 144 matches
Mail list logo
