Hi!
On 01/03/11 22:24, Tom Lane wrote:
I wonder whether you're failing to copy the backup_label file as part of
the base backup. The presence of that file is what tells the slave
postmaster where it has to start recovering from.
regards, tom lane
Thank you so much
Imre Oolberg wrote:
> I am starting to think more in the direction what Kevin Grittner
> suggested that i miss something in my procedure and instead
> following so to say recovery path i am doing something else which
> strangely ends up with working database process but actually
> misses some d
Imre Oolberg writes:
> First of all, thanks for your time dealing with my situation. I must
> stress that i have wal arhived starting from before issuing
> pg_start_backup, wal archives generated before pg_start/stop_backup and
> also some wal archive files generated after pg_stop_backup (and
Hi!
On 01/03/11 20:56, Tom Lane wrote:
Scott Ribe writes:
Unless I misread his earlier post, he is starting the backup, copying files, stopping
the backup, and expecting those transactions (between start& stop) to be applied,
even though files changed during that time (including WAL fil
Scott Ribe writes:
> Unless I misread his earlier post, he is starting the backup, copying files,
> stopping the backup, and expecting those transactions (between start & stop)
> to be applied, even though files changed during that time (including WAL
> files) have not all been copied. Again, u
On Jan 3, 2011, at 11:42 AM, Tom Lane wrote:
> That's either incorrect or poorly worded.
Let's go with poorly worded then. (Actually I don't do this, I use streaming
replication, where I don't have to copy the WAL files because the standby picks
up the ones that are needed.)
Unless I misread h
Scott Ribe writes:
> On Jan 3, 2011, at 11:22 AM, Imre Oolberg wrote:
>> But http://www.postgresql.org/docs/9.0/interactive/continuous-archiving.html
>> suggests to use tar on rsync and i guess that PostgreSQL recovery with wal
>> files takes care of these inconsistencies that are created during
Scott Ribe wrote:
> Yes, but the database is recovered to the consistent state as of
> the pg_start_backup command, as I pointed out to you before.
> Results of transactions that commit after the pg_start_backup
> command will not be in the backed up database.
I doubt you. The transactions be
On 01/03/11 19:36, Kevin Grittner wrote:
Imre Oolberg wrote:
archive_command = 'test ! -f
/data/backup/postgresql/archive-logs/%f&&
cp %p /data/backup/postgresql/archive-logs'
I suppose that will work, but why not specify %f in the copy target?
Yep, that works as it is since w
On Jan 3, 2011, at 11:22 AM, Imre Oolberg wrote:
> But http://www.postgresql.org/docs/9.0/interactive/continuous-archiving.html
> suggests to use tar on rsync and i guess that PostgreSQL recovery with wal
> files takes care of these inconsistencies that are created during copying
> filesystem,
Hi!
Thanks for the answer.
On 01/03/11 18:36, pasman pasmański wrote:
The problem exists when you do a base backup with pg_backup?
Maybe rsync skip some data ?
Yes, problem exists using pg_start/stop_backup as i discribed.
I am sure that 'rsync -avH ...' and 'tar cvf ...' will skip at l
Imre Oolberg wrote:
> archive_command = 'test ! -f
> /data/backup/postgresql/archive-logs/%f &&
> cp %p /data/backup/postgresql/archive-logs'
I suppose that will work, but why not specify %f in the copy target?
> I guess that my problem is probably that although my .backup file
> says
>
>
On Sun, Jan 2, 2011 at 10:55 PM, kirancnair wrote:
>
> Hi,
>
> I get this error when I try to call a function from an Insert Trigger set on
> one of my tables in the SNE GP Edition:
>
...
> What can be the cause of this? Triggers + functions are working perfectly
> fine with another table in the s
kirancnair wrote:
> segDBs
The community version of PostgreSQL does not have segDBs. You
should probably contact Greenplum.
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Hi,
I get this error when I try to call a function from an Insert Trigger set on
one of my tables in the SNE GP Edition:
ERROR: Functions that execute SQL statements from the segDBs are not yet
supported (spi.c:203) (seg0 localhost:50001 pid=5504)
DETAIL:
SQL statement "SELECT DISTINCT min
The problem exists when you do a base backup with pg_backup?
Maybe rsync skip some data ?
pasman
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Hello,
Original-Nachricht
> Datum: Mon, 03 Jan 2011 11:05:30 -0500
> Von: Tom Lane
> An: "Jan-Peter Seifert"
> CC: pgsql-admin@postgresql.org
> Betreff: Re: [ADMIN] Obscure problem due to high system OID or privileges?
> "Jan-Peter Seifert" writes:
> > During 'start up' the a
"Jan-Peter Seifert" writes:
> During 'start up' the application does a couple of SELECTs on pg_catalog:
> SELECT COUNT(*) FROM pg_attribute JOIN pg_type ON
> pg_attribute.atttypid=pg_type.oid LEFT OUTER JOIN pg_attrdef ON (
> pg_attribute.attnum=pg_attrdef.adnum AND
> pg_attribute.attrelid=
Hello,
we have a strange problem with a server instance:
PostgreSQL 8.2.11 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.3 20070929
(prerelease) (Ubuntu 4.1.2-16ubuntu2)
It's one of several clones (server/system) where one of our applications cannot
work with a specific database restored
sharilalipv wrote:
> How can we find hanging query in postgresql?
If this doesn't answer your question:
http://wiki.postgresql.org/wiki/Lock_Monitoring
then please read this page and re-post:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-admin
Hi and Happy New Year!
Unfortunately i still have the same problem, in the mean time i tried
out with different versions and still get same results. Experimenting on
Debian Lenny v 5.0 with v. compiled v. 9.0.2 where default conf is
changed only in this
wal_level = archive
archive_mode = on
21 matches
Mail list logo
