On Mon, 2008-12-29 at 13:02 +0200, Heikki Linnakangas wrote:
> >> That will ensure that the standby doesn't need to stall WAL
> >> application because of read-only queries.
> >
> > It doesn't need to. That is already optional.
>
> Oh right. I should've added, "without having to kill queries".
On Thu, 2009-01-08 at 18:02 -0500, Aidan Van Dyk wrote:
> * Bruce Momjian [090108 16:43]:
> >
> > The attached patch from Aidan Van Dyk zeros out the end of WAL files to
> > improve their compressibility. (The patch was originally sent to
> > 'general' which explains why it was lost until now.)
>
On Fri, 2009-01-09 at 01:29 +0200, Hannu Krosing wrote:
> On Thu, 2009-01-08 at 18:02 -0500, Aidan Van Dyk wrote:
...
> > There's possible a few other ways to do it, such as zero the WAL on
> > recycling (but not fsyncing it), and hopefully most of the zero's get
> >
ean something you do after unclean
shutdown or when restoring from backup.
maybe allow_hot_slaves ;)
--
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pg
and define
anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
the number in parentheses
> Alvaro made
> a good point about not wanting to multiply the various hard-wired
> OID references, but perhaps some judicious code refactoring could
> prevent a notational di
l
> preference]. Then you can have functions with complex types like:
>
> maplist :
> function(anyelement,anyelement2,function(list(anyelement),list(anyelement2)))
>
> This would have the fringe benefit of eliminating types like anyarray
> (which is just list(anyelement))
On Wed, 2009-09-09 at 21:57 +0200, Pavel Stehule wrote:
> 2009/9/9 Alvaro Herrera :
> > Pavel Stehule escribió:
> >> 2009/9/9 Alvaro Herrera :
> >
> >> > I already published a pseudo-sprintf function in the wiki here:
> >> > http://wiki.postgresql.org/wiki/Sprintf I'm looking for something
> >> >
ping excessive trailing columns
> does not seem acceptable though; you could lose entire rows and not
> notice.
Maybe we could put a catch-all "text" or even "text[]" column at as the
last one of the table and gather all extra columns there ?
> --
> Alvaro Herrer
s well, in my very cursory look at
> the patch.
> Does Python have a saner mapping for it?
>
> regards, tom lane
>
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Train
On Thu, 2009-09-10 at 00:31 +0200, Dimitri Fontaine wrote:
> Hi,
>
> Tom Lane writes:
> > Hannu Krosing writes:
> >> anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
> >> the number in parentheses
> >
> > Yeah, that idea
On Thu, 2009-09-10 at 08:44 +0300, Hannu Krosing wrote:
> maybe just let users say what they mean, so first time we have "any" and
> if we need more then we say "same_as(...)"
Acutually we could be even more SQL-y and have a more verbose syntax for
pseudotypes by exte
e is another thing that would make postgreSQL a
lot more powerful for all kinds of computing.
> (This brings up the whole question of performance impact, which would
> have to be thought about and minimized.)
Completely agree - nobody wants a slow COPY command.
>
On Thu, 2009-09-10 at 21:30 +0200, Pavel Stehule wrote:
> 2009/9/10 Tom Lane :
> > Pavel Stehule writes:
> >> 2009/9/10 Tom Lane :
> >>> 1. Allow the existing "any" pseudotype as an input argument type for PLs.
> >>> (AFAICS this is simple and painless; about the only question is whether
> >>> we
pe" - etc invisible explicit casting.
what is the difference between these two ?
> It could work, but it doesn't look like SQL.
but we do it all over the place if another type is needed and CAST
exists for getting it
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalab
On Thu, 2009-09-10 at 22:15 +0200, Pavel Stehule wrote:
> 2009/9/10 Hannu Krosing :
> > On Thu, 2009-09-10 at 21:35 +0200, Pavel Stehule wrote:
> >> 2009/9/10 Tom Lane :
> >> > Pavel Stehule writes:
> >> >> I don't afraid about crashing. Simply I
On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> >> It might be possible to make it work, but it's likely to create a lot
> >> of bloat in pg_type, and will make it very difficult
On Thu, 2009-09-10 at 16:48 -0400, Robert Haas wrote:
> On Thu, Sep 10, 2009 at 4:38 PM, Hannu Krosing wrote:
> > On Thu, 2009-09-10 at 15:49 -0400, Tom Lane wrote:
> >> Hannu Krosing writes:
> >> > On Thu, 2009-09-10 at 15:06 -0400, Robert Haas wrote:
> >
o we will need to handle
multiple anyelementN types separately from ordinary types.
> > 5. Various syntactic sugar to substitute for anyelement. (Not in favor
> > of this myself, it seems to just complicate matters.)
>
> I agree; I don't think this solves any real pr
ormating, just you can use to_char function.
yes, format(...) is generic enough that people won't expect it to
confirm to their favorite languages version of printf.
> Pavel
>
> >regards, tom lane
> >
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
CREATE OR REPLACE FUNCTION foo(a ANY TYPE, b TYPE OF a)
CREATE OR REPLACE FUNCTION foo(ANY TYPE, TYPE OF $1)
and maybe try
CREATE OR REPLACE FUNCTION foo(a ANY TYPE, b TYPE OF a)
RETURNS ARRAY OF TYPE OF a
instead of
CREATE OR REPLACE FUNCTION foo(a anyelement, b anyelement)
RETURNS an
On Wed, 2009-09-16 at 11:10 -0700, Josh Berkus wrote:
> Hackers,
>
> Here's the feedback on replacing VACUUM FULL with VACUUM REWRITE:
> http://it.toolbox.com/blogs/database-soup/getting-rid-of-vacuum-full-feedback-needed-33959
>
> Of note:
>
> a) To date, I have yet to hear a single person brin
But it would be trivial
> to write one, so I think we should offer that as a contrib module.
I have not checked, but I suspect pg_reorg may already be doing
something similar http://pgfoundry.org/forum/forum.php?forum_id=1561
> --
> Heikki Linnakangas
> EnterpriseDB http://www.en
table was not locked during rewrite and
thus some code could be updating the old heap even while the data had
been muved to the new one.
> --
> Josh Berkus
> PostgreSQL Experts Inc.
> www.pgexperts.com
>
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Avail
lso moved towards beginning
then yes, it would have taken some time, but it would have definitely
helped
It would still have caused index bloat, so to get full benefit of it,
one should have finished it up with an equivalent of CONCURRENT REINDEX.
--
Hannu Krosing http://www.2ndQuadrant.co
ere with OLTP loads.
>
> How would this work with HS?
Exactly the same as just doing a lot of UPDATE's which move tuples
around between pages.
It actually _is_ a lots of updates, just with extra condition that tuple
is always moved to lowest available free slot.
> --
> Josh Berkus
On Wed, 2009-09-16 at 23:53 +0300, Heikki Linnakangas wrote:
> Hannu Krosing wrote:
> > On Wed, 2009-09-16 at 21:23 +0300, Heikki Linnakangas wrote:
> >> 2) Another utility that does something like UPDATE ... WHERE ctid > ? to
> >> move tuples to lower pages. It
do you mean by "VACUUM FULL"
if VACUUM FULL is just something that works on a table ends up with
(mostly) compacted one, then doing this CONCURRENTLY should not be
impossible.
If you mean the current version of VACUUM FULL, then this is impossible
indeed.
--
Hannu Krosing http
so that it's easier to tune something
> that isn't very hard to tune anyway doesn't seem like a good
> trade-off.
I think that just making sure that pessimal cases don't happen should be
enough, maybe just check for too-much-time-in-transaction after each N
pages touched.
--
On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Wed, 2009-09-16 at 21:19 -0400, Tom Lane wrote:
> >> VACUUM FULL CONCURRENTLY is a contradiction in terms. Wishing it were
> >> possible doesn't make it so.
>
> > It de
On Thu, 2009-09-17 at 10:32 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Thu, 2009-09-17 at 10:21 -0400, Tom Lane wrote:
> >> because it will break applications that depend on CTID.
>
> > Do you know of any such applications out in the wild ?
>
> Yes
o throw a "concurrent
> update" type of error when this happens, and we don't want magic
> background operations to cause that.
Would'nt current VACUUM FULL or CLUSTER cause much more grief in this
situation ?
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL
On Thu, 2009-09-17 at 12:36 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Thu, 2009-09-17 at 12:18 -0400, Tom Lane wrote:
> >> Or for an update without having to hold a transaction open. We have
> >> recommended this type of technique in the past:
>
>
ver discussion does not address that.
But maybe something can be tahen from this discussion the other way
round - maybe we should not be afraid of doing null updates during
in-place update
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consu
; FSMstrategy can change via ALTER TABLE ... WITH (fsm_strategy = ...)
>
> --
> Simon Riggs www.2ndQuadrant.com
>
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, 2009-09-18 at 16:24 +0200, Dimitri Fontaine wrote:
> Hans-Juergen Schoenig -- PostgreSQL writes:
> > Tom,
> > happy birthday.
>
> +1 from me :)
+1 from me too :D
> Regards,
> --
> dim
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability
On Thu, 2009-09-24 at 17:51 +0900, ning wrote:
> Hi all,
>
> I am using psqlodbc to connect to PostgreSQL8.2.4 server on Linux.
> The manual says "BEGIN TRANSACATION" is equlvalent to "START
> TRANSACTION", but it turns out that they throw different error message
> and have different effect to sub
further reduce error cases caused by charset
incompatibilities ?
> and at least
> gets the data into the DB where you can hack on it. But it's still
> going to be painful for some use cases.
>
> ...Robert
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalabi
anymore for tables which use hash
indexes.
> regards, tom lane
>
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, 2009-10-28 at 12:51 -0700, Jeff Davis wrote:
> On Wed, 2009-10-28 at 21:09 +0200, Hannu Krosing wrote:
> > Is at least the fact that they "are undocumented, have changed in the
> > past, and are likely to change again in the future" documented ?
>
> That
On Wed, 2009-10-28 at 15:31 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > I had never checked the docs for hash functions, but I had assumed, that
> > internal functions are prefixed by pg_ and anything else is public, free
> > to use functionality.
>
> Sure,
't change output over versions and is independent of
> hash index implementation concerns.
And maybe even documented ;)
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing
On Thu, 2009-10-29 at 09:32 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > Or maybe we could just extract the hashes form some version of stock
> > postgresql (say 8.3) and then make those available in contrib under the
> > name "stable_hashes" ?
>
> A b
On Tue, 2009-11-24 at 09:24 +0200, Heikki Linnakangas wrote:
> Greg Smith wrote:
> > Heikki Linnakangas wrote:
> >> So I guess what I'm asking is: Does anyone see any show-stoppers in
> >> removing VACUUM FULL
> > Here's the disclaimers attached to the new VACUUM REPLACE implementation
> > from Ita
cchet
> Aster Data
> Web: http://www.asterdata.com
>
>
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On Mon, 2009-11-23 at 18:31 -0500, Greg Smith wrote:
> Robert Haas wrote:
> > I'm fuzzy on what problem this is attempting to solve... as mentioned
> > in the above guidelines, it's usually good to start with some design
> > discussions before writing/submitting code.
> This has been through some
resolved and converted to right types.
it may be useful to also have forms like
COPY func(text) FROM stdin;
and
COPY func(bytea[]) FROM stdin;
for getting a less processed input
> should we try to make these kinds of operations a bit more
> symmetrical.
--
Hannu Krosing h
omething of the sort in contrib already, I believe, though
> it's so old it still uses abstime :-(
What's wrong with abstime ?
it is valid for timestamps up to 2038-01-19 and it's on-disk size
smaller than other timestamp options
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreS
on ]
[ , SORTOP = sort_operator ]
)
and maybe use additional INITFUNC=, if you need it for dblink type
things which don't do connection management it automatically like
pl/proxy does.
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Cons
On Tue, 2009-11-24 at 09:46 +, Thom Brown wrote:
> 2009/11/24 Hannu Krosing
> On Sun, 2009-11-22 at 18:51 -0500, Tom Lane wrote:
> > Craig Ringer writes:
> > > I do think this comes up often enough that a built-in
> trigger "upda
On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> > On Tue, Nov 24, 2009 at 2:50 AM, Hannu Krosing
> > wrote:
> >> Can't you use existing aggregate function design ?
> >>
> &
On Tue, 2009-11-24 at 03:48 -0800, Daniel Farina wrote:
> On Tue, Nov 24, 2009 at 3:25 AM, Hannu Krosing wrote:
> > On Tue, 2009-11-24 at 02:56 -0800, Daniel Farina wrote:
> >> On Tue, Nov 24, 2009 at 2:51 AM, Daniel Farina wrote:
> >> > On Tue, Nov 24,
approach here - do it as a set of types
and functions first, think about adding DDL once it has stabilised
enough
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
define
> triggers). With the current proposed implementation, would it be
> possible to define a view using child tables?
the child tables are there, and they _are_ defined, either implicitly
(using constraints, which "constraint exclusion" resolves to a set of
child tables) or ex
urrently, the second argument to copy is a source or destination of
> bytes, not records. So forcing it to deal with records is inconsistent.
>
> Regards,
> Jeff Davis
>
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting
On Wed, 2009-11-25 at 08:39 -0500, Emmanuel Cecchet wrote:
> Hannu Krosing wrote:
> > On Tue, 2009-11-24 at 10:08 -0500, Emmanuel Cecchet wrote:
> >
> >> Itagaki Takahiro wrote:
> >>
> >>> I just edited a wiki page for this discussi
effort for allowing triggers to be defined on
those (hidden) partitions.
If the partition tables are visible, some trigger support would be good.
> regards, tom lane
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services,
nswer
> for 8.3 in any case; I am not seeing a real fix that I'd care to risk
> back-patching. (Note that this is not exactly trivial in itself, since
> then vacuum.c would need at least some minimal ability to deal with
> LP_REDIRECT entries.)
>
> r
On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
>
> > The idea that's becoming attractive to me while contemplating the
> > multiple-maps problem is that we should adopt something similar to
> > the old Mac OS idea of multiple "forks" in a relation. In addition
> > to
A question to all pg hackers
Is anybody working on adding pipelining to set returning functions.
How much effort would it take ?
Where should I start digging ?
BACKGROUND:
AFAICS , currently set returning functions materialise their results
before returning, as seen by this simple test:
hannu
On Tue, 2008-04-08 at 09:33 +0100, Heikki Linnakangas wrote:
> The last thread about Free Space Map evolved into discussion about
> whether the FSM and other kinds of auxiliary data should be stored
> within the heap pages, in "map forks", or auxiliary relfilenodes
> attached to the relation. I
On Tue, 2008-04-08 at 12:26 +0300, Hannu Krosing wrote:
> Probably we could do without sparse files, if we find an efficient way
> to compute the "add order" of leaf and parent pages for above algorithm.
if we always add only the minimal needed set of parents then the order
wil
On Tue, 2008-04-08 at 13:38 +0300, Hannu Krosing wrote:
> On Tue, 2008-04-08 at 12:26 +0300, Hannu Krosing wrote:
>
> > Probably we could do without sparse files, if we find an efficient way
> > to compute the "add order" of leaf and parent pages for above algorithm
On Wed, 2008-04-09 at 10:17 +0530, Pavan Deolasee wrote:
> On Wed, Apr 9, 2008 at 12:22 AM, Heikki Linnakangas
> <[EMAIL PROTECTED]> wrote:
>
> >
> > Well, if you add the higher levels, we're no longer talking about O(1), but
> > O(log n) (for a pretty steep logarithm), just like my proposal.
>
On Wed, 2008-04-09 at 18:33 +0530, Ashish Sharma wrote:
> Hi,
>
> The setup in question includes PostGRESQL v8.2.4, Java based web
> servers and MS.NET based web servers. Following is the fuzzy
> situation:
>
> 1. Our SQL queries run very fast using PSQL (both, from the
> server as well as
On Wed, 2008-04-09 at 21:09 +0300, Heikki Linnakangas wrote:
> Hannu Krosing wrote:
> > Saving 1 byte is an atomic op
>
> Unfortunately, it's not. Most if not all modern CPUs will perform one
> byte modification as "load word" + "modify word" + &qu
> BTW, I'm pretty sure I have figured out the method for storing minimal
> required binary tree as an array, where adding each page adds exactly
> one upper node. The node added is often not the immediate parent, but is
> always the one needed for covering all nodes.
>
> I just have to write it u
On Fri, 2008-04-11 at 10:57 +0200, Hans-Juergen Schoenig wrote:
> Hannu Krosing wrote:
> > A question to all pg hackers
> >
> > Is anybody working on adding pipelining to set returning functions.
> >
> > How much effort would it take ?
> >
> > Where
On Tue, 2008-04-22 at 00:24 +0100, Simon Riggs wrote:
> On Mon, 2008-04-21 at 16:38 -0400, A.M. wrote:
>
> > "MERGE will not invoke Rules." Does this imply that MERGE cannot be
> > used on views or that the resulting INSERTs or UPDATEs do not work on
> > views?
>
> Yes, that's right. Just li
On Tue, 2008-04-29 at 16:01 -0400, Aidan Van Dyk wrote:
> Most of my published applications *are* simple, and I tend to
> consolidate as much of my "business logic" in the database as possible
> and a "known" set of queries shared by all the related apps, relying
> heavily on view, triggers, and
On Thu, 2008-05-08 at 00:41 -0400, Tom Lane wrote:
> Tino Wildenhain <[EMAIL PROTECTED]> writes:
> > I may be wrong but my feeling is, not to much weirdness in the core
> > please :)
>
> +1 ... we have wasted more than enough man-hours trying to get the magic
> "serial" type to play nicely. If I
On Sun, 2008-05-18 at 16:00 -0400, Andrew Dunstan wrote:
> I am working on moving the notification buffer into shared memory as
> previously discussed. Since pg_listener will no longer exist, I think we
> need to provide a couple of information functions.
>
> I suggest:
>
> pg_listened_events(o
On Sun, 2008-05-18 at 22:17 -0700, David Fetter wrote:
> On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
> > "Zoltan Boszormenyi" <[EMAIL PROTECTED]> writes:
> > > Also, it seems there are no infinite recursion detection:
> > >
> > > # with recursive x(level, parent, child) as (
> >
On Mon, 2008-05-19 at 21:53 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >>> trigger on "prepare", "commit", "rollback", "savepoint",
> >>
> >> This is a sufficiently frequently asked question that I wish someone
> >> would add an entry to the FAQ about it, or add it to th
On Tue, 2008-05-20 at 12:09 +0200, Fabien COELHO wrote:
> As for replication, I was naively thinking of using BEFORE PREPARE to
> forward a prepare and possibly fail in the master if the slave fails, and
> then an AFTER PREPARE or BEFORE COMMIT/ROLLBACK PREPARE would forward the
> final COMMIT/
On Wed, 2008-05-14 at 23:29 +0300, Marko Kreen wrote:
> There are few code beautification ideas on which I'd like to
> get feedback from wider audience:
>
> - Drop CONNECT statement. This was added to make creating
> simple dblink style calls easier, but actually its not
> maintainable compa
On Tue, 2008-05-20 at 13:36 +0200, Fabien COELHO wrote:
> > or running data modifications through pl/proxy functions where
> > partitioning function always returns two partitions
>
> I don't think that pl/proxy takes care of 2PC semantics in any useful way.
>
> Possibly something like pgpool co
On Wed, 2008-05-21 at 10:40 +0200, Andreas Pflug wrote:
> Florian Pflug wrote:
> >
> > But maybe you could store the whitespace appearing before (or after?)
> > a token in the parse tree that is stored for a view. That might not
> > allow reconstructing the *precise* statement, but at least the
On Wed, 2008-05-21 at 18:12 +0200, Pavel Stehule wrote:
> Hello
...
> In my proposal I don't create any default variables. Result type is
> only virtual - I don't need write it to system directory. I thing it's
> better than using some specific predeclared type as RESULTTYPE OR
> RESULTSET.
How
On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> >> In my proposal I don't create any default variables. Result type is
> >> only virtual - I don't need write it to system dir
On Wed, 2008-05-21 at 23:06 +0200, Pavel Stehule wrote:
> 2008/5/21 Hannu Krosing <[EMAIL PROTECTED]>:
> > On Wed, 2008-05-21 at 13:31 -0400, Merlin Moncure wrote:
> >> On Wed, May 21, 2008 at 1:28 PM, Hannu Krosing <[EMAIL PROTECTED]> wrote:
> >> >&
On Wed, 2008-05-28 at 22:45 +0100, Simon Riggs wrote:
> On Wed, 2008-05-28 at 16:28 -0400, Tom Lane wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > "Tom Lane" <[EMAIL PROTECTED]> writes:
> > >> This is expected to take lots of memory because each row-requiring-check
> > >> generates an e
On Wed, 2008-05-28 at 19:11 -0400, Mike wrote:
>
> Can somebody point to the most logical place in the code to intercept
> the WAL writes? (just a rough direction would be enough)- or if this
> doesn’t make sense at all, another suggestion on where to get the
> data?
I don't think that intercep
On Thu, 2008-05-29 at 13:37 -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Thu, May 29, 2008 at 08:46:22AM -0700, Joshua D. Drake wrote:
> >> The only question I have is... what does this give us that PITR
> >> doesn't give us?
>
> > It looks like a wrapper for PITR to me
On Fri, 2008-05-30 at 15:16 -0400, Robert Treat wrote:
> On Friday 30 May 2008 01:10:20 Tom Lane wrote:
> > Greg Smith <[EMAIL PROTECTED]> writes:
> > > I fully accept that it may be the case that it doesn't make technical
> > > sense to tackle them in any order besides sync->read-only slaves becau
On Thu, 2008-05-29 at 12:05 -0700, Robert Hodges wrote:
> Hi everyone,
>
> First of all, I’m absolutely delighted that the PG community is
> thinking seriously about replication.
>
> Second, having a solid, easy-to-use database availability solution
> that works more or less out of the box wou
On Thu, 2008-05-29 at 23:37 +0200, Mathias Brossard wrote:
> I pointed out that the NTT solution is synchronous because Tom said in
> the first part of his email that:
>
> > In practice, simple asynchronous single-master-multiple-slave
> > replication covers a respectable fraction of use cases
On Mon, 2008-06-02 at 22:40 +0200, Andreas 'ads' Scherbaum wrote:
> On Mon, 02 Jun 2008 11:52:05 -0400 Chris Browne wrote:
>
> > [EMAIL PROTECTED] ("Andreas 'ads' Scherbaum") writes:
> > > On Thu, 29 May 2008 23:02:56 -0400 Andrew Dunstan wrote:
> > >
> > >> Well, yes, but you do know about archiv
On Wed, 2008-06-04 at 10:40 -0400, Tom Lane wrote:
> "Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> > Hmm, WAL version compatibility is an interesting question. Most minor
> > releases hasn't changed the WAL format, and it would be nice to allow
> > running different minor versions in the mas
atement should still behave
> according to SELECT isolation/snapshot rules. But when I guess about the
> standard, I'm usually wrong.
>
--
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Cons
On Tue, 2009-02-03 at 08:40 -0500, Andrew Dunstan wrote:
>
> Hannu Krosing wrote:
> > Actually we came up with a solution to this - use filesystem level
> > snapshots (like LVM2+XFS or ZFS), and redirect backends with
> > long-running queries to use fs snapsho
like, when you have page X in shared buffers, which version of
> page X is it, anyway?).
The idea was to switch file pointers inside the backend needing old
versions, (and then flush cache if needed) so the only bookkeeping you
need is which fs snapshots you need to keep and which can be release
On Tue, 2009-02-03 at 13:50 +, Gregory Stark wrote:
> Hannu Krosing writes:
>
> > Actually we came up with a solution to this - use filesystem level
> > snapshots (like LVM2+XFS or ZFS), and redirect backends with
> > long-running queries to use fs snapsho
On Tue, 2009-02-03 at 10:19 -0500, Robert Haas wrote:
> On Tue, Feb 3, 2009 at 9:40 AM, Simon Riggs wrote:
> > On Tue, 2009-02-03 at 09:14 -0500, Robert Haas wrote:
> >> I think _the_ solution is to notice when you're about to vacuum a page
> >> that is still visible to a running backend on the st
On Tue, 2009-02-03 at 14:28 +, Simon Riggs wrote:
> On Tue, 2009-02-03 at 08:40 -0500, Andrew Dunstan wrote:
> >
> > Hannu Krosing wrote:
> > > Actually we came up with a solution to this - use filesystem level
> > > snapshots (like LVM2+XFS or ZFS), and
On Wed, 2009-01-28 at 22:19 +0200, Heikki Linnakangas wrote:
> Tom Lane wrote:
...
> > Well, those unexpectedly cancelled queries could have represented
> > critical functionality too. I think this argument calls the entire
> > approach into question. If there is no safe setting for the parameter
ulting, Development, Support, Training
>503-667-4564 - http://www.commandprompt.com/
>The PostgreSQL Company, serving since 1997
>
--
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
shipping should be:
>
> I am master, my slave is here.
> I am slave, I understand my master is here.
> Here is our mutual authentication love token.
> Let congress begin.
>
> Anything more and we are being difficult for the sake of being
> difficult.
Actually I'd l
On Fri, 2009-02-27 at 12:21 -0800, Joshua D. Drake wrote:
> On Fri, 2009-02-27 at 22:17 +0200, Hannu Krosing wrote:
>
> > > Well VLDB is like 2% of what we need. If the above will remove all the
> > > B.S. currently associated with actually doing PITR (rsync, scp, nfs,
&g
Same as int field does not accept int[].
Or maybe we rather need separate xmldocument and xmlforest/xmlfragments
types in next releases and leave the "base" xml as it is but deprecated
due to inability to fix it without breaking backwards compatibility.
--
Hannu Krosing http://www.2ndQ
On Fri, 2009-02-27 at 16:37 -0500, Andrew Dunstan wrote:
>
> Hannu Krosing wrote:
> > On Thu, 2009-02-26 at 13:51 -0500, Robert Haas wrote:
> >
> >>> What I have proposed for 8.3 should not break a single case that currently
> >>> behaves usefully. I
601 - 700 of 1838 matches
Mail list logo
