--On 4. November 2009 09:57:27 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
Yeah, this is a known issue. The ALTER should be rejected, but it is
not, because we don't have enough infrastructure to notice that the
constraint is inherited and logically can't be dropped. I think the
consensus was
On 26/05/10 23:31, Dimitri Fontaine wrote:
So if you want simplicity to admin, effective data availability and
precise control over the global setup, I say go for:
a. transaction level control of the replication level
b. cascading support
c. quorum with timeout
d. choice of commit or
On 12/05/10 22:23, Robert Haas wrote:
On Wed, May 12, 2010 at 3:01 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Tom Lane wrote:
If so, master/standby would probably work.
+1 for master/standby.
It's worth remembering that a standby server might not be actively
Hi!
I've spent some time going through all the email threads since Alpha4
was released, and have updated the 9.0 Open Items list.
We have two sections of open items which need initial review by -hackers:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Code
On Wed, 2010-05-26 at 17:31 -0400, Jan Wieck wrote:
You can do this only with per standby options, by giving each standby a
weight, or a number of votes. Your DEV server would have a weight of
zero, while your production standby's have higher weights, depending on
their importance for your
On Thu, 2010-05-27 at 00:21 +0300, Heikki Linnakangas wrote:
On 26/05/10 23:31, Dimitri Fontaine wrote:
d. choice of commit or rollback at timeout
Rollback is not an option. There is no going back after the commit
record has been flushed to disk or sent to a standby.
There's definitely
On 19/05/10 00:37, Simon Riggs wrote:
On Tue, 2010-05-18 at 17:25 -0400, Heikki Linnakangas wrote:
On 18/05/10 17:17, Simon Riggs wrote:
There's no reason that the buffer size we use for XLogRead() should be
the same as the send buffer, if you're worried about that. My point is
that
Committed with chunk size of 128 kB. I hope that's a reasonable
compromise, in the absence of any performance test data either way.
So where are we with max_standby_delay? Status check?
--
-- Josh Berkus
PostgreSQL
On Thu, 2010-05-27 at 01:34 +0300, Heikki Linnakangas wrote:
Committed with chunk size of 128 kB.
Thanks. I'm sure that's fine.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Sun, 2010-05-16 at 17:11 +0100, Simon Riggs wrote:
New version, with some other cleanup of wait processing.
New logic is that when Startup asks for next applychunk of WAL it saves
the lastChunkTimestamp. That is then the base time used by
WaitExceedsMaxStandbyDelay(), except when
Peter Eisentraut wrote:
It turns out that the SQL standard uses the function call notation
foo(this AS that)
for something else:
routine invocation ::= routine name SQL argument list
routine name ::= [ schema name period ] qualified identifier
SQL argument list ::= left paren [ SQL
On Wed, 2010-05-26 at 15:45 -0700, Josh Berkus wrote:
Committed with chunk size of 128 kB. I hope that's a reasonable
compromise, in the absence of any performance test data either way.
So where are we with max_standby_delay? Status check?
Just this second posted about that, as it turns
On 26/05/10 02:00, Sam Vilain wrote:
Florian Pflug wrote:
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
Releasing the newer savepoint will cause the older one to again become
accessible, as the doc says, but rolling back to a savepoint does not
implicitly release it. You'll have to
On Wed, May 12, 2010 at 8:00 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-05-12 at 19:33 +0300, Peter Eisentraut wrote:
The server's messages and the documentation uses all of these terms in
mixed ways. Maybe we could decide on some preferred terminology and
adjust the existing
On 5/26/2010 5:12 PM, Heikki Linnakangas wrote:
On 26/05/10 23:49, Jan Wieck wrote:
In this implementation it wouldn't even matter if a transaction that was
recorded actually never made it because it crashed before the WAL flush.
It would be reported by this commit order feature, but there
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
mechanism for this is 'paramname = value', but I think that has
problems
On 27/05/10 01:23, Simon Riggs wrote:
On Thu, 2010-05-27 at 00:21 +0300, Heikki Linnakangas wrote:
On 26/05/10 23:31, Dimitri Fontaine wrote:
d. choice of commit or rollback at timeout
Rollback is not an option. There is no going back after the commit
record has been flushed to disk or
Just this second posted about that, as it turns out.
I have a v3 *almost* ready of the keepalive patch. It still makes sense
to me after a few days reflection, so is worth discussion and review. In
or out, I want this settled within a week. Definitely need some RR
here.
Does the keepalive
On May 26, 2010, at 4:09 PM, alvherre wrote:
The problem with the = operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice. Perhaps we could allow = to resolve as the
operator for the case the user really needs
Just picking up a dropped thread, does anyone have a patch for this?
http://archives.postgresql.org/pgsql-hackers/2010-04/msg01191.php
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 27/05/10 02:09, alvherre wrote:
Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010:
I think we should fix it now. Quick thought: maybe we could use FOR
instead of AS: select myfunc(7 for a, 6 for b); IIRC the standard's
mechanism for this is 'paramname = value', but
On 5/26/2010 4:34 PM, Kevin Grittner wrote:
Jan Wieck janwi...@yahoo.com wrote:
Without this logic, the replication system could not combine
multiple origin sessions into one replication session without
risking to never find a state, in which it can commit.
My latest idea for handling this
The src/backend/parser/gram.c is a generated file, so shouldn't this be
removed by `make distclean`, or maybe even by `make clean`?
I did a `git clean -f -d` and even that did not remove gram.c, apparently
because this file _was_ alive at some point in the past hence git won't
remove it even
* alvherre (alvhe...@commandprompt.com) wrote:
Excerpts from Stephen Frost's message of mié may 26 15:19:59 -0400 2010:
* Robert Haas (robertmh...@gmail.com) wrote:
Then, too, there's the fact that many of these tests fail on my
machine because my username is not sfrost,
I've
Gurjeet Singh singh.gurj...@gmail.com writes:
The src/backend/parser/gram.c is a generated file, so shouldn't this be
removed by `make distclean`, or maybe even by `make clean`?
No. It's shipped in distribution tarballs. If you want all derived
files to be removed, use make maintainer-clean.
Josh Berkus j...@agliodbs.com writes:
How does that get us out of reading and writing old pages, though?
Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
your problem, because they cannot become set without having visited the
page.
regards, tom
Gurjeet Singh wrote:
I did a `git clean -f -d` and even that did not remove gram.c,
apparently because this file _was_ alive at some point in the past
hence git won't remove it even though the current branch does not have
gram.c.
At first glance that looks like a git bug.
cheers
alvherre alvhe...@commandprompt.com writes:
The problem with the = operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice.
Sucks is not the word; utterly unacceptable is the word. Having an
expression mean
On May 27, 2010, at 0:58 , Heikki Linnakangas wrote:
On 26/05/10 02:00, Sam Vilain wrote:
Florian Pflug wrote:
On May 25, 2010, at 12:18 , Heikki Linnakangas wrote:
Releasing the newer savepoint will cause the older one to again become
accessible, as the doc says, but rolling back to a
Stephen Frost sfr...@snowman.net writes:
* alvherre (alvhe...@commandprompt.com) wrote:
(And if we want something like this, I think we should not have a single
huge file for the complete test, but a set of smaller files. I'd even
put the bunch in src/bin/psql/regress rather than the main
* Tom Lane (t...@sss.pgh.pa.us) wrote:
There might be some value in psql backslash command tests that
are designed to depend on just one or a few tables (or other appropriate
objects). Dumping large fractions of the catalogs will just be a net
loss.
Fair enough, I can certainly do that
On 26/05/10 16:54, Heikki Linnakangas wrote:
On 26/05/10 16:16, Robert Haas wrote:
This comment obviously requires adjustment now that HS is committed.
The obvious way to change it is to replace when we get hot standby
capability with when running in Hot Standby mode, but I'm not clear
whether
On Wed, May 26, 2010 at 8:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
How does that get us out of reading and writing old pages, though?
Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
your problem, because they cannot become set
On Wed, May 26, 2010 at 8:25 PM, Florian Pflug f...@phlo.org wrote:
Unfortunately, this patch is untested. I couldn't get openjade + DocBook to
work on OSX for some reason :-(
That is a truly awful nightmare. Dave Page dug up some old
instructions which got me through it - I'm guessing he
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
alvherre alvhe...@commandprompt.com writes:
The problem with the = operator seems best resolved as not accepting
such an operator in a function parameter, which sucks but we don't seem
to have a choice.
Sucks is not the
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
your problem, because they cannot become set without having visited the
page.
Well, maybe I'm confused here,
On Wed, May 26, 2010 at 8:20 PM, Andrew Dunstan and...@dunslane.net wrote:
Gurjeet Singh wrote:
I did a `git clean -f -d` and even that did not remove gram.c, apparently
because this file _was_ alive at some point in the past hence git won't
remove it even though the current branch does not
I'm thinking about exporting the raw parser and related modules as a C
library. Though this will not be an immediate benefit of PostgreSQL
itself, it will be a huge benefit for any PostgreSQL
applications/middle ware those need to parse SQL statements.
For example, pgpool-II parses queries to
On 27/05/10 03:57, Robert Haas wrote:
Being compatible with the SQL
standard and with Oracle is not to be taken lightly.
I seem to be alone believing that the SQL standard doesn't say anything
about named function parameters. Can someone point me to the relevant
section of the standard?
As
On Wed, May 26, 2010 at 9:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 24, 2010 at 10:35 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, May 24, 2010 at 10:26 PM, Robert Haas robertmh...@gmail.com wrote:
This looks pretty reasonable to me, but I guess I feel like it would
On Wed, May 26, 2010 at 9:54 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, May 25, 2010 at 6:19 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, May 18, 2010 at 3:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
(2)
pg_ctl -ms stop emits the following warning whenever there is the
I think those works are essentially a refactoring of existing raw
parser, and will not add performance degration nor maintenance cost.
Comments?
You should call it libSQL; who knows, other DB projects might want it.
They seem to borrow our parser enough as it is.
--
* Tom Lane (t...@sss.pgh.pa.us) wrote:
There might be some value in psql backslash command tests that
are designed to depend on just one or a few tables (or other appropriate
objects).
Updated, much much smaller, patch attached. Also available, again, at
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator name. (And no, I'm not
for that.)
I suppose the most painful thing
On Wed, May 26, 2010 at 8:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Yeah. Neither PD_ALL_VISIBLE nor the visibility map are going to solve
your problem, because they cannot become set
On Wed, May 26, 2010 at 9:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, May 26, 2010 at 8:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we go with the spec's syntax I think we'd have no realistic choice
except to forbid = altogether as an operator
Tatsuo Ishii is...@postgresql.org writes:
I'm thinking about exporting the raw parser and related modules as a C
library. Though this will not be an immediate benefit of PostgreSQL
itself, it will be a huge benefit for any PostgreSQL
applications/middle ware those need to parse SQL statements.
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
OK ... I guess I was bothered because this has been referred to in a
public press release about the Beta. The PLPerl security stuff is
missing too, so I'll fix that also.
The security
Stephen, thanks for comments.
The attached three patches are the revised and divided ones.
A: add makeRangeTblEntry()
B: major reworks of DML permission checks
C: add an ESP hook on the DML permission checks
(2010/05/27 0:09), Stephen Frost wrote:
KaiGai,
* KaiGai Kohei
Tatsuo Ishii is...@postgresql.org wrote:
I'm thinking about exporting the raw parser and related modules as a C
library. Though this will not be an immediate benefit of PostgreSQL
itself, it will be a huge benefit for any PostgreSQL
applications/middle ware those need to parse SQL
On Wed, May 26, 2010 at 9:06 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, May 26, 2010 at 9:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Mon, May 24, 2010 at 10:35 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, May 24, 2010 at 10:26 PM, Robert Haas robertmh...@gmail.com
On 27/05/10 12:25, Florian Pflug wrote:
Patch that changes the wording to Explicitly releasing the newer savepoint with
RELEASE SAVEPOINT will cause ... is attached.
Unfortunately, this patch is untested. I couldn't get openjade + DocBook to
work on OSX for some reason :-(
FWIW docs
It knows that queries beginning with select or values are select
commands, but it seems not to be clued in about table and with.
For now, we can probably get by with just adding those to the list of
things it checks for. But I wonder what we'll do about this if we
ever get CTEs for
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Stephen, thanks for comments.
The attached three patches are the revised and divided ones.
A: add makeRangeTblEntry()
Ok, didn't actually expect that. Guess my suggestion would have been to
just use makeNode() since there wasn't
As was already discussed, I don't believe that premise. None of the
applications you cite would be able to make use of the raw parser
output, because it doesn't contain the semantic information they need.
If what you actually meant was the analyzed parse tree, that *might*
serve the need
* Robert Haas (robertmh...@gmail.com) wrote:
For now, we can probably get by with just adding those to the list of
things it checks for. But I wonder what we'll do about this if we
ever get CTEs for insert/update/delete statements... you'd have to
parse the whole darn thing to figure out
I wrote:
It strikes me that we could not only fix this case, but make the libpq
code simpler and more like the backend case, if we got rid of
client_cert_cb and instead preloaded the ~/.postgresql/postgresql.crt
file using SSL_CTX_use_certificate_chain_file().
Just for the archives: I've
I read your proposal says postgres.exe will link to libSQL.dll,
and pgpool.exe will also link to the DLL, right?
Perhaps.
I think it is reasonable, but I'm not sure what part of postgres
should be in the DLL. Obviously we should avoid code duplication
between the DLL and postgres.exe.
-
On Wed, May 26, 2010 at 10:20 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-05-26 at 18:52 +0900, Fujii Masao wrote:
I guess that dropping the support of #3 doesn't reduce complexity
since the code of #3 is almost the same as that of #2. Like
walreceiver sends the ACK after
Robert Haas robertmh...@gmail.com writes:
It knows that queries beginning with select or values are select
commands, but it seems not to be clued in about table and with.
What we really ought to do IMO is throw out the entire current
implementation of fetch_count. If libpq exposed access to
On Wed, May 26, 2010 at 10:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It knows that queries beginning with select or values are select
commands, but it seems not to be clued in about table and with.
What we really ought to do IMO is throw out the
On 27/05/10 10:21, Tom Lane wrote:
What will happen as things stand is that all the certs get loaded
into a common pool. That's not too horrible as long as there are
not actual conflicts, but it could mean that for example some
connections trust CA certs that the app programmer expected to
Tatsuo Ishii is...@sraoss.co.jp wrote:
The proposal will be acceptable only when all of the technical issues
are solved. The libSQL should also be available in stand-alone.
It should not be a collection of half-baked functions.
What do you mean by should also be available in
Craig Ringer cr...@postnewspapers.com.au writes:
On 27/05/10 10:21, Tom Lane wrote:
What will happen as things stand is that all the certs get loaded
into a common pool. That's not too horrible as long as there are
not actual conflicts, but it could mean that for example some
connections
Stephen,
The 'failure' may make an impression of generic errors not only permission
denied.
How about 'error_on_violation'?
Maybe 'ereport_on_violation'? I dunno, guess one isn't really better
than the other. You need to go back and fix the comment though- you
still say 'abort' there.
My stand-alone means libSQL can be used from many modules
without duplicated codes. For example, copy routines for raw
parse trees should be in the DLL rather than in postgres.exe.
Then, we need to consider other products than pgpool. Who will
use the dll? If pgpool is the only user, we
Hi,
Anyone working on make contrib/pg_trgm mutibyte encoding aware? If
not, I'm interested in the work.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Wed, May 26, 2010 at 03:47:25PM -0400, Robert Haas wrote:
On Tue, May 25, 2010 at 4:34 AM, Jonathan Leto jal...@gmail.com wrote:
This tiny doc patch adds _PG_init to the skeleton example code for a
PL. The information is quite valuable to PL authors, who might miss it
when it is
On 27/05/2010, at 02.48, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 26, 2010 at 8:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
How does that get us out of reading and writing old pages, though?
Yeah. Neither PD_ALL_VISIBLE nor the visibility
101 - 169 of 169 matches
Mail list logo
