On ons, 2010-06-02 at 16:56 -0400, Robert Haas wrote:
But in the end the only purpose of setting it on a column is to set
which one will be used for operations on that column. And the user
might still override it for a particular query.
Of course. I'm just saying that it *can* be useful to
On Wed, 2010-06-02 at 16:00 -0400, Tom Lane wrote:
the current situation that query grace periods go to zero
Possibly a better way to handle this concern is to make the second
parameter: min_standby_grace_period - the minimum time a query will be
given in which to execute, even if
On 3 June 2010 02:06, Bruce Momjian br...@momjian.us wrote:
Also, foreign keys can't be defined that refer to a deferrable primary
key. That isn't mentioned at all in the manual with regard to the
DEFERRABLE clause, though it is mentioned in the FK section. You get
this error message
ERROR:
The attached patch is a proof of concept.
It tries to fix the problem of leaky VIEWs for RLS.
* The scenario of leaky VIEWs for RLS
-
When a view contains any table joins and user gives a function that
takes arguments depending on only one-side table of the
On Wed, 2010-06-02 at 21:06 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
Deferrable unique constraints seem an interesting feature, though I have
either some questions or some issues, not sure which.
I don't seem to be able to find any way to do an ALTER TABLE that adds
this new
On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I don't understand why you want to use a different delay when you're
restoring from archive vs. when you're streaming (what about existing WAL
files found in pg_xlog, BTW?). The source of WAL shouldn't
On Thu, 2010-06-03 at 17:56 +0900, Fujii Masao wrote:
On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I don't understand why you want to use a different delay when you're
restoring from archive vs. when you're streaming (what about existing WAL
On Thu, Jun 3, 2010 at 4:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 02/06/10 21:44, Tom Lane wrote:
In the current coding, the effect of not setting *caughtup here is just
that we uselessly call XLogSend an extra time for each
On Thu, Jun 3, 2010 at 6:07 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-06-03 at 17:56 +0900, Fujii Masao wrote:
On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I don't understand why you want to use a different delay when you're
So I think the scheme in the original post of this thread is workable.
Not as described but could be made to work. In which case I think it's
preferable to a freeze map -- which I had previously assumed we would
need eventually.
The problem with the scheme originally described is that it assumed
On Thu, 2010-06-03 at 18:39 +0900, Fujii Masao wrote:
What purpose would that serve?
Tom has already explained this and it makes sense for me.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hi!
I'm to face a problem, and not at once resolve it. When I do:
-- // --
test=# SELECT xpath('//domain:name/text()',
$$?xml version='1.0' encoding='UTF-8'?
Denis I. Polukarov wrote:
Hi!
I'm to face a problem, and not at once resolve it.
[default namespace mapped in xml xmlns= attribute requires
corresponding mapping in third param of xpath()]
It's a tolerably subtle point, and I'm not sure it's really
PostgreSQL-specific. But if you
On Thu, Jun 3, 2010 at 5:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I stand by my suggestion from yesterday: Let's define max_standby_delay
as the difference between a piece of WAL becoming available in the
standby, and applying it.
My proposal is essentially the same as yours plus allowing
Simon Riggs wrote:
On Wed, 2010-06-02 at 20:28 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
On Wed, 2010-06-02 at 15:20 -0400, Bruce Momjian wrote:
The attached patch allows wal_keep_segments = -1 to keep all segements;
this is particularly useful for taking a base backup,
On Jun 3, 2010, at 2:43 AM, Peter Eisentraut wrote:
On ons, 2010-06-02 at 16:56 -0400, Robert Haas wrote:
But in the end the only purpose of setting it on a column is to set
which one will be used for operations on that column. And the user
might still override it for a particular query.
On 03/06/10 15:15, Bruce Momjian wrote:
Simon Riggs wrote:
I think its much easier to find out your free disk space than it is to
calculate how much WAL might be generated during backup. Disk space
doesn't vary significantly on a production database.
If we encourage that laziness then we will
Heikki Linnakangas wrote:
On 03/06/10 15:15, Bruce Momjian wrote:
Simon Riggs wrote:
I think its much easier to find out your free disk space than it is to
calculate how much WAL might be generated during backup. Disk space
doesn't vary significantly on a production database.
If we
Hi,
My production server is running PostgreSQL v8.2.3 on CentOS release 5.2
(Final).
I've setup PITR in my production server. For some reason, after setting up
PITR, we're not able to manage and maintain it. Because of this our WAL
archive drive become full (100% use) approximately after 1
Fujii Masao masao.fu...@gmail.com writes:
On Thu, Jun 3, 2010 at 4:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
That's intentional. It could take some time for the WAL to be sent, if
the network is busy, so by the time XLogSend
Heikki Linnakangas wrote:
On 03/06/10 15:15, Bruce Momjian wrote:
Simon Riggs wrote:
I think its much easier to find out your free disk space than it is to
calculate how much WAL might be generated during backup. Disk space
doesn't vary significantly on a production database.
If we
Simon Riggs wrote:
On Wed, 2010-06-02 at 21:06 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
Deferrable unique constraints seem an interesting feature, though I have
either some questions or some issues, not sure which.
I don't seem to be able to find any way to do an ALTER
Bruce Momjian br...@momjian.us writes:
Heikki Linnakangas wrote:
Surely we don't expect DBAs to delete old files in pg_xlog? I agree with
Simon here, I think it would be better to not provide -1 as an option
here. At least you better document well that you should only do that
temporarily
On tor, 2010-06-03 at 07:30 -0500, David Christensen wrote:
How does collation relate to per-table/column encodings?
There is some connection between collations and character sets or
encodings, because a collation is tied to one of those, just as a
necessity of implementation (depending on
Because that's the consequences of fooling with pg_control.
I committed the PG_CONTROL_VERSION bump that was missing from
the patch Robert committed last night, but I wonder whether
we shouldn't revert the whole thing instead. It's not apparent
to me that what it bought is worth forcing beta
On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
I was assuming the walreceiver only requests more wal in relatively
small chunks and only when replay has caught up and needs more data. I
haven't actually read this code so if that
Peter Eisentraut wrote:
On m?n, 2010-05-31 at 18:23 -0400, Tom Lane wrote:
My feeling is that (a) there is no hurry to do anything about an
unreleased draft of the standard, and (b) perhaps Peter could lobby
the committee to change the standard before it does get published.
Given that
Hi,
I'll try to answer your questions below, but in the future please post
questions concerning the usage and administration of postgres to pgsql-general
or pgsql-admin. This list focus is the development of new features and bugfixes.
On Jun 3, 2010, at 15:37 , Gnanakumar wrote:
PITR SETUP
On 03/06/10 17:54, Tom Lane wrote:
Because that's the consequences of fooling with pg_control.
I committed the PG_CONTROL_VERSION bump that was missing from
the patch Robert committed last night, but I wonder whether
we shouldn't revert the whole thing instead. It's not apparent
to me that what
I wrote:
On further contemplation, it seems like the protocol needs another field
besides that: each record should also carry a boolean indicating whether
walsender.c thinks it is currently caught up, ie the record carries
all WAL data up to the current end of WAL.
Actually, there's a better
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't think breaking it (and probably other code)
on zero notice is an acceptable outcome.
On Thu, Jun 3, 2010 at 11:25 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 03/06/10 17:54, Tom Lane wrote:
Because that's the consequences of fooling with pg_control.
I committed the PG_CONTROL_VERSION bump that was missing from
the patch Robert committed last night,
Greg Stark gsst...@mit.edu writes:
Well, if the slave can't keep up, that's a separate problem. It will
not fail to keep up as a result of the transmission mechanism.
No, I mean if the slave is paused due to a conflict. Does it stop
reading data from the master or does it buffer it up on
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't think breaking it (and probably other code)
on zero notice is an
On Thu, Jun 3, 2010 at 4:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The data keeps coming in and getting dumped into the slave's pg_xlog.
walsender/walreceiver are not at all tied to the slave's application
of WAL. In principle we could have the code around max_standby_delay
notice just how
On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Are we sure we want hstore compatibility to drive this decision?
hstore is what it is, and has been that way for a long time. We can't
just ignore it. And I don't think breaking it (and probably other code)
On Thu, Jun 3, 2010 at 3:43 AM, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2010-06-02 at 16:56 -0400, Robert Haas wrote:
But in the end the only purpose of setting it on a column is to set
which one will be used for operations on that column. And the user
might still override it for a
Bruce Momjian br...@momjian.us writes:
Is telling hstore users they have to change = to something else such a
large major version incompatibility that it is worth supporting and
documenting two syntaxes for parameter assignment? It is that calculus
that has me questioning our approach.
Well
Bruce Momjian br...@momjian.us writes:
Thinking some more, what is the value of keeping = in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have to go fix
On Jun 3, 2010, at 8:54 AM, Tom Lane wrote:
Thinking some more, what is the value of keeping = in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have to go fix
On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote:
Now that it's pretty clear from Peter that the standard is not going to
change its choice here, I'll vote adding a WARNING each time an operator
called = is created, so that we get a chance to move later on.
Should support for == be added to
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Thinking some more, what is the value of keeping = in hstore for 9.0?
Backwards compatibility. You have not made any argument today that we
have not been over many times before. I do not have time to argue
about this today --- I have
David E. Wheeler wrote:
On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote:
Now that it's pretty clear from Peter that the standard is not going to
change its choice here, I'll vote adding a WARNING each time an operator
called = is created, so that we get a chance to move later on.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
If we moved the new DB_SHUTDOWNED_IN_RECOVERY as the last item in the
enum, we would stay backwards-compatible.
I don't think that's a terribly workable idea; the enum is laid out so
that inequality tests are sensible, and I'm not
The 9.0 release notes have been updated to current.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-hackers mailing list
On 03/06/10 19:16, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
If we moved the new DB_SHUTDOWNED_IN_RECOVERY as the last item in the
enum, we would stay backwards-compatible.
I don't think that's a terribly workable idea; the enum is laid out so
that
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2010-06-02 at 13:14 -0400, Tom Lane wrote:
This patch seems to me to be going in fundamentally the wrong direction.
It's adding complexity and overhead (far more than is needed), and it's
failing utterly to resolve the objections that I raised
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2010-06-02 at 16:00 -0400, Tom Lane wrote:
the current situation that query grace periods go to zero
Possibly a better way to handle this concern is to make the second
parameter: min_standby_grace_period - the minimum time a query will be
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 03/06/10 19:16, Tom Lane wrote:
What exactly was the reason for this patch? Could it be held over till
9.1?
Before the patch, when you shut down a standby server, you get this
message in the log on the next startup:
LOG:
On Thu, 2010-06-03 at 12:47 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Wed, 2010-06-02 at 13:14 -0400, Tom Lane wrote:
This patch seems to me to be going in fundamentally the wrong direction.
It's adding complexity and overhead (far more than is needed), and it's
On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
[ . . . ]
In my current idea, when a qual-node that contains FuncExpr tries to
reference a part of relations within a security view, its referencing
relations will be expanded to whole of the security view at
On 06/03/2010 09:34 AM, Bruce Momjian wrote:
The 9.0 release notes have been updated to current.
OK. I'll be doing editing for readability starting on Monday.
--
-- Josh Berkus
PostgreSQL Experts Inc.
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-06-03 at 12:47 -0400, Tom Lane wrote:
But in any case the current behavior is
still quite broken as regards reading stale timestamps from WAL.
Agreed. That wasn't the objective of this patch or a priority.
If you're reading from an
On Thu, 2010-06-03 at 13:32 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-06-03 at 12:47 -0400, Tom Lane wrote:
But in any case the current behavior is
still quite broken as regards reading stale timestamps from WAL.
Agreed. That wasn't the objective of
On Jun 3, 2010, at 19:00 , Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 03/06/10 19:16, Tom Lane wrote:
What exactly was the reason for this patch? Could it be held over till
9.1?
Before the patch, when you shut down a standby server, you get this
Excerpts from Bruce Momjian's message of jue jun 03 08:36:28 -0400 2010:
Using this only temporarily is mentioned in the doc patch. Do I need
more?
Yeah, it's far too easy to miss. Besides, I think the wording you used
is ambiguous -- it can be read as the server will temporarily keep all
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of jue jun 03 08:36:28 -0400 2010:
Using this only temporarily is mentioned in the doc patch. Do I need
more?
Yeah, it's far too easy to miss. Besides, I think the wording you used
is ambiguous -- it can be read as the server
On Thu, Jun 3, 2010 at 4:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It is off-base. The receiver does not request data, the sender is
what determines how much WAL is sent when.
Hm, so what
Greg Stark gsst...@mit.edu writes:
On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It is off-base. The receiver does not request data, the sender is
what determines how much WAL is sent when.
Hm, so what happens if the slave blocks, doesn't the sender block when
the
On 6/2/2010 7:49 PM, Greg Stark wrote:
On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne cbbro...@acm.org wrote:
It would make it easy to conclude:
This next transaction did 8328194 updates. Maybe we should do
some kind of checkpoint (e.g. - commit transaction or such) before
working on it.
Jan Wieck wrote:
The point is not that we don't have that information now. The point is
having a hint BEFORE wading through possibly gigabytes of WAL or log data.
If getting that information requires to read all the log data twice or
the need to read gigabytes of otherwise useless WAL data
Jan Wieck janwi...@yahoo.com wrote:
I actually have a hard time understanding why people are so
opposed to a feature that has zero impact at all unless a DBA
actually turns in ON. What is the problem with exposing the
commit order of transactions?
FWIW, once I came to understand the use
protocol.sgml says
termSTART_REPLICATION XXX/XXX/term
listitem
para
Instructs backend to start streaming WAL, starting at point XXX/XXX.
Am I correct in thinking that this is wrong, and streaming actually
starts with the byte after XXX/XXX?
regards,
On 03/06/10 23:17, Tom Lane wrote:
protocol.sgml says
termSTART_REPLICATION XXX/XXX/term
listitem
para
Instructs backend to start streaming WAL, starting at point XXX/XXX.
Am I correct in thinking that this is wrong, and streaming actually
starts with the byte after
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 03/06/10 23:17, Tom Lane wrote:
Am I correct in thinking that this is wrong, and streaming actually
starts with the byte after XXX/XXX?
No, I believe the documentation is correct.
OK, I read the code again. Thanks for the
On 6/3/2010 4:04 PM, Bruce Momjian wrote:
If you want to fork Postgres and add it, go ahead, but if the community
has to maintain the code and document it, we care.
That comment was rather unprofessional. I think the rest of us still try
to find the best solution for the problem, not kill the
br...@momjian.us (Bruce Momjian) writes:
Jan Wieck wrote:
The point is not that we don't have that information now. The point is
having a hint BEFORE wading through possibly gigabytes of WAL or log data.
If getting that information requires to read all the log data twice or
the need to
gsst...@mit.edu (Greg Stark) writes:
On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne cbbro...@acm.org wrote:
It would make it easy to conclude:
This next transaction did 8328194 updates. Maybe we should do
some kind of checkpoint (e.g. - commit transaction or such) before
working on it.
Heikki Linnakangas wrote:
We leave that up to the DBA to clean out one way or another. We
provide restartpoint_command and the %r option in restore_command to
help with that.
I was in fact just looking into this, and I see that there is no example
restartpoint_comand script given in
On Thu, Jun 3, 2010 at 8:50 PM, Jan Wieck janwi...@yahoo.com wrote:
I'm puzzled how you would define this value. How do you add 7 inserts,
7 deletes, and 7 updates? Is that 21 rows modified?
I actually have a hard time understanding why people are so opposed to a
feature that has zero impact
I see what went wrong in my example. Unique constraints must have unique names
since they create an index. I'll try again, sorry for the noise.
--Dan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Greg Stark gsst...@mit.edu wrote:
what kind of interface you need
For the potential uses I can see, it would be great to have a SRF
which took two parameters: xid of last known commit and a limit how
many commits past that to return. Perhaps a negative number could
move earlier in time, if
Florian Pflug f...@phlo.org writes:
On Jun 3, 2010, at 19:00 , Tom Lane wrote:
Maybe we should just get rid of the hint.
FYI, Robert Haas suggested the same in the thread that lead to this patch
being applied. The arguments against doing that is that a real crash during
recovery *is*
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Greg Stark gsst...@mit.edu wrote:
what kind of interface you need
For the potential uses I can see, it would be great to have a SRF
which took two parameters: xid of last known commit and a limit
how many commits past that to return.
Jan Wieck wrote:
On 6/3/2010 4:04 PM, Bruce Momjian wrote:
If you want to fork Postgres and add it, go ahead, but if the community
has to maintain the code and document it, we care.
That comment was rather unprofessional. I think the rest of us still try
to find the best solution for the
Bruce Momjian wrote:
Jan Wieck wrote:
On 6/3/2010 4:04 PM, Bruce Momjian wrote:
If you want to fork Postgres and add it, go ahead, but if the community
has to maintain the code and document it, we care.
That comment was rather unprofessional. I think the rest of us still try
to
On Thu, 2010-06-03 at 18:18 +0100, Simon Riggs wrote:
Are you planning to work on these things now as you said?
Are you? Or do you want me to?
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-06-03 at 18:18 +0100, Simon Riggs wrote:
Are you planning to work on these things now as you said?
Are you? Or do you want me to?
I decided there wasn't time to get anything useful done on it before the
beta2 deadline (which is, more or
Excerpts from Chris Browne's message of jue jun 03 16:21:35 -0400 2010:
What this offers is *SOME* idea of how much updating work a particular
transaction did. It's a bit worse than you suggest:
- If replication triggers have captured tuples, those would get
counted.
- TOAST
On 06/03/2010 10:27 AM, Josh Berkus wrote:
On 06/03/2010 09:34 AM, Bruce Momjian wrote:
The 9.0 release notes have been updated to current.
OK. I'll be doing editing for readability starting on Monday.
Actually, the section tags appear to be broken in release-9.0.sgml in
the current cvs.
I wanted to work on this todo item and I have a few questions about the
semantics of it. Essentially, it is not possible to have more than one relname
for a constraint, even though the comment in trigger.c says otherwise. I have
used this code to test this:
CREATE TABLE products (
On 6/3/2010 5:58 PM, Greg Stark wrote:
On Thu, Jun 3, 2010 at 8:50 PM, Jan Wieck janwi...@yahoo.com wrote:
I'm puzzled how you would define this value. How do you add 7 inserts,
7 deletes, and 7 updates? Is that 21 rows modified?
I actually have a hard time understanding why people are so
On 6/3/2010 6:24 PM, Kevin Grittner wrote:
Apologies for not looking back to the start of the thread before
that last post. It was all laid out right at the start.
No need to apologize. Happens.
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. --
On 6/3/2010 7:11 PM, Alvaro Herrera wrote:
Excerpts from Chris Browne's message of jue jun 03 16:21:35 -0400 2010:
What this offers is *SOME* idea of how much updating work a particular
transaction did. It's a bit worse than you suggest:
- If replication triggers have captured tuples, those
I fixed up the subject.
(2010/06/04 2:23), Marc Munro wrote:
On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
[ . . . ]
In my current idea, when a qual-node that contains FuncExpr tries to
reference a part of relations within a security view, its referencing
Ther is an open item:
Standby instead of slave in documentation
http://archives.postgresql.org/message-id/1273682033.12754.1.ca...@vanquo.pezone.net
I replacesd almost all slave to standby or standby servers
not only in HS+SR but also in other places like third-party tools.
There are still 3
On 5/27/2010 4:31 PM, Bruce Momjian wrote:
Heikki Linnakangas wrote:
BTW, I think we're going to need a separate config file for listing the
standbys anyway. There you can write per-server rules and options, but
explicitly knowing about all the standbys also allows the master to
recycle WAL
On Thu, Jun 3, 2010 at 6:29 PM, Bruce Momjian br...@momjian.us wrote:
Jan Wieck wrote:
On 6/3/2010 4:04 PM, Bruce Momjian wrote:
If you want to fork Postgres and add it, go ahead, but if the community
has to maintain the code and document it, we care.
That comment was rather
Bruce Momjian wrote:
I care about cleaning up more of the mistakes, made in the original
development of Slony. Namely using hacks and kluges to implement
details, not supported by a current version of PostgreSQL. Londiste and
Slony made a good leap on that with the txid data type. Slony
I summarized the series of discussion at:
http://wiki.postgresql.org/wiki/RLS#Issue:_A_leaky_VIEWs_for_RLS
Please point out, if I missed or misunderstood something.
Thanks,
(2010/06/03 11:36), KaiGai Kohei wrote:
(2010/06/02 12:02), KaiGai Kohei wrote:
Here's another thought. If we're
Josh Berkus wrote:
On 06/03/2010 10:27 AM, Josh Berkus wrote:
On 06/03/2010 09:34 AM, Bruce Momjian wrote:
The 9.0 release notes have been updated to current.
OK. I'll be doing editing for readability starting on Monday.
Actually, the section tags appear to be broken in
On 5/27/2010 11:52 PM, Andrew Dunstan wrote:
Bruce Momjian wrote:
Peter Eisentraut wrote:
On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote:
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);
On Thu, Jun 3, 2010 at 1:23 PM, Marc Munro m...@bloodnok.com wrote:
On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
[ . . . ]
In my current idea, when a qual-node that contains FuncExpr tries to
reference a part of relations within a security view, its
On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck janwi...@yahoo.com wrote:
On 5/27/2010 4:31 PM, Bruce Momjian wrote:
Heikki Linnakangas wrote:
BTW, I think we're going to need a separate config file for listing the
standbys anyway. There you can write per-server rules and options, but
explicitly
Jan Wieck wrote:
That is a sad wart that we should never have done, IMNSHO (it was
before my time or I would have objected ;-) ). But beyond that, = is
an operator in SQL and := is never an operator, IIRC.
As far as I can tell, this was already in the code when Bruce moved it
into core
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote:
Could you explain why default_only entries idea is
better than adjusting those fields in the toast-specific codes?
It's my understanding that reloption-framework is just a tool to fill
reloption parameters, and it's not responsible for
(2010/06/04 11:55), Robert Haas wrote:
On Thu, Jun 3, 2010 at 1:23 PM, Marc Munrom...@bloodnok.com wrote:
On Thu, 2010-06-03 at 05:53 -0300, pgsql-hackers-ow...@postgresql.org
wrote:
[ . . . ]
In my current idea, when a qual-node that contains FuncExpr tries to
reference a part of
Dan Colish dcol...@gmail.com writes:
I wanted to work on this todo item and I have a few questions about
the semantics of it. Essentially, it is not possible to have more than
one relname for a constraint,
That is per SQL spec: SQL92 10.6 syntax rule 2 saith
2) The qualified
KaiGai Kohei kai...@ak.jp.nec.com writes:
(2010/06/04 11:55), Robert Haas wrote:
A (very) important part of this problem is determining which quals are
safe to push down.
At least, I don't have an idea to distinguish trusted functions from
others without any additional hints, because we
1 - 100 of 102 matches
Mail list logo
