Is anyone actually working on Postgres-R ? Last git commit was in January 2011.
What are the chances of it getting integrated with the core, which it
is probably targeted for ?
If I picked it up, and tried to make usable for my own needs - instead
of implementing trigger/log (slony like) multi mas
2011/9/13 Merlin Moncure :
> 2011/9/13 Grzegorz Jaśkiewicz :
>> I'm guessing I won't get much more from devs , without providing more
>> info here which unfortunately has been lost.
>
> yup -- you destroyed all the evidence. if it happens again, try
> posting s
I'm guessing I won't get much more from devs , without providing more
info here which unfortunately has been lost.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2011/9/12 Merlin Moncure :
>
> It seems odd that you could not create a temp sequence but you were
> able to reindex the entire database. did you confirm you were
> blocking on a non-granted lock?
I could revacuum/reindex all stuff, only if I had to do the system
catalogues first. That seemed a
So here's the thing. I got a message from one of the developers, that
running 'create temporary sequence xyz;' hangs on the database.
That seemed suspicious. I tried running any ddl command, and that hang.
No other connections to the database.
It turned out that it had a power failure earlier in t
It probably won't fix it, but you'll avoid possible issues in the future.
However you should look at possibly upgrading to 8.4 or later, as 8.0
is either out of its support life, or getting close to it.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
On Thu, Sep 1, 2011 at 11:14 AM, Sim Zacks wrote:
> On 09/01/2011 12:26 PM, Pavel Stehule wrote:
>>
>> Hello
>>
>> postgres=# create table tt(a int, b varchar);
>> CREATE TABLE
>> postgres=# insert into tt values(10,'hello');
>> INSERT 0 1
>>
>> postgres=# select md5(array_to_string(array_agg(md5(
Alternatively you can get the 'server' package from app store, it has
postgresql already in it :) (9.0)
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
what you probably looking for is formatting the output into a string.
Postgresql will store it as 2.3, because that is what 2.30 is anyway.
Its up to you to format it before passing it on to the user/business
logic/whatever.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
On Mon, Jun 27, 2011 at 4:12 PM, F T wrote:
> Hello list,
>
> I use PostgreSQL 8.4 and Postgis 1.4.
>
> I use FME to insert 772185 records in a table (multipolygons that represent
> parcels).
>
> Everything seems fine but...
> If I type select count(*), I get the right number of records : 772185
>
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#comp
That applies in general to SSL apps.
In cryptography it is always recommended, and sometimes even mandatory
to compress data before encryption. This reduces the risk of finding
patterns, etc.
And SSL includes that option as well.
But that's
The answer is: SSL. SSL will compress things, before encrypting
(depends on setup obviously).
As far as I know, postgresql it self doesn't compress any data over the wire.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://w
It could be worth considering 9.1. Probably by the time you get
production ready version, 9.1 will be already stable (few months I
guess).
The usual answer to that question is - it will be ready when its ready.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes
Cursors only see the data that is the effect of the query. That output
doesn't get updated. It would actually be pretty bad if that was the
case.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-ge
There's a generic trigger that sends a signal to a process whenever
changes are made (via listen/notify mechanism), but when FK cascade
fires it will cause a mass amount of notifies to be send out and I
want to avoid it.
2011/3/18 David Johnston :
> Don't know if this would work but could you che
Considering the following example.
Tables A and B.
Table A contains some data.
Table B reefers to table A using FK with 'on delete cascade'. Table B
has a trigger on it, after delete per row
Now, is there any way I can tell in the trigger on table B that it has
been called from a direct delete on
On Wed, Jan 5, 2011 at 3:03 PM, Mike Christensen wrote:
> 2011/1/5 Grzegorz Jaśkiewicz :
>> On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe
>> wrote:
>>> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>>>
>>>> * simple to generate, and 128bit ran
On Wed, Jan 5, 2011 at 2:37 PM, Scott Ribe wrote:
> On Jan 5, 2011, at 1:31 AM, Radosław Smogura wrote:
>
>> * simple to generate, and 128bit random is almost globally unique,
>
> Almost? Should be totally unique, as long as your random source is decent
> quality.
But I would never rely on that
I don't think planner should do things like creating an index. But it
might hint at doing it in the logs.
There was a discussion around that sort of feature on -hackers not so
long time ago. I don't remember what the conclusion was, but probably
that it just isn't worth wasting planner's cycles whe
lookup CASE WHEN END in docs.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/11/24 Florian Weimer :
> * Grzegorz Jaśkiewicz:
>
>> just never use SELECT *, but always call columns by names. You'll
>> avoid having to depend on the order of columns, which is never
>> guaranteed, even if the table on disk is one order, the return colu
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
read documentation on backups.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Timing is on.
psql (9.1devel)
Type "help" for help.
# select count(hashtext(a::text)) FROM generate_series(1,1) a;
count
---
1
(1 row)
Time: 106.637 ms
# select count(hashtext(a::text)) FROM generate_series(1,100) a;
count
-
100
(1 row)
Time: 770.823 ms
# select
try gdb --args ./pg_upgrade -d /var/pgsql-8_4_3/data/ -D
/var/pgsql-9_0_1/data/ -b /var/pgsql-8_4_3/bin/ -B
/var/pgsql-9_0_1/bin/ --check -P 5433 -v -g -G debug
and when it fails, type in 'bt' and paste it here please.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
OLD.column_name
NEW.column_name ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/10/20 Merlin Moncure :
> In recent versions of postgres (I think 8.4+?) you can add columns to
> the view via create/replace (not drop of course). This greatly
> reduces the practical annoyances of dropping view dependencies, at
> least for me...
Ok, We're still on 8.3 here, and management re
On Tue, Oct 19, 2010 at 3:12 PM, Tom Lane wrote:
> Ravi Katkar writes:
>> Is there any feature to drop the view with out cascading the dependents.
>
> No. But why don't you use CREATE OR REPLACE VIEW?
>
only caveat is, it won't work if he adds/removes any columns. CREATE
OR REPLACE VIEW is rathe
select regexp_replace(myval, E'(\\D)', '', 'g') from foo;
for added speed, you might consider this:
CREATE INDEX ON foo((regexp_replace(myval, E'(\\D)', '', 'g'))::bigint);
which is also going to protect you against inserts where value doesn't
contain any digits.
and added benefit of index:
gj=
If you use QT, it has PG connector classes I believe (it had in 3.x).
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
you can pass in/out very large set of data inside a transaction by
using temp tables. Temporary tables are one of the greatest features
of SQL dbs.
Here's one fact, it most often takes as long to transfer data from/to
a query/function as it takes to execute it. By storing data on the
server side, y
2010/9/29 Tom Lane :
> =?UTF-8?Q?Grzegorz_Ja=C5=9Bkiewicz?= writes:
>> I got bitten Today by 'alter table disable trigger all' vs 'trigger user'.
>> Basically , assuming that psql doesn't show me that FKs are disabled
>> some code was using 'trigger all' instead of 'user'.
>
> I think that is toda
I got bitten Today by 'alter table disable trigger all' vs 'trigger user'.
Basically , assuming that psql doesn't show me that FKs are disabled
some code was using 'trigger all' instead of 'user'.
Is that a bug of psql, or a feature ? As far as I can see
pg_catalog.pg_constraint doesn't contain in
Use JOIN sherlock.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
no you can't
but you have have multiple clusters running at the same time on the
same box. Just set them up on different ports, and in different
directories.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailp
On Tue, Sep 28, 2010 at 12:37 AM, Tim Uckun wrote:
>> If the table is large, I sometimes use the following pattern:
>
> The table is very large so I will use your advice thanks.
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> ht
prior to 8.4 not in will be slow. Just use left join.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/9/23 Raymond O'Donnell :
> On 23/09/2010 13:55, Grzegorz Jaśkiewicz wrote:
>>
>> or even better, learn English properly and contribute your translation.
>> I'm not whining that there's no Polish translation.
>>
>> French people are somewhat spe
or even better, learn English properly and contribute your translation.
I'm not whining that there's no Polish translation.
French people are somewhat specific in that matter, don't get me
started on aviation (cos it drives me insane).
--
Sent via pgsql-general mailing list (pgsql-general@p
try reindex database;
and move away from 7.4, it is unsupported, and ancient history.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I wonder if there's an equivalent of gcore on windows. If there is, it
might be useful.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
show us explain analyze on this
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Jun 30, 2010 at 2:41 PM, Andrea Lombardoni wrote:
>> You need to use EXECUTE for the INSERT statement as well per error:
>>
>> CONTEXT: SQL statement "INSERT INTO idmap (oldid, type, newid) VALUES(1,
>> 1, 1)" PL/pgSQL function "test" line 16 at SQL statement
>
> Thanks, this works and s
I'll fix it this way:
CREATE TABLE foob(id serial primary key, name varchar default '');
CREATE TABLE fooA(id serial primary key, fooBook int not null
references fooB(id) on update cascade on delete cascade DEFERRABLE,
name varchar default '');
CREATE FUNCTION foobarrB() RETURNS trigger AS
$_$
B
it is slightly more complicated than that, cos I need information from
fooA too. So we have a chicken and egg problem.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
that Id refers to 'name' column that I need. There still is FK on it,
so basically it is broken inside transaction, from trigger's
perspective.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-gene
because in my case I have many tables with FK pointing at foob. So
writing that many triggers is going to be a royal pain.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Jun 23, 2010 at 7:31 PM, Tom Lane wrote:
> Thom Brown writes:
>> Yes, I'm still not exactly sure why it's seeing uncommitted changes. :/
>
> Because it's all one transaction. A transaction that couldn't see its
> own changes wouldn't be very useful.
>
> I think what the OP is unhappy abo
I do understand what you are saying, but still it is highly
unintuitive. Since trigger is BEFORE, developer will expect that data
to be there.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-gener
it is confusing to me, because I thought triggers are firring BEFORE
anything goes away. So I assume that all data is still going to be
visible to the trigger, as it is firing BEFORE. The only thing is, it
looks like the FKs are doing the deletion and than things are handed
over to triggers.
--
S
the delete will succeed.
That's not the point of the exercise tho.
The point, is to print name in trigger, rather than null!
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
well, change foob column name to something else, and try yourself. It
still fails.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
not really, as it depends on pretty much both tables.
This is where de-normalization would actually makes sens, except for
that it wouldn't - because it will badly effect all my other queries
(joining on varchar is so slow).
I could drop FK, and replace that with my own trigger(s), but that's a
lo
nope, that's not the thing. This is just specific to my example. But
production code I have, doesn't have such confusing name, and still
fails.
Plus postgresql doesn't rely on names, but on oids rather.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
any ideas than, how can make it actually do what I wanted it to do please ?
Making FK deferrable doesn't help.
thanks.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
this is 8.3.7, for the record. And no, They won't let me update it to 8.3.11 :/
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
consider following example:
CREATE TABLE foob(id serial primary key, name varchar default '');
CREATE TABLE fooA(id serial primary key, fooB int not null references
fooB(id) on update cascade on delete cascade, name varchar default
'');
CREATE FUNCTION foobarrA() RETURNS trigger AS
$_$
BEGIN
On Tue, May 25, 2010 at 11:15 AM, Alban Hertroys
wrote:
> On 25 May 2010, at 11:38, Malm Paul wrote:
>
>> Hi,
>> I'm trying to update postgresql ver 8.7.3 to 8.4.4
>
> I know it's totally unrelated, but when did it become popular to send (HTML)
> messages in a very small blue font? I find this ra
don't lock tables explicitly. That's a killer for (concurrent) performance.
Just write queries properly, and use appropriate transaction level.
And you are sorted.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
by default query is wrapped in a transaction (if it is not run under a
transaction). And this will be default transaction isolation level.
some people think it works magic, but that's not true.
find in docs part that talks about transaction isolation levels, and
translate it to your problem.
--
S
every single query in postrgresql runs as a transaction, on top of it,
some are atomic, like when you use RETURNING statement. This is
because postgresql doesn't actually have to select these rows as
separate query.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make cha
If you think about it, NULL is not a value.
It makes sens that it allows multiple NULLs.
If you don't agree, than your SQL point of view doesn't match the
majority, and your designs won't fit in the SQL paradigm .
I think it is just a matter of experimenting, and experience to see
how useful it is
2010/5/12 Glyn Astill :
> --- On Wed, 12/5/10, Grzegorz Jaśkiewicz wrote:
>
>> Alban Hertroys
>>
>> wrote:
>> > On 12 May 2010, at 12:01, Glyn Astill wrote:
>> >
>> >> Did you not mention that this server was a slony
>> slave at some p
On Wed, May 12, 2010 at 11:09 AM, Alban Hertroys
wrote:
> On 12 May 2010, at 12:01, Glyn Astill wrote:
>
>> Did you not mention that this server was a slony slave at some point though?
>>
>> Just because you have removed slony, and the error comes from postgresql
>> itself does not mean the corru
On Wed, May 12, 2010 at 10:57 AM, Glyn Astill wrote:
> Hi Grzegorz,
>
> Is it always the same OID(s)?
>
> Usually this means something somewhere has a link to an OID that has been
> removed.
>
> You could try digging through pg_catalog lookng for an oid column that refers
> to the OID in questio
no it is not slony related.
It is a postgresql problem.
my original post:
http://archives.postgresql.org/pgsql-general/2010-05/msg00402.php
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
anyone please ?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Having seen that all previous problems went unresolved, heres a bit
more info. The system is 32 bit, running on enterprise redhat 4.7. It
is slony's slave node, so it will be hit with quite few updates.
My guess is that it happened when we ere adding/removing slony to the
system for Nth time (due t
I got that sort of error on 8.3.7 (can't upgrade really), is it
something that can be easily resolved ? I do understand that OID is
gone from the pg catalogue , but still in memory.
Will restart of database help in this case ? Was it fixed in
following revisions ?? (8.3.x, x>7).
--
GJ
--
Se
the rule of thumb for me is:
- if you have more than one column as PK - and are variable length,
or more than 2 columns, fixed length, no bigger than 8 bytes - go for
surrogate - always.
- if PK is variable length, on average longer than 8 bytes, or can
change - go surrogate.
- Otherwise leave
On Tue, May 4, 2010 at 3:16 PM, Merlin Moncure wrote:
> On Tue, May 4, 2010 at 9:40 AM, Merlin Moncure wrote:
>> On Sat, May 1, 2010 at 4:14 PM, John R Pierce wrote:
>>>
>>> If your 'natural key' is a large text field, I'd have to assume there's some
>>> point at which a surrogate index would be
2010/5/4 Peter Eisentraut :
> On tis, 2010-05-04 at 09:19 +0100, Grzegorz Jaśkiewicz wrote:
>> 2010/5/3 Peter Eisentraut :
>> > It was a convenient choice. You could propose a different method for
>> > generating the specific routine name, but given that it has to fit
2010/5/3 Peter Eisentraut :
> It was a convenient choice. You could propose a different method for
> generating the specific routine name, but given that it has to fit into
> an identifier and has to allow for function overloading, some kind of
> number makes the most sense, in absence of any othe
why specific_name column on that view contains also OID ?
This makes two databases that are identical, have different values
there. Is there any specific reason for that ?
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://w
it tells you that it is not able to compare timestamp with text. Different
types. Cast if you have to explicitly.
--
GJ
if you have a primary key on the table, and you should, you might get better
performance using LEFT JOIN.
EXCEPT will compare all columns, which might not be that fast, especially if
those are text. (hence why I always tell others to use int as key in a
table, but that's a different story).
--
G
however you are going to validate it, create yourself a domain for it
(custom type). That way, if it changes, you have to only update it in one
place, instead of doing it on column by column basis.
2010/4/1 Birgit Laggner
> Hi Grzegorz,
>
> sorry, but that doesn't help me, perhaps you could get a little bit
> clearer:
>
> @a) Does the use of SAVEPOINT avoid memory overflow? I could not find an
> explanation about memory use in the documentation of SAVEPOINT.
>
> transactions don't really us
a) you can't explicitly control transactions in plpgsql. If you need some
sort of a form of it, use save points.
b) you are trying to outsmart database software, and this is just a biiig
mistake, and you should stop doing that completely.
you can't really do any updates sensibly unless you know what the relation
is. So, I kind of silently assume that you know that.
create temporary table, insert your data, and than run update with join
against the table you wish to modify. And than drop your temp table.
simple.
2010/3/23 Filip Rembiałkowski
> For the record, I've recently observed such behaviour on non-cheap
> 64bit server harware.
>
> That was Pg 8.4.0. hardware specs available on request.
>
> EXPLAIN ANALYZE SELECT was over 2 times slower that SELECT. repeatedly.
>
> Answering an obligatory question:
yes, if you really want to do it - analyze should be running following
cluster, as it moves data around.
plus, with 8.4 autovacuum should do the job.
altho not an answer to your question, you might want to start using table
name aliases, to make queries more readable.
so instead of:
SELECT dsclient_logs.ev_id,dsclient_
logs.type,to_timestamp(dsclient_logs.ev_time)
as
timestamp,dsclient_logs.category,dsclient_logs.error,dsclient_logs.ev_text,ds
the reason you are using joins, most often is because your schema is
normalized. One way or another, de-normalisation + queries will cost you
more, than normalised tables and joins.
That's at least the short answer.
do a vacuum analyze verbose on it, and see if it complains about FSM (free
space map) setting. Which it probably will be.
just try if it does what you want it to do ;)
select count(*) AS count, error, ev_text FROM clients_event_log GROUP BY
error, ev_text;
you can add 'HAVING count(*) > X'; , if you want to see only those with
count above X, etc.
--
GJ
don't use 'NOT EXISTS', as this will be damn slow. Use LEFT JOIN.
all statements in postgresql are self contained transactions, and you cannot
change that.
To answer your question directly, you don't have to, it will all be a
transaction.
The best example of that is to run following query in psql:
CREATE TEMP TABLE foo() ON COMMIT DROP;
the table will not exi
On Fri, Feb 5, 2010 at 1:29 PM, Albe Laurenz wrote:
> In your case, by using ''Cote dIvoire''.
single quotes for string literals. So again: 'Cote d''lvoire'.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgr
use $$
Or you can always use double single quotes, which is going to
translate into single one, ie : blah = 'foo '' bar';
will give you "foo ' bar" string.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpre
try reindexing table.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
SET client_min_messages = error;
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
2010/1/23 Craig Ringer :
>
> An InnoDB `AUTO_INCREMENT' column under MySQL 5.x is pretty similar to a
> sequence.
>
> I increasingly think it's pretty safe to just
> 's/AUTO_INCREMENT/SERIAL/g'
> in DDL. Apps that use MyISAM aren't going to be fussy about how it works,
> and apps that use InnoDB g
On Fri, Jan 22, 2010 at 7:15 PM, Erik Jones wrote:
> Hello,
>
> Given that the EU has approved Oracle's acquisition of Sun w/ MySQL it's
> fairly likely that there may be a number of people and companies looking to
> move from MySQL to Postgres in the coming months. Does anyone know of any
> g
and to answer the question of the release date, I believe sometime
around summer holiday.
There is a schedule, but in reality things usually slip by couple
weeks, especially when you add quite few not so trivial patches like
replication.
--
Sent via pgsql-general mailing list (pgsql-general@postg
2010/1/22 John Mitchell :
> When is the new version of postgres (8.5) scheduled to be released as the
> latest stable version?
there will be no 8.5.
It was decided to name it 9.0.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
is going to be used for
replication.
2010/1/21 John Mitchell :
> So am I to presume that the current stable version of postgres (before 8.5)
> does require extra locking?
>
> John
>
> 2010/1/21 Grzegorz Jaśkiewicz
>>
>> On Thu, Jan 21, 2010 at 1:12 PM, John Mitchell
On Thu, Jan 21, 2010 at 1:12 PM, John Mitchell wrote:
> Hi,
>
> In reading the documentation it states that the SQL dump backup does not
> block other operations on the database while it is working.
yes, pg_dump opens serializable transaction thus guarantees data to be
the exact snapshot (as oppos
1 - 100 of 487 matches
Mail list logo
