Oh sorry, I missed something. I turned off the XLOG archive in code after
pg_start_backup so the pg_xlog directory contains all the xlog files.
And for performance purpose, I change the checkpoint type in pg_start_backup to
CHECKPOINT_IMMEDIATE, does it matter?
The PG log I mentioned above is th
On Wed, Aug 4, 2010 at 10:38 PM, Heikki Linnakangas
wrote:
> Then you risk running out of disk space. Similar to having an archive
> command that fails for some reason.
>
> That's one reason the registration should not be too automatic - there is
> serious repercussions if the standby just disappe
On Thu, Aug 05, 2010 at 04:58:32PM +0300, Peter Eisentraut wrote:
> pg_stat_user_functions has an inconsistent notion of what "user" is.
> Whereas the other pg_stat_user_* views filter out non-user objects
> by schema, pg_stat_user_functions checks for language "internal",
> which does not successf
Thanks for replying.
But I could not find any relation between the RequestXLogSwitch function and
the error I met.
For perfromance purpose , I change the pg_start_backup checkpoint type from
CHECKPOINT_WAIT to CHECKPOINT_IMMEDIATE, does it matter?
--
On Thu, Aug 5, 2010 at 9:59 AM, Tom Lane wrote:
> Well, if it were only a hint, and thus didn't actually "prevent"
> anything, then it wouldn't be breaking compatibility. But I don't
> like the idea much either. It would be extremely expensive, if not
> impossible, to determine whether all paren
On Fri, Jul 30, 2010 at 7:02 AM, Jan Urbański wrote:
> On 24/07/10 15:20, Adriano Lange wrote:
>>
>> Hi,
>
> Hi!
>
>>
>> I'd like to release the last version of my experimental join order
>> algorithm (TwoPO - Two Phase Optimization [1]):
>>
>> http://git.c3sl.ufpr.br/gitweb?p=lbd/ljqo.git;a=summa
On Thu, Aug 5, 2010 at 9:50 AM, Richard wrote:
> I reboot PG because I found PG recovery end point if far away from the
> actual end point of the XLOG on the backup directory, so I want to test if
> the original DB is OK.
> Unfortunately, I got the same PG log on the original DB. I don't unsta
"Richard" writes:
> PS : I am using PG 8.3.7
I believe there's a related bug fix in 8.3.8.
BTW, -hackers is not the place for this type of question.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
Robert Haas writes:
> Yeb Havinga writes:
>> The root cause seems to center around multiple inheritance of the same
>> column without a common ancestor. Another way to approach the problem, is to
>> prevent the user to create a setup, i.e. when adding a column to B that
>> already exists in A, or
pg_stat_user_functions has an inconsistent notion of what "user" is.
Whereas the other pg_stat_user_* views filter out non-user objects by
schema, pg_stat_user_functions checks for language "internal", which
does not successfully exclude builtin functions of language SQL. Is
there a reason for thi
On Thu, Aug 5, 2010 at 7:25 PM, Simon Riggs wrote:
> On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> > On 05/08/10 10:46, Simon Riggs wrote:
> > > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> > >> The following two files specify the behaviour of the MERGE statement
> and
I reboot PG because I found PG recovery end point if far away from the actual
end point of the XLOG on the backup directory, so I want to test if the
original DB is OK.
Unfortunately, I got the same PG log on the original DB. I don't unstand what
you said, I missing what?
---
Michael Meskes wrote:
> All prior ECPG versions were fine because dynamic cursor names
> were only added in 9.0. Apparently only this one place was
> missed. So this is a bug in the new feature, however not such a
> major one that it warrants the complete removal IMO. I'd prefer to
> fix this in
On 08/05/2010 09:19 AM, Richard wrote:
I want to create a database backup when PG is running, so I call
pg_start_backup(''), scp the data to a backup directory, pg_stop_backup.
Then I reboot PG , PG boot failed with log like "unexpected pageaddr X/X in log file X,
segment X, offset X" "WAL e
PS : I am using PG 8.3.7
--
Richard
2010-08-05
-
发件人：Richard
发送日期：2010-08-05 21:19:27
收件人：pgsql-hackers
抄送：
主题：Online backup cause boot failure, anyone know why?
I want to create a database
I want to create a database backup when PG is running, so I call
pg_start_backup(''), scp the data to a backup directory, pg_stop_backup.
Then I reboot PG , PG boot failed with log like "unexpected pageaddr X/X in log
file X, segment X, offset X" "WAL ends before end time of backup dump".
Then
On Thu, Aug 5, 2010 at 6:15 AM, Yeb Havinga wrote:
> Tom Lane wrote:
>>
>> Yeb Havinga writes:
>>
>>>
>>> A.a_column B.a_column
>>> | /
>>> v v
>>> C.a_column
>>> C inherits from A and B.
>>>
>>
>> Well, if A and B inherited the column from a common ancestor, he can
>>
On Thu, 2010-08-05 at 12:29 +0300, Heikki Linnakangas wrote:
> On 05/08/10 10:46, Simon Riggs wrote:
> > On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> >> The following two files specify the behaviour of the MERGE statement and
> >> how it will work in the world of PostgreSQL.
> >
> >> The
On Wed, Aug 4, 2010 at 12:35 AM, Heikki Linnakangas
wrote:
> There's some race conditions with the signaling. If another process finishes
> XLOG flush and sends the signal when a walsender has just finished one
> iteration of its main loop, walsender will reset xlogsend_requested and go
> to sleep
On Wed, Aug 4, 2010 at 10:00 PM, Robert Haas wrote:
> On Tue, Aug 3, 2010 at 1:50 PM, Kolb, Harald (NSN - DE/Munich)
> wrote:
>> Or is "fsync" still not supported ?
>
> Wouldn't you need to have it set to "apply" to get the behavior you want here?
Yes. In that case, replication_mode needs to be
Tom Lane wrote:
Yeb Havinga writes:
A.a_columnB.a_column
| /
v v
C.a_column
C inherits from A and B.
Well, if A and B inherited the column from a common ancestor, he can
easily do that. If not, maybe he should have thought harder before he
started.
On 05/08/10 05:08, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but uncommitted
changes or other funny things. I can live with that g
On 04/08/10 16:50, Andrew Dunstan wrote:
On 08/04/2010 09:29 AM, Heikki Linnakangas wrote:
All those issues can be avoided if you only run "git gc" when all the
working directories are in a clean state, with no staged but
uncommitted changes or other funny things. I can live with that gun
tied
On 05/08/10 10:46, Simon Riggs wrote:
On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
The following two files specify the behaviour of the MERGE statement and
how it will work in the world of PostgreSQL.
The HTML file was generated from SGML source, though the latter is not
included her
On Mon, 2008-04-21 at 21:08 +0100, Simon Riggs wrote:
> The following two files specify the behaviour of the MERGE statement and
> how it will work in the world of PostgreSQL.
> The HTML file was generated from SGML source, though the latter is not
> included here for clarity.
Enclose merge.sgml
101 - 125 of 125 matches
Mail list logo
