esn't matter
much.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
.
I can't find any mention of serializability concerns in the RI code itself.
AFAIK it would be strange to exclude FK checks from serializability checks,
since they represent a valid observation of an intermediate state.
Mat Views are excluded but I don't understand why that should be the ca
On 29 June 2015 at 21:13, Kevin Grittner wrote:
> Simon Riggs wrote:
> > On 17 June 2015 at 13:52, Kevin Grittner wrote:
> >> Filipe Pina wrote:
>
> >>> if drop the foreign key constraint on stuff_ext table there are
> >>> no failures at all…
e that only parts of the table are there.
> Wouldn't it be much more safe to raise an error as soon as the table is
> touched?
>
How would we know that an external agent had deleted the file? What action
should we take if we did notice?
It's a very good thing that we remain flying eve
ion.
>
> If it didn’t make 9.6 core, is there plan to include it in 9.7, or may be
> pglogical becomes available on Windows?
>
>
Currently pglogical does not support Windows.
It's free software, so funding for any new features or requirements is
always welcome.
--
Simon R
em could be fixed by using
> hot_standby_feedback. I have encountered similar problem but it seems
> hot_standby_feedback was not any help in this case:
>
> https://www.postgresql.org/message-id/20130829.164457.863984798767991096.t-ishii%40sraoss.co.jp
There have been various bugs and enhancement
he truncation logic always kicks in or small tables of less than
16 blocks. It's more forgiving on bigger tables.
Maybe we could defer the truncation on the standby in some cases.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
ent design will be submitted for the next release, 10.0.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
cal replication will be in 10.0.
Yes, 10.0 is the next release, due 2017.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make
e CRC checked, so it may just be a bug, not corruption that
affects multiple servers.
At the moment we know the Startup process died, but we don't know why.
Do you repeatedly get this error?
Please set log_error_verbosity = VERBOSE and rerun
--
Simon Riggshttp://www
On 25 August 2016 at 09:50, Russell Keane wrote:
> We’re fairly convinced the issue lies with the actual storage but I was
> wondering if there is anything within PG that would be affected by the high
> latency and result in corrupt indexes.
Nothing we know of, at this time.
--
Si
tation is required.
Anybody can come here and discuss new features. Anybody. They just
need to explain their thoughts and produce evidence for their
assertions.
Come on in, database researchers, we're open to rational contributions.
--
Simon Riggshttp://www.2ndQuadrant.com/
and pull
> requests are welcome too!
Very good. Oleg had mentioned that dictionary compression was being considered.
It would be useful to be able to define compression dictionaries for
many use cases.
Will you be submitting this to core?
--
Simon Riggshttp://www.2ndQuadrant.co
modifier, e.g. ZSON(357)
That way we can use this for TEXT, XML, JSON etc.. as ZTEXT, ZXML, ZJSON
So it seems like a generally useful thing to me.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via
's a big issue.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
t at a random block and a
random item between min and max?
It wasn't ever intended to be biased and bernoulli in particular ought
to have a strict no bias.
Happy to patch if we agree.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, T
On 18 October 2016 at 22:06, Tom Lane wrote:
> Simon Riggs writes:
>> On 18 October 2016 at 19:34, Tom Lane wrote:
>>> If you don't want to have an implicit bias towards earlier blocks,
>>> I don't think that either standard tablesample method is really w
* Physical streaming replication, built-in from 9.0+
* Logical streaming replication, partially built in from 9.4+ using pglogical
and
* Logical streaming replication, built in from 10.0+ (not yet released)
Performance is much better than rubyrep
--
Simon Riggshttp://www.2ndQua
ther big (500M+ records) with
>> 5-7 indexes. Sometimes it takes us 20 hours+ to get table vacuumed and
>> all progress reporting we have for stage 3 is that it is stage 3.
>
> Yes, things could be improved here.
Yes, it seems that VACUUM progress reporting feature is only about
you name tables and columns, keep it generic.
You'll get a precise measurement of whether it works for you. And the
project will get a representative test case that we can understand and
tune for. And if everyone does that we'll get a set of use cases that
will help demonstrate our per
g about this because there is clearly some confusion around
this.
In official docs very small information about how to configure servers.
>
> Could anyone direct me in right way?
>
If anyone would like to contribute better documentation, they are very
welcome to do so.
--
Simon Riggs
wanted and didn't want
to see in the final product. I think those choices were good ones.
Design your applications carefully, understanding the trade-offs between
availability, local access times, serializability and performance.
--
Simon Riggshttp://www.2ndQuadrant.com/
<h
able in 9.6.
>
BDR 9.4 is currently at v0.9.3. There isn't a BDR 9.5, since we
concentrated on pglogical.
pglogical works with 9.4 and 9.5 and is currently at v1.0
Future detailed planning for BDR and pglogical is happening now; there
definitely will be future versions with increasing PostgreSQL co
ve point 3 entirely. Point 2 is sufficient to limit what
is said.
Who will decide how this code is enacted? Rules imply rulers, so what is
the constitution of the governing body?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 20 January 2016 at 19:05, Kevin Grittner wrote:
> On Wed, Jan 20, 2016 at 12:47 PM, Simon Riggs
> wrote:
> > On 18 January 2016 at 18:02, Joshua D. Drake
> wrote:
>
> >> * We are tolerant of people’s right to have opposing views.
> >>
> >> * Par
t of the doubt.
>
> * When interpreting the words and actions of others, participants
> should always consider the possibility of misunderstandings.
>
+1
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
amp() as ctimestamp
> FROM generate_series(1,1000) as id
> )
> SELECT
> *
> FROM
> (SELECT
> id,
> ctimestamp,
> row_number() OVER (ORDER BY ctimestamp) as rownum
> FROM data_cte
> ) as data_withrownumbers
> WHERE
>
and search binary
> documents, e.g. pdf ?
>
> Ah, no. That's not possible
...not possible, Yet.
PostgreSQL grows by adding the features people need and its changing
rapidly.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi Konstantin,
Is this open source with The PostgreSQL Licence?
Will you be contributing those changes to the BDR project, or is this a
permanent fork of that?
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x
On 10 April 2016 at 22:48, Dorian Hoxha wrote:
> Postgres-XL has no highavailibility
>
Postgres-XL 9.5 has had lots of additional work put in, HA being one of
those areas.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Devel
tch as
select '0123456789ABCDE' from generate_series(1,100);
drop table xlog_switch;
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archiv
anything crashed on your server?
Are you using GIN or GIST indexes?
I'll look at putting some debug information in there that logs whether
multi-WAL actions remain unresolved for any length of time.
Continuing to think about this one
--
Simon Riggs
EnterpriseDB http:/
On Fri, 2007-06-01 at 13:33 +0200, Frank Wittig wrote:
> Simon Riggs schrieb:
>
> > This is repeatable, yes?
> Yes, it occures every time I begin with a new base backup. And it seem
> to happen during recreation of tsearch2 vectors of large amounts of data
> sets.
>
>
I have some ideas if its (2).
The attached patch should show which of these it is. I'll dress it up a
little better so we have a debug option on this. Please note I've not
tested this patch myself, so Frank if you don't mind me splatting
something at you we'll see what we see
ential for not being able to track this is
high. I'd want to throw errors in those locations also.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/gin/ginxlog.c
===
RCS file
ome administrative
difficulty if the *standby* server fails. We're working on a fix.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archive
oduce the problem - it leaves
> incompleted
> splits. But I discover one more problem: deadlock on buffer's lock. So, right
> now I investigate the problem.
OK, I'll leave the code to you from here
--
Simon Riggs
EnterpriseDB http://www.enterp
7;m going away for weekend, so I'll not be online until Monday.
OK, I'll check the other AMs to see if we have similar problems.
Have a good weekend.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)-
splits cause a problem.
The new RHS block numbers are consecutive from 111780+
2. The incomplete splits stay around indefinitely after creation and we
aren't trying to remove the wrong split at any point. We're either never
creating an xlog record, or we are ignoring it in r
t didn't work for you. Even if this doesn't effect you, it might
effect others, so I want to be certain to stamp this out before the fire
spreads.
You can still do the lock file test using a safe method. I'll document
that idea so we can steer people in the right direction.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
t; failover on failure detection (via heartbeat2), and be synchronous.
Do you have any performance measurements of either the replication
overhead or the failover time? I'm interested in how well we cope with
high transaction rates. Thanks.
--
Simon Riggs
Enter
ill give you the FATAL
error message "WAL ends before end time of backup dump". You won't know
this until you have attempted recovery using those files, even if the
scripts give rc=0.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
-
id with drive write caches
> supposedly disabled. Should I expect to see such lines anyway after a
> sudden power loss?
Yes.
"Unexpected pageaddr" is just one of the ways that recovery can detect
the end of the log, since there isn't ever an "end of log" mar
files
No, it won't, so I'm not sure what Josh means.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
8.3 for the restore_command to be passed a %r
parameter so you don't need to grovel in the control file.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Mon, 2007-06-18 at 12:35 +0300, Sabin Coanda wrote:
> Is somewhere a system table providing statistic counters of CRUD operations
> against custom databases ?
pg_stat_user_tables
http://www.postgresql.org/docs/8.2/static/monitoring-stats.html#MONITORING-STATS-VIEWS
--
Simon
d a server patch is in the
queue for 8.3 that will allow a more flexible approach to this.
I'll add a --version option to pg_standby to allow us to discuss which
version is in use, to avoid such issues in future. Thanks,
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
file or directory
> Jun 18 15:44:39 postgres[29730]: [55-1] PANIC: storage sync failed
> on magnetic disk: No such file or directory
It's a duplicate bug. Please check next time before you report.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
e? Benchmark ? Availability ? Architecture ?
> Limitation : users, volumes ? Resouces needed ? Support ?
I would suggest you make your comparison based upon your specific needs,
not a purely abstract comparison. If your not sure what your
requirements are, research those first.
--
ke a base backup, is there anything to be gained by
> using incrementally updated backups?
If you are certain there are parts of the database not touched at all
between backups. The only real way to be sure is to take file level
checksums, or you can trust file dates. Many backup solutions can do
thi
On Mon, 2007-06-25 at 16:00 -0500, Erik Jones wrote:
> On Jun 25, 2007, at 3:40 PM, Simon Riggs wrote:
> >> If I'm correct, then for large databases wherein it can
> >> take hours to take a base backup, is there anything to be gained by
> >> using incrementally
ex. So indexes
specifically to provide a fast ORDER BY/LIMIT are no longer required.
Courtesy of Greg Stark.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
r procedure to use in
> these situations?
Your example transactions are so large that going back 15 minutes is not
enough. You'll need to go back further.
recovery_target_time can only stop on a COMMIT or ABORT record. This is
because it makes no sense to recover half a transaction, only w
m is unfortunately release specific, which is not very useful
for you now. D05E is the correct magic number for 8.2.4.
I'll update that program once we have the main software done for 8.3. I
was hoping that Diogo would continue to support it.
--
Simon Riggs
EnterpriseDB
On Mon, 2007-07-02 at 11:06 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Sun, 2007-07-01 at 21:41 -0700, Jason L. Buberel wrote:
> >> I am trying to learn/practice the administrative steps that would need
> >> to be taken i
On Mon, 2007-07-02 at 16:32 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > On Mon, 2007-07-02 at 09:21 -0700, Jason L. Buberel wrote:
> >> I downloaded the latest xlogdump source, and built/installed it against
> >> my 8.2.4 s
postgresql.org/docs/8.2/static/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose
hich is much less likely than corruption of the data blocks
at hardware level. ISTM that both Slony and Log shipping replication
protect fairly well against block corruption on the standby, but only
log shipping allows you to recover the precise block, as you describe.
--
Sim
LIMIT 100 isn't this essentially the same thing?
Both restrict the number of matches found, but they're not the same
thing. One is for the query as a whole, the other is for one index scan
on a GIN index.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb
> one... other than our scheme with the delete with limit + trigger +
> private temp table thing.
Use partitioning: don't delete, just drop the partition after a while.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)
k, I'm bit confused here
Visibility has nothing to do with subtransactions, so your worry is not
relevant. We judge visibility either at the start of each transaction
when in SERIALIZABLE mode, or we judge visibility at the start of each
statement when in READ COMMITTED (default) mode.
--
Sim
help me figure out what I need to do to correct this and get my
> database running again?
You're running 8.1 with GIST indexes and you will prefer the way they
work in 8.2. The changes were bug fixes but possibly considered
extensive enough to not have been backpatched.
--
Simon Riggs
On Fri, 2007-08-03 at 15:12 +0800, Ow Mun Heng wrote:
> Is 30min - 2hours too long or is this considered "normal"??
Yes.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
ay to remove it while keeping the database operational/
> restore-able by copying it back?
Reduce the setting of checkpoint_segments to something more realistic.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)
id in (select
transactionid from xids);
drop table xids;
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail comm
ver, we have database files ( not wal files ) that change while
> the system is in backup mode. This happens during every backup. Is
> this normal?
It's OK if they change; thats the whole point of HOT backup - you can
just continue working while we take the backup.
--
Simon Rig
k them."
I'll shortly be writing a doc patch to clarify a few points and to
explain new possibilities, such as Koichi Suzuki's work.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 9: In versions
definite list to
> work with?
There's a few different kinds of errors pg_standby can generate, though
much of its behaviour depends upon the command line switches.
I wasn't planning on documenting all possible failure states. We don't
do that anywhere else in the docs.
Happy to c
s. Even with archive_timeout set there could be
various delays before that happens. We have two servers and a network
involved, so the time might spike occasionally.
Touching a file doesn't really prove its working either.
Not sure what to suggest otherwise.
--
Simon Riggs
2ndQuadra
olumns to system tables.
Superusers have the capability to modify data in catalog tables and many
other things besides, normal users don't.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 5: don&
l.org/pgdocs/postgres/sql-explain.html
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED]
4 x86_64 GNU/Linux) and the new server is running Mac OS
> X Leopard Server.
The First Commandment is Make Thy Servers Identical, which applies to
OS, OS version, disk layouts/config as well as basic hardware. If
they're not then you're going to get some strange results.
--
On Thu, 2007-10-04 at 09:21 -0600, Brian Wipf wrote:
> On 4-Oct-07, at 8:14 AM, Simon Riggs wrote:
> > The First Commandment is Make Thy Servers Identical, which applies to
> > OS, OS version, disk layouts/config as well as basic hardware. If
> > they're not then you&#x
y leak. If somebody will be interesting, I can provide my
> postgres.conf and I can write script isolating and demonstrating this
> phenomena.
It's a known side effect of the way FKs work currently.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.
to re-sync from the primary as
often as was the case with 8.1 and prior.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index s
lt of the replication
technique. That means these incidents are very rare and we have quickly
fixed such bugs when they do occur. I think this has happened twice in
12-18 months.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)
. If that's what people think is wanted. I'd seen the
behaviour as beneficial up til now.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
with
rsync, or another method that uses atomic 8Kb reads. The backup is only
valid if you rollforward past the next restartpoint after the backup
completes, which is not technically the right place but definitely far
enough. So its not exactly for the feint-hearted, at the moment.
--
Simon Riggs
release level is being tested? It may already have happened.
8.3 is substantially faster at seq scans, so the tests should be re-run
on 8.3 beta.
Also, re-run the Postgres test. It should be faster the second time,
even if the database server is restarted between tests.
--
Simon Riggs
2ndQuadr
ented, otherwise I would have
suggested this myself way back. This new parameter would be a small
change, but will make a major difference to application portability.
This seems like the key to unlocking your new functionality for most
people.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadr
is
there. I've had that question before myself.
The tuple level ExclusiveLocks you are seeing are locking only the rows;
the table containing those rows will not be ExclusiveLock-ed.
The docs are correct in what they say about *table-level* (i.e. relation
as referred to by pg_locks) ExclusiveLoc
On Wed, 2007-11-07 at 11:39 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Wed, 2007-11-07 at 10:23 -0500, Tom Lane wrote:
> >> I put this in the same category as altering the identifier case-folding
> >> rules.
>
> > That has m
On Wed, 2007-11-07 at 16:05 +0100, Martijn van Oosterhout wrote:
> On Wed, Nov 07, 2007 at 02:37:41PM +0000, Simon Riggs wrote:
> > Editing an application, you would be required to add the words NULLS
> > FIRST to every single ORDER BY and every single CREATE INDEX in an
> &g
On Wed, 2007-11-07 at 08:38 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > If an application has already made that choice then we should allow them
> > the opportunity to work with PostgreSQL. The application may be at
> > fault, but PostgreSQL is the loser bec
On Wed, 2007-11-07 at 10:23 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Perhaps we can have a parameter?
> > default_null_sorting = 'last' # may alternatively be set to 'first'
>
> Not unless it's locked down at initdb
taneous, so there is no single time at which the
hot backup takes place. So deciding whether a file has changed based
upon a comparison of two file timestamps cannot work. You would need to
take timestamps for the file both before the pg_start_backup() and after
the pg_stop_backup() of the file f
backup:
>
time1
> - pg_start_backup()
> - full backup of the PostgreSQL files
> - pg_stop_backup()
time2
>
> Next day:
>
time3
> - pg_start_backup()
> - backup of the files that have changed since the last backup
> - pg_stop_backup()
time4
> The recovery:
>
On Fri, 2007-11-09 at 10:28 +0100, Albe Laurenz wrote:
> Simon Riggs wrote:
> >>>>>>> So if we perform our database backups with incremental
> >>>>>>> backups as described above, we could end up with additional
> >>>>>>>
On Fri, 2007-11-09 at 10:59 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-11-09 at 10:28 +0100, Albe Laurenz wrote:
> >> I think that understanding is finally dawning here.
> >>
> >> The problem you see is that the
om pgfoundry.
Postgres just provides the hooks to allow it to work, nothing else.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subs
because if you have the last backup and all the
> archived segments it gives you another potential way to rebuild the
> database in case of a large disaster damages both the primary and the
> secondary. You can never have too many ways to try and recover from such
> a situation
pg_dump never allows any form of Point in Time Recovery.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAI
least in the first release.
So, its something we expect to work on actively in 2008, but won't be
available for use for roughly another year yet.
There is some overlap in functionality between this and Slony, though
there is no intention to replace all of the features of Slony.
e been involved in the past and are active in the
community, but I don't want to assume that they are interested in
helping with organisation and advocacy.
If you'd been thinking about getting involved, now is your chance.
--
Simon Riggs
2ndQuadrant h
> [1] http://archives.postgresql.org/pgsql-hackers/2007-02/msg01390.php
> [2] http://archives.postgresql.org/pgsql-general/2007-09/msg00752.php
http://archives.postgresql.org/pgsql-general/2007-11/msg01193.php
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---
n.html
plus 2ndQuadrant now offers training to directly address this decision.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
plication, amongst other issues. It looks like its going to have to be
user companies, rather than vendors that sponsor these things.
I've got the plans, I just need the time to execute them.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of bro
s through execution of dynamic SQL.
>
> Is it really true ?
Depends how complex your rules are, but I think yes is the short answer.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
---(end of broadcast)---
TIP 9: In versions
and was not archived when server went down
>
> file upto 56 are there in archive.
>
> can anybody please explain why server giving message for filer 57 not
> found in archive area.
http://www.postgresql.org/docs/8.2/static/continuous-archiving.html#BACKUP-PITR-RECOVERY
--
S
On Wed, 2007-11-28 at 11:00 +, Ashish Karalkar wrote:
> Thanks Simon for your replay,
> Yes I have followed the same instruction givn on the link, still it is
> happining , should i ignore this message too?
Yes.
--
Simon Riggs
2ndQuadrant http://www.2ndQua
1 - 100 of 448 matches
Mail list logo
