Following an upgrade to 8.2.2, many of my plpgsql functions started to cause
server process crashes.
I make use of a custom data-type "uniqueidentifier", available here:
http://gborg.postgresql.org/project/uniqueidentifier
ftp://gborg.postgresql.org/pub/uniqueidentifier/stable/uniqueidentifier-0.
On Mon, Feb 05, 2007 at 05:21:34PM -0500, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > have this about PQfreemem():
> >
> > Frees memory allocated by libpq, particularly
> >PQescapeByteaConn,
> >PQescapeBytea,
> >PQunescapeBytea,
> >and PQnotifies.
> >It is needed by Micro
> What I'm more concerned about, with Jan's proposal, is the assumption
> that you always want to resolve conflicts by time (except for
> balances,
> for which we don't have much information, yet). I'd rather
Um, I think the proposal was only for beneficial backend functionality
for replicati
On Mon, 2007-02-05 at 23:25 +, Gregory Stark wrote:
> "Gregory Stark" <[EMAIL PROTECTED]> writes:
>
> > "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >
> >> OK, please propose some wording so at least we can get agreement on
> >> that.
> >
> > How about something open-ended like "arrange for u
Reading the post again I caught a typo in my query. I had been playing
with variations of this test to try and get it working, but I have had no
success with any combination as long as it returns this kind of type.
I was comparing integers to uniqueidentiers, which actually works, but is
unrelate
> > future for some reason. (the doc for the other functions say you
have to
> > use PQfreemem without mentioning any exceptions)
> >
> > Thoughts? Rip out or update?
>
> Are you saying that almost all Win32 binaries and libraries now can
free
> across DLLs?
You can under very narrow conditions
On Mon, 2007-02-05 at 19:18 -0500, Jan Wieck wrote:
> On 2/5/2007 11:52 AM, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> Sounds like a good time to suggest making these values configurable,
> >> within certain reasonable bounds to avoid bad behaviour.
> >
> > Actually, given
On 2/6/07, Jonathan Gray <[EMAIL PROTECTED]> wrote:
Following an upgrade to 8.2.2, many of my plpgsql functions started to cause
server process crashes.
I make use of a custom data-type "uniqueidentifier", available here:
http://gborg.postgresql.org/project/uniqueidentifier
ftp://gborg.postgres
Simon Riggs wrote:
On Sat, 2007-02-03 at 09:43 -0800, Stephan Szabo wrote:
On Sat, 3 Feb 2007, Simon Riggs wrote:
On Fri, 2007-02-02 at 16:50 -0500, Tom Lane wrote:
No, I don't. I think knowledge of which columns are in a PK is quite a
few levels away from the semantics of row locking. To p
On Tue, 2007-02-06 at 12:10 +0900, ITAGAKI Takahiro wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote:
>
> > > Actually, given what we've just learned --- namely that choosing these
> > > values at random is a bad idea --- I'd want to see a whole lot of
> > > positive evidence before adding such a
[EMAIL PROTECTED] wrote:
Reading the post again I caught a typo in my query. I had been playing
with variations of this test to try and get it working, but I have had no
success with any combination as long as it returns this kind of type.
I was comparing integers to uniqueidentiers, which actu
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Heikki, did this code cleanup get included in your recent btree split
fix?
No.
OK, would you please send a patch to remove the unused code. Thanks.
Ok, here you are.
--
Heikki Linnakangas
EnterpriseDB http://www.en
On 2/6/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
Indeed, the code can crash on NULL values as the NULL checks
are missing or wrong in the functions. Actually all the various
functions except newid() should be declared STRICT IMMUTABLE
thus immidiately avoiding problems with NULLs.
Could you re
Gavin Sherry wrote:
On Thu, 1 Feb 2007, Bruce Momjian wrote:
Where are we on this patch? Does it have performance tests to show
where it is beneificial? Is it ready to be reviewed?
Here's an updated patch:
http://www.alcove.com.au/~swm/bitmap-2007-02-02.patch
In this patch, I rewrote the
On 2/6/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
STRICT IMMUTABLE fixed the crash for me so seems it was bug
in the module. Although it did not happen in 8.2.1 so seems
some change in 8.2.2 made it trigger.
Trigger was following patch:
http://archives.postgresql.org/pgsql-committers/2007-02/
Hello all,
after upgrading from 8.1.5 to 8.1.7, I got errors in the server log when
updating decimal values using string constants. I tried the same using
psql (pasted the query from below) and it fails, too. Downgrading to
8.1.5 resolved the issue.
ERROR: attribute 4 has wrong type
DETAIL:
On Tue, Feb 06, 2007 at 12:34:50PM +0100, Michael Paesold wrote:
> Hello all,
>
> after upgrading from 8.1.5 to 8.1.7, I got errors in the server log when
> updating decimal values using string constants. I tried the same using
> psql (pasted the query from below) and it fails, too. Downgrading
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> OK, would you please send a patch to remove the unused code. Thanks.
> Ok, here you are.
Applied with an added comment and Assert.
While testing it I realized that there seems to be a nearby bug in
_bt_findsplitloc: it fai
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Attached is a patch for uniqueindent-0.2 that removes the
> buggy checks and makes functions STRICT IMMUTABLE.
Not sure where you should send that, but it's not here.
regards, tom lane
---(end of broadcas
On Mon, Jan 29, 2007 at 04:22:43PM -0500, Tom Lane wrote:
>
> (A) I'm not sure we would have heard about it, and (B) any one user is
> probably only using a subset of what has been proposed to be loaded by
> default, so the odds of collisions would go way up.
As a data point, some time ago (7.2 d
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 2/6/07, Marko Kreen <[EMAIL PROTECTED]> wrote:
>> STRICT IMMUTABLE fixed the crash for me so seems it was bug
>> in the module. Although it did not happen in 8.2.1 so seems
>> some change in 8.2.2 made it trigger.
> Trigger was following patch:
> htt
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
OK, would you please send a patch to remove the unused code. Thanks.
Ok, here you are.
Applied with an added comment and Assert.
While testing it I realized that there seems to be a nearby bug in
_bt_find
Following an upgrade to 8.2.2, many of my plpgsql functions started to cause
server process crashes.
I make use of a custom data-type "uniqueidentifier", available here:
http://gborg.postgresql.org/project/uniqueidentifier
ftp://gborg.postgresql.org/pub/uniqueidentifier/stable/uniqueidentifier-0.
Michael Paesold <[EMAIL PROTECTED]> writes:
> after upgrading from 8.1.5 to 8.1.7, I got errors in the server log when
> updating decimal values using string constants.
Have you got a constraint or functional index on that column?
regards, tom lane
--
Hi all,
Methinks I made a big mistake when swapping from 8.2.1 to 8.2.2
I read the "fix incorrect permission check in
information_schema_key_column_usage_view" chapter in HISTORY far too fast
and fed psql on each database with share/information_schema.sql.
Too late to stop it!
What did I do wrong
Andrew Sullivan wrote:
On Mon, Jan 29, 2007 at 04:22:43PM -0500, Tom Lane wrote:
(A) I'm not sure we would have heard about it, and (B) any one user is
probably only using a subset of what has been proposed to be loaded by
default, so the odds of collisions would go way up.
As a data p
Hi,
Zeugswetter Andreas ADI SD wrote:
And "time based"
is surely one of the important conflict resolution methods for async MM
replication.
That's what I'm questioning. Wouldn't any other deterministic, but
seemingly random abort decision be as clever as time based conflict
resolution? It wo
On Tue, Feb 06, 2007 at 11:43:24AM -0500, Andrew Dunstan wrote:
> Andrew Sullivan wrote:
> >
> >As a data point, some time ago (7.2 days) I used to do this as a
> >matter of completeness, and never had a collision.
>
> The point I at least have been trying to make is that extensions
> generally
ohp@pyrenet.fr writes:
> I read the "fix incorrect permission check in
> information_schema_key_column_usage_view" chapter in HISTORY far too fast
> and fed psql on each database with share/information_schema.sql.
> Too late to stop it!
> What did I do wrong, and how can I go backwards (I imagine %
ohp@pyrenet.fr wrote:
Unrelated, I have problem with conforming string: adding a E is easy in C
or PHP but SpamAssassin has this plpgsql function :
[snip]
As you see, token is bytea where do I put the E in the insert query?
Since you aren't using a string literal in this function fo
On 2/6/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Attached is a patch for uniqueindent-0.2 that removes the
> buggy checks and makes functions STRICT IMMUTABLE.
Not sure where you should send that, but it's not here.
I did Cc: the maintainer.
--
marko
http://doxygen.postgresql.org is now set up for your browsing pleasure.
It's synced to anoncvs once per day.
//Magnus
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.o
I've been looking into converting some code to use strlcpy rather than
strncpy, as previously discussed. Making good use of strlcpy requires
the availability of strlcat as well, so I'm going to add the OpenBSD
version thereof to src/port/ as well, unless anyone objects.
--
Peter Eisentraut
ht
As per numerous reports this morning, PG 8.2.2 and 8.1.7 both fail on
fairly simple scenarios involving typmod-bearing columns (varchar,
numeric, etc) with check constraints or functional indexes (and maybe
other cases too, but those are the ones reported so far). I have not
been able to reproduce
Nikolay Samokhvalov wrote:
On 2/5/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
[...]
I would suggest we start with what is (I think) simplest and clearest:
. catalog support via a simple extension->schema(s) map
. initdb installs standard extensions if it finds them, unless told
not to
. sup
On Tue, Feb 06, 2007 at 13:27:47 -0500,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I have applied a patch that resolves the problem AFAICT, but this time
> around it would be nice to get some more eyeballs and testing on it.
> Please try CVS HEAD or branch tips this afternoon, if you can. Core
> i
On Feb 6, 12:27 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
> As per numerous reports this morning, PG 8.2.2 and 8.1.7 both fail on
> fairly simple scenarios involving typmod-bearing columns (varchar,
> numeric, etc) with check constraints or functional indexes (and maybe
> other cases too, but those
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Is a test going to get added to the regression tests to catch similar
> regressions in the future?
I've been thinking about that. It seems that the regression tests have
fairly poor coverage of use of typmod-bearing data types in general;
most of our
Tom Lane wrote:
Michael Paesold <[EMAIL PROTECTED]> writes:
after upgrading from 8.1.5 to 8.1.7, I got errors in the server log when
updating decimal values using string constants.
Have you got a constraint or functional index on that column?
Yes.
Check constraints:
"tc_reminder_charges
On Feb 6, 2007, at 12:40 PM, Tom Lane wrote:
Bruno Wolff III <[EMAIL PROTECTED]> writes:
Is a test going to get added to the regression tests to catch similar
regressions in the future?
I've been thinking about that. It seems that the regression tests
have
fairly poor coverage of use of ty
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Feb 6, 2007, at 12:40 PM, Tom Lane wrote:
>> ... massive expansion of the tests doesn't seem justified
> What about the idea that's been floated in the past about a --
> extensive mode for regression testing that would (generally) only be
> used by the
On 2/6/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
around 6:30 this morning, I started getting the following messages in my log:
Feb 6 06:33:34 mojo postgres[1117]: [2-1] :: ERROR: could not access
status of transaction 51911
Feb 6 06:34:35 mojo postgres[1128]: [2-1] :: ERROR: could no
Merlin Moncure wrote:
> On 2/6/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
>> around 6:30 this morning, I started getting the following messages in
>> my log:
>>
>> Feb 6 06:33:34 mojo postgres[1117]: [2-1] :: ERROR: could not access
>> status of transaction 51911
>> Feb 6 06:34:35 mojo po
Merlin Moncure wrote:
> On 2/6/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> >around 6:30 this morning, I started getting the following messages in my
> >log:
> >
> >Feb 6 06:33:34 mojo postgres[1117]: [2-1] :: ERROR: could not access
> >status of transaction 51911
> >Feb 6 06:34:35 mojo
On 2/6/07, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote:
Merlin Moncure wrote:
> On 2/6/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
>> around 6:30 this morning, I started getting the following messages in
>> my log:
>>
>> Feb 6 06:33:34 mojo postgres[1117]: [2-1] :: ERROR: could not access
On 2/6/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> actually, here is some more relevant bits from the log.
> Feb 6 06:31:33 mojo postgres[1088]: [1-1] :: LOG: autovacuum:
> processing database "template0"
> Feb 6 06:31:33 mojo postgres[1088]: [2-1] :: ERROR: could not access
> status of t
Merlin Moncure wrote:
> ya, it doesn't seem to match, as this seems to be repeating quite
> regularly. interesting that my 'clog' files start at 06B6 and count
> up. 0207 is way off the charts.
>
> a lot of applications are hitting this database, and so far everything
> seems to be running ok (i
n 2/6/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Merlin Moncure wrote:
> ya, it doesn't seem to match, as this seems to be repeating quite
> regularly. interesting that my 'clog' files start at 06B6 and count
> up. 0207 is way off the charts.
>
> a lot of applications are hitting this databa
Merlin Moncure wrote:
> On 2/6/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >> actually, here is some more relevant bits from the log.
> >> Feb 6 06:31:33 mojo postgres[1088]: [1-1] :: LOG: autovacuum:
> >> processing database "template0"
> >> Feb 6 06:31:33 mojo postgres[1088]: [2-1] :: ERRO
Merlin Moncure wrote:
> n 2/6/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >Merlin Moncure wrote:
> >
> >> ya, it doesn't seem to match, as this seems to be repeating quite
> >> regularly. interesting that my 'clog' files start at 06B6 and count
> >> up. 0207 is way off the charts.
> >>
> >> a
Tom Lane wrote:
Bruno Wolff III <[EMAIL PROTECTED]> writes:
Is a test going to get added to the regression tests to catch similar
regressions in the future?
I've been thinking about that. It seems that the regression tests have
fairly poor coverage of use of typmod-bearing data types in gener
I'm still getting random failures from some of my buildfarm members
which is starting to get a bit irritating and annoying :-(
some recent failures:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-02-06%2015:25:04
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=clownfi
Stefan Kaltenbrunner wrote:
> I'm still getting random failures from some of my buildfarm members
> which is starting to get a bit irritating and annoying :-(
>
> some recent failures:
>
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-02-06%2015:25:04
> http://buildfarm.pos
On 2/6/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Merlin Moncure wrote:
> On 2/6/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >> actually, here is some more relevant bits from the log.
> >> Feb 6 06:31:33 mojo postgres[1088]: [1-1] :: LOG: autovacuum:
> >> processing database "template0"
Alvaro Herrera wrote:
> Setting the cost_delay sounds a reasonable thing to do anyway, and in
> fact I already proposed it and nobody objected (AFAIR). Now we only
> have to agree on a reasonable value.
Also note this message:
Date: Sat, 27 Jan 2007 21:51:40 -0500
Message-ID: <[EMAIL PROTECTED]
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>> I'm still getting random failures from some of my buildfarm members
>> which is starting to get a bit irritating and annoying :-(
>>
>> some recent failures:
>>
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=zebra&dt=2007-02-06%2015:
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
>> Setting the cost_delay sounds a reasonable thing to do anyway, and in
>> fact I already proposed it and nobody objected (AFAIR). Now we only
>> have to agree on a reasonable value.
>
> Also note this message:
>
> Date: Sat, 27 Jan 2007 21:51:40
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Also note this message:
>> If this theory is correct, then we can improve the reliability of the
>> stats test a good deal if we put a sleep() at the *start* of the test,
>> to let any old backends get out of the way. It seems worth a try
>> anyway. I'
Simon Riggs started this thread with the question:
. . .
Why do we need a SHARE lock at all, on the **referenc(ed)** table?
. . .
The root problem addressed by this thread seems to be that using share
locks in this way increases the likelihood of deadlock, and causes
blocking when no blocki
Bruce Momjian wrote:
> Tom Lane wrote:
>> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>>> Bruce Momjian wrote:
I think environment variables are used rarely enough on Win32 that we
should supply a hint.
>>> I think every Windows administrator who is not totally clueless knows
>>> how to s
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >>> Bruce Momjian wrote:
> I think environment variables are used rarely enough on Win32 that we
> should supply a hint.
> >>> I think every Windows administrator who is not
Tom Lane wrote:
I'm tempted to propose replacing the fixed sleep with a short plpgsql
function that sleeps for a second, checks to see if the stats have
changed, repeats if not; giving up only after perhaps 30 seconds.
It'd be interesting to try to gather stats on the length of the delay
taken,
It would be great to be able to join to update, returning, etc. It
looks like the code was deliberately tied off as-is and I was
surprised not to see a todo for this.
the basic idea is to be able to do things like:
select * from (update foo set id = 1 returning *) q;
which currently syntax erro
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm tempted to propose replacing the fixed sleep with a short plpgsql
>> function that sleeps for a second, checks to see if the stats have
>> changed, repeats if not; giving up only after perhaps 30 seconds.
>>
>> It'd be interesting
On Tue, 2007-02-06 at 16:54 -0500, Merlin Moncure wrote:
> It would be great to be able to join to update, returning, etc. It
> looks like the code was deliberately tied off as-is and I was
> surprised not to see a todo for this.
>
> the basic idea is to be able to do things like:
> select * from
Hello,
Currently PostgreSQL support set returning functions.
ANSI SQL 2003 goes with new type of functions - table functions. With this
syntax
CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
PostgreSQL equal statements are:
CREATE TYPE tmptype AS (c1 t1, ...)
CREATE FUNCTION ... RETURNS S
> Josh Berkus writes:
> > In recent versions, we've changed the logging of function executions so
> > that only the function call is logged, and not any of the queries which it
> > may execute internally. While most of the time this method is superior
> > for performance analysis, in applicati
Korry,
> If anyone is interested, let me know and I'll add this to my ToDo
> list.
The Sun benchmarking team needs this. However, we need to be able to feed
the data into some kind of mass analysis ala pg_fouine so that we can do
overall performance analysis.
--
--Josh
Josh Berkus
PostgreSQ
"Marc Munro" <[EMAIL PROTECTED]> writes:
> Proposal 1: Alter the way RI triggers fire, so that they complete before
> locking the row against which they fire.
It's kind of hard to know what records the user will choose to update before
he actually does the update...
> Proposal 2: Lock the index
Tom Lane wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only statements [pitr]
No, it's a someday-wishlist item; the work involved is not small.
Thanks,very much for the info. I'm
Andrew Hammond wrote:
On Jan 26, 2:38 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only statements [pitr]
No, it's a someday-wishlist item; the work
Gregory Stark wrote:
"Rick Gigger" <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only statements [pitr]
This is useful for checking PITR recovery."
No, nobody worked on it prior to 8.2. Afaik there's
On 2/6/2007 11:44 AM, Markus Schiltknecht wrote:
Hi,
Zeugswetter Andreas ADI SD wrote:
And "time based"
is surely one of the important conflict resolution methods for async MM
replication.
That's what I'm questioning. Wouldn't any other deterministic, but
seemingly random abort decision be a
On Tue, 6 Feb 2007, Pavel Stehule wrote:
> Hello,
>
> Currently PostgreSQL support set returning functions.
>
> ANSI SQL 2003 goes with new type of functions - table functions. With this
> syntax
>
> CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
>
> PostgreSQL equal statements are:
>
> CREATE
On Tue, 2007-06-02 at 23:47 +, Gregory Stark wrote:
> "Marc Munro" <[EMAIL PROTECTED]> writes:
>
> > Proposal 1: Alter the way RI triggers fire, so that they complete before
> > locking the row against which they fire.
>
> It's kind of hard to know what records the user will choose to update
Yay!
This rocks IMO, but I'm a borderline PHB so what do I know ;-)
- Luke
On 2/6/07 9:19 AM, "Magnus Hagander" <[EMAIL PROTECTED]> wrote:
> http://doxygen.postgresql.org is now set up for your browsing pleasure.
> It's synced to anoncvs once per day.
>
> //Magnus
>
> ---
Marc Munro <[EMAIL PROTECTED]> writes:
> The RI triggers currently fire when a record is updated. Under my
> proposal they would fire in the same way but before the record is locked
> rather than after. Or am I missing your point?
IOW, some other transaction could update or delete the tuple mean
Pavel Stehule wrote:
> Hello,
>
> Currently PostgreSQL support set returning functions.
>
> ANSI SQL 2003 goes with new type of functions - table functions. With
> this syntax
>
> CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
>
Yeah this should be pretty easy because a table is just a comp
Luke Lonergan wrote:
> Yay!
>
> This rocks IMO, but I'm a borderline PHB so what do I know ;-)
You think, "Oh, this will make my developers more productive". :-)
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterpris
On Feb 5, 2007, at 8:19 AM, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
My suggestions would be
1. "Database system has completed recovery" and
2. "Database system is ready to accept connections"
The second was in fact the wording I had in mind, sorry for not being
clear. As to
On Feb 5, 2007, at 12:53 PM, Andrew Hammond wrote:
On Jan 26, 2:38 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
Rick Gigger <[EMAIL PROTECTED]> writes:
I thought that the following todo item just barely missed 8.2:
"Allow a warm standby system to also allow read-only statements
[pitr]
No, it's a
On Feb 5, 2007, at 11:19 AM, Andrew Dunstan wrote:
Jim Nasby wrote:
There was also mention of having a means to tell pg_dump not to
dump extensions...
What's the use case for that? What will we do if there are db
objects that depend on some extensions? Given that there will be
some uninstal
On 2/6/07, Jim Nasby <[EMAIL PROTECTED]> wrote:
On Feb 5, 2007, at 12:53 PM, Andrew Hammond wrote:
> On Jan 26, 2:38 pm, [EMAIL PROTECTED] (Tom Lane) wrote:
>> Rick Gigger <[EMAIL PROTECTED]> writes:
>>> I thought that the following todo item just barely missed 8.2:
>>> "Allow a warm standby syst
Something worth noting... the only places I've actually seen MM
replication implemented, each master was in fact still responsible
for it's own set of data. It was essentially something that you could
really do with Slony, if you could tolerate the extreme complexity
that would be involved.
Hi,
Jan Wieck wrote:
Whatever strategy one will use, in an async multimaster there are always
cases that can be resolved by rules (last update being one of them), and
some that I can't even imagine solving so far. I guess some of the cases
will simply boil down to "the application has to make
85 matches
Mail list logo
