The docs don't seem to contain any discussion I could find on why one
might not want hot_standby on. Maybe it's just too obvious to most
people, but this seems to be a bit lacking in the docs.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make change
(2010/06/04 13:57), Tom Lane wrote:
> KaiGai Kohei 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 a
Hi Florian,
Sure. I'll post my future questions either in pgsql-general or pgsql-admin.
> If some of those WAL segments still reside in pg_xlog, you'll either need
to teach your restore_command to fetch them from there. Note that you cannot
recover "in reverse".
My pg_xlog/ and walarchive/ dire
KaiGai Kohei 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 support variabl
Dan Colish 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 of shall be differ-
(2010/06/04 11:55), Robert Haas wrote:
> On Thu, Jun 3, 2010 at 1:23 PM, 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
Takahiro Itagaki 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 unused fields.
Here is my p
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 as
On Thu, Jun 3, 2010 at 8:47 PM, Jan Wieck 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 kn
On Thu, Jun 3, 2010 at 1:23 PM, 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
>> rel
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);
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
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 l
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
On Thu, Jun 3, 2010 at 6:29 PM, 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
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 as
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 stil
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 referen
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
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. -- Benjami
On 6/3/2010 5:58 PM, Greg Stark wrote:
On Thu, Jun 3, 2010 at 8:50 PM, Jan Wieck 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 t
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 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.
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
Simon Riggs 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 less, right now).
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 subscri
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
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
"Kevin Grittner" wrote:
> Greg Stark 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's very first post had it right
Florian Pflug 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* something to
Greg Stark 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 that seems reaso
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:
http://www.postgresql.org/mailpref/pgs
On Thu, Jun 3, 2010 at 8:50 PM, Jan Wieck 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 at all unles
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 th
gsst...@mit.edu (Greg Stark) writes:
> On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne 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."
>>
>
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
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
Heikki Linnakangas 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 cross-check.
On 03/06/10 23:17, Tom Lane wrote:
protocol.sgml says
START_REPLICATION XXX/XXX
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?
No, I believe t
protocol.sgml says
START_REPLICATION XXX/XXX
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, tom lane
--
Sent via p
Jan Wieck 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 case, it seems t
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
On 6/2/2010 7:49 PM, Greg Stark wrote:
On Wed, Jun 2, 2010 at 6:45 PM, Chris Browne 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."
versus
"
Greg Stark writes:
> On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane 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 kernel buffers fill up?
Well
On Thu, Jun 3, 2010 at 4:18 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane 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 t
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 "t
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
On Jun 3, 2010, at 19:00 , Tom Lane wrote:
> Heikki Linnakangas 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
On Thu, 2010-06-03 at 13:32 -0400, Tom Lane wrote:
> Simon Riggs 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
Simon Riggs 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 archive, you need t
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.
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
> d
On Thu, 2010-06-03 at 12:47 -0400, Tom Lane wrote:
> Simon Riggs 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 ut
Heikki Linnakangas 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: database system was interrup
Simon Riggs 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
> given in which to e
Simon Riggs 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 to start with.
On 03/06/10 19:16, Tom Lane wrote:
Heikki Linnakangas 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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Heikki Linnakangas 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 sure there aren't any.
The code wo
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 o
Tom Lane wrote:
> Bruce Momjian 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 fi
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 adde
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
Bruce Momjian 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 max_standby_delay.
Bruce Momjian 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 it's not onl
On Thu, Jun 3, 2010 at 3: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
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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)
> > o
On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian 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 (an
On Thu, Jun 3, 2010 at 4:34 PM, Tom Lane 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 far behind it's g
Tom Lane wrote:
> Bruce Momjian 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 outc
Greg Stark 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 disk? If it
>
On Thu, Jun 3, 2010 at 11:25 AM, Heikki Linnakangas
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, but I wonder whether
>> we sh
Bruce Momjian 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.
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 be
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
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 DE
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.
>
> Give
On Thu, Jun 3, 2010 at 12:11 AM, Tom Lane wrote:
> Greg Stark 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 assumption is wrong then
>> I'm off-
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 teste
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 imple
Bruce Momjian 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 or you wi
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
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.
>
Fujii Masao writes:
> On Thu, Jun 3, 2010 at 4:21 AM, Tom Lane wrote:
>> Heikki Linnakangas 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 returns you might well not
>>> be caught up anymore.
>>
>> It may have
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 mont
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.
>
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 g
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 que
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
On Thu, Jun 3, 2010 at 5:00 AM, Tom Lane 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 the DBA to
>
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 t
Hi!
I'm to face a problem, and not at once resolve it. When I do:
-- // --
test=# SELECT xpath('//domain:name/text()',
$$
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 subscri
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
y
On Thu, Jun 3, 2010 at 6:07 PM, Simon Riggs wrote:
> On Thu, 2010-06-03 at 17:56 +0900, Fujii Masao wrote:
>> On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas
>> wrote:
>> > I don't understand why you want to use a different delay when you're
>> > restoring from archive vs. when you're streamin
On Thu, Jun 3, 2010 at 4:21 AM, Tom Lane wrote:
> Heikki Linnakangas 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 transmission
>>> (because the main loop won't e
On Thu, 2010-06-03 at 17:56 +0900, Fujii Masao wrote:
> On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas
> 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
On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas
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 make a
> difference.
Yes. The p
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
>
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 join
1 - 100 of 103 matches
Mail list logo
