On Wed, Jun 19, 2013 at 4:44 AM, Peter Eisentraut wrote:
> On Tue, 2013-06-18 at 12:32 +0200, Magnus Hagander wrote:
>> The CF app was and is specifically for dealing with CFs. Having it
>> deal with backpatches makes it, well, a bugtracker. It's not meant to
>> be that. If we want a bugtracker, t
On Wed, Jun 5, 2013 at 8:01 AM, Andres Freund wrote:
>
> Two patches attached:
> 1) add snappy to src/common. The integration needs some more work.
> 2) Combined patch that adds indirect tuple and snappy compression. Those
> coul be separated, but this is an experiment so far...
>
>
>
I took a look
On 2013-06-19 00:15:56 -0700, Hitoshi Harada wrote:
> On Wed, Jun 5, 2013 at 8:01 AM, Andres Freund wrote:
> >
> > Two patches attached:
> > 1) add snappy to src/common. The integration needs some more work.
> > 2) Combined patch that adds indirect tuple and snappy compression. Those
> > coul be se
2013/6/17 Josh Kupershmidt :
> On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule
> wrote:
>
>> I'll see - please, stay tuned to 9.4 first commitfest
>
> Hi Pavel,
> Just a reminder, I didn't see this patch in the current commitfest. I
> would be happy to spend some more time reviewing if you wish to
On 18 June 2013 22:57, Fujii Masao wrote:
> On Wed, Jun 19, 2013 at 2:40 AM, Simon Riggs wrote:
>> On 18 June 2013 17:10, Fujii Masao wrote:
>>> On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes wrote:
On Tuesday, May 21, 2013, Simon Riggs wrote:
>
> I worked up a small patch to support
On 18.06.2013 23:59, Alexander Korotkov wrote:
I would like to illustrate that on example. Imagine you have fulltext query
"rare_term& frequent_term". Frequent term has large posting tree while
rare term has only small posting list containing iptr1, iptr2 and iptr3. At
first we get iptr1 from po
Thank you.
> > This makes sense to me. I only lament the fact that this makes the
> > module a misnomer. Do we want to 1) rename the module (how
> > inconvenient), 2) create a separate module for this (surely not
> > warranted), or 3) accept it and move on?
Although I also feel uneasy with the
On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 18.06.2013 23:59, Alexander Korotkov wrote:
>
>> I would like to illustrate that on example. Imagine you have fulltext
>> query
>> "rare_term& frequent_term". Frequent term has large posting tree while
>>
On Wed, Jun 19, 2013 at 12:30 PM, Alexander Korotkov
wrote:
> On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com> wrote:
>
>> On 18.06.2013 23:59, Alexander Korotkov wrote:
>>
>>> I would like to illustrate that on example. Imagine you have fulltext
>>> query
>>> "rar
On 19.06.2013 11:30, Alexander Korotkov wrote:
On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas<
hlinnakan...@vmware.com> wrote:
On 18.06.2013 23:59, Alexander Korotkov wrote:
I would like to illustrate that on example. Imagine you have fulltext
query
"rare_term& frequent_term". Freque
On Wed, Jun 19, 2013 at 12:49 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 19.06.2013 11:30, Alexander Korotkov wrote:
>
>> On Wed, Jun 19, 2013 at 11:48 AM, Heikki Linnakangas<
>> hlinnakan...@vmware.com> wrote:
>>
>> On 18.06.2013 23:59, Alexander Korotkov wrote:
>>>
>>> I wo
On 19 June 2013 09:19, Kyotaro HORIGUCHI
wrote:
> It should useful in other aspects but it seems a bit complicated
> just to know about visibility bits for certain blocks.
With your current patch you can only see the visibility info for
blocks in cache, not for all blocks. So while you may think
On 2013-06-19 10:03:40 +0100, Simon Riggs wrote:
> On 19 June 2013 09:19, Kyotaro HORIGUCHI
> wrote:
>
> > It should useful in other aspects but it seems a bit complicated
> > just to know about visibility bits for certain blocks.
>
> With your current patch you can only see the visibility info
On 19 June 2013 10:15, Andres Freund wrote:
> On 2013-06-19 10:03:40 +0100, Simon Riggs wrote:
>> On 19 June 2013 09:19, Kyotaro HORIGUCHI
>> wrote:
>>
>> > It should useful in other aspects but it seems a bit complicated
>> > just to know about visibility bits for certain blocks.
>>
>> With your
Le mercredi 19 juin 2013 04:48:11, Peter Eisentraut a écrit :
> On Tue, 2013-06-18 at 15:52 +0200, Cédric Villemain wrote:
> > This allows for example to install hstore header and be able to
> > include them
> >
> > in another extension like that:
> > # include "contrib/hstore/hstore.h"
>
> Tha
Le mercredi 19 juin 2013 04:58:15, Peter Eisentraut a écrit :
> On Mon, 2013-06-17 at 19:00 +0200, Cédric Villemain wrote:
> > My only grief is to loose the perfect regression tests for PGXS those
> > contribs are.
>
> I think they are neither perfect nor regression tests. If we want
> tests, let
Hi,
I'm thinking of implementing an incremental backup tool for
PostgreSQL. The use case for the tool would be taking a backup of huge
database. For that size of database, pg_dump is too slow, even WAL
archive is too slow/ineffective as well. However even in a TB
database, sometimes actual modifie
Le jeudi 13 juin 2013 05:16:48, Peter Eisentraut a écrit :
> This has served no purpose except to
>
> 1. take up space
> 2. confuse users
> 3. produce broken external extension modules that take contrib as an
> example 4. break builds of PostgreSQL when users try to fix 3. by
> exporting USE_PGXS
On Tuesday, March 05, 2013 7:03 PM Heikki Linnakangas wrote:
> I spent some more time on this, and came up with the attached patch. It
> includes the changes I posted earlier, to use indexes instead of
> pointers in the hash table. In addition, it makes the hash table size
> variable, depending on
Hi Harada-san,
Thank you for the review.
I think that the parse tree has enough information to do this optimization and
that the easiest way to do it is to use the information, though I might not have
understand your comments correctly. So, I would like to fix the bug by simply
modifying t
On 19 June 2013 04:11, David Fetter wrote:
> On Tue, Jun 18, 2013 at 11:36:08AM +0100, Dean Rasheed wrote:
>> On 17 June 2013 06:33, David Fetter wrote:
>> >> Next revision of the patch, now with more stability. Thanks, Andrew!
>> >
>> > Rebased vs. git master.
>>
>> Here's my review of the WITH
From: "Jeff Janes"
On Tue, Jun 18, 2013 at 3:40 PM, MauMau wrote:
Really? Would the catcache be polluted with entries for nonexistent
tables? I'm surprised at this. I don't think it is necessary to speed up
the query that fails with nonexistent tables, because such queries should
be eliminat
Tatsuo,
* Tatsuo Ishii (is...@postgresql.org) wrote:
> I'm thinking of implementing an incremental backup tool for
> PostgreSQL. The use case for the tool would be taking a backup of huge
> database. For that size of database, pg_dump is too slow, even WAL
> archive is too slow/ineffective as well
On Wed, Jun 19, 2013 at 1:13 PM, Tatsuo Ishii wrote:
> I'm thinking of implementing an incremental backup tool for
> PostgreSQL. The use case for the tool would be taking a backup of huge
> database. For that size of database, pg_dump is too slow, even WAL
> archive is too slow/ineffective as well
Svenne Krap wrote:
> On 18-06-2013 22:18, Jeff Janes wrote:
>> In Danish, apparently 'AA' > 'WA', so two more rows show up.
>
> Yes of course
>
> We have three extra vowels following Z (namely Æ, Ø and Å) and
> for keyboard missing those essential keys we have an official
> alternate way to
On 2013-06-19 06:18:20 -0700, Kevin Grittner wrote:
> Svenne Krap wrote:
> > On 18-06-2013 22:18, Jeff Janes wrote:
>
> >> In Danish, apparently 'AA' > 'WA', so two more rows show up.
> >
> > Yes of course
> >
> > We have three extra vowels following Z (namely Æ, Ø and Å) and
> > for keyboa
On 2013-06-19 15:23:16 +0200, Andres Freund wrote:
> On 2013-06-19 06:18:20 -0700, Kevin Grittner wrote:
> > Svenne Krap wrote:
> > > On 18-06-2013 22:18, Jeff Janes wrote:
> >
> > >> In Danish, apparently 'AA' > 'WA', so two more rows show up.
> > >
> > > Yes of course
> > >
> > > We have
On 05/01/13 04:57, Fabien COELHO wrote:
>
> Add --throttle to pgbench
>
> Each client is throttled to the specified rate, which can be expressed in
> tps or in time (s, ms, us). Throttling is achieved by scheduling
> transactions along a Poisson-distribution.
>
> This is an update of the previ
I'm still getting the same sort of pauses waiting for input with your v11.
Alas.
This is a pretty frustrating problem; I've spent about two days so far trying
to narrow down how it happens. I've attached the test program I'm using. It
seems related to my picking a throttled rate that's cl
On 6/19/13 9:18 AM, Kevin Grittner wrote:
> Svenne Krap wrote:
>> On 18-06-2013 22:18, Jeff Janes wrote:
>
>>>In Danish, apparently 'AA' > 'WA', so two more rows show up.
>>
>> Yes of course
>>
>> We have three extra vowels following Z (namely Æ, Ø and Å) and
>> for keyboard missing those
On 6/19/13 5:55 AM, Cédric Villemain wrote:
> Le mercredi 19 juin 2013 04:48:11, Peter Eisentraut a écrit :
>> On Tue, 2013-06-18 at 15:52 +0200, Cédric Villemain wrote:
>>> This allows for example to install hstore header and be able to
>>> include them
>>>
>>> in another extension like that:
>>>
On 06/19/2013 10:06 AM, Peter Eisentraut wrote:
On 6/19/13 5:55 AM, Cédric Villemain wrote:
Le mercredi 19 juin 2013 04:48:11, Peter Eisentraut a écrit :
On Tue, 2013-06-18 at 15:52 +0200, Cédric Villemain wrote:
This allows for example to install hstore header and be able to
include them
in
On 6/13/13 1:37 AM, Dean Rasheed wrote:
> On 12 June 2013 23:01, Tom Lane wrote:
>> > Dean Rasheed writes:
>>> >> [ pg_relation_is_updatable.patch ]
>> >
>> > I've committed this with some modifications as mentioned. There is
>> > still room to debate exactly what
>> > information_schema.columns
Hi all,
I'm writing a foreign data wrapper in which i'm taking control of various
aspects of SELECT queries (such as join, order by, count, sum etc.).
Is it possible? for example, when trying to count(*), i see that pg
supplies an empty list of columns to select from, and probably does the
counti
On 6/7/13 2:57 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> I had a customer pulling their hair out today because they couldn't
>> login to their system. The error was consistently:
>
>> 2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
>> authentication failed for user "u
On 6/19/13 10:19 AM, Andrew Dunstan wrote:
> What are they going to be used for anyway? I rubbed up against this not
> too long ago. Things will blow up if you use stuff from the module and
> the module isn't already loaded.
See transforms.
--
Sent via pgsql-hackers mailing list (pgsql-hackers
Peter Eisentraut wrote:
> On 6/19/13 9:18 AM, Kevin Grittner wrote:
>> Does anyone object to the attached change, so that regression tests
>> pass when run in a Danish locale? I think it should be
>> back-patched to 9.2, where the test was introduced.
>
> Yes, that should be fixed. I wouldn't p
On 19 June 2013 15:22, Peter Eisentraut wrote:
> We still don't have any support for this in psql, do we?
>
No, but at least we now have an API that psql can use.
There are still a number of questions about the best way to display it in psql.
Should it be another column in \d+'s list of relation
On Wed, Jun 19, 2013 at 7:13 AM, Tatsuo Ishii wrote:
>
> For now, my idea is pretty vague.
>
> - Record info about modified blocks. We don't need to remember the
> whole history of a block if the block was modified multiple times.
> We just remember that the block was modified since the last
>
On Wed, Jun 19, 2013 at 4:49 AM, Etsuro Fujita
wrote:
> Hi Harada-san,
>
> ** **
>
> Thank you for the review.
>
> ** **
>
> I think that the parse tree has enough information to do this optimization
> and that the easiest way to do it is to use the information, though I might
> not have u
Le mercredi 19 juin 2013 18:20:11, Andrew Dunstan a écrit :
> On 06/19/2013 11:26 AM, Peter Eisentraut wrote:
> > On 6/19/13 10:19 AM, Andrew Dunstan wrote:
> >> What are they going to be used for anyway? I rubbed up against this not
> >> too long ago. Things will blow up if you use stuff from the
On 06/19/2013 11:26 AM, Peter Eisentraut wrote:
On 6/19/13 10:19 AM, Andrew Dunstan wrote:
What are they going to be used for anyway? I rubbed up against this not
too long ago. Things will blow up if you use stuff from the module and
the module isn't already loaded.
See transforms.
So you'
On 06/19/2013 12:32 PM, Cédric Villemain wrote:
Le mercredi 19 juin 2013 18:20:11, Andrew Dunstan a écrit :
On 06/19/2013 11:26 AM, Peter Eisentraut wrote:
On 6/19/13 10:19 AM, Andrew Dunstan wrote:
What are they going to be used for anyway? I rubbed up against this not
too long ago. Things
Peter Eisentraut writes:
> Looks pretty good, but the description of the parsetree field was
> obviously copied from somewhere else. I would fix it myself, but I
> don't know what kind of assurances we want to offer about what's in that
> field.
Oh, oops.
I think we should direct the reader to
Gražvydas Valeika writes:
> - create new database;
> - CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;
> - backup it;
> - create new database and restore it from this new backup.
>
> It produces 3 errors while executing these 3 statements:
This has been fixed by Joe Conway meanwhile.
On 6/19/13 11:50 AM, Dean Rasheed wrote:
> On 19 June 2013 15:22, Peter Eisentraut wrote:
>> We still don't have any support for this in psql, do we?
>>
>
> No, but at least we now have an API that psql can use.
>
> There are still a number of questions about the best way to display it in
> psq
> I'd imagine having a "CF" entry per release, so after a set of minor
> releases, the "CF" is closed.
How would we name these?
Also, what about patches for beta? Should we have a "beta" CF?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list
On 6/19/13 12:20 PM, Andrew Dunstan wrote:
> So you're saying to install extension headers, but into the main
> directory where we put server headers?
Yes, if we choose to install some extension headers, that is where we
should put them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Tuesday, June 18, 2013, Amit Kapila wrote:
> On Tuesday, June 18, 2013 12:18 AM Sawada Masahiko wrote:
> > On Sun, Jun 16, 2013 at 2:00 PM, Amit kapila
> >
> >
> > wrote:
> > > On Saturday, June 15, 2013 8:29 PM Sawada Masahiko wrote:
> > > On Sat, Jun 15, 2013 at 10:34 PM, Amit kapila
> > >
On 6/13/13 5:47 PM, Josh Berkus wrote:
>> 2. File name to store settings set by ALTER SYSTEM command is still
>> > persistent.auto.conf
> Why? Shouldn't it just be auto.conf? Or system.auto.conf?
>
> I prefer auto.conf, personally.
Well, not much about it is automatic, really. It's just set el
On 06/19/2013 10:48 AM, Peter Eisentraut wrote:
> On 6/13/13 5:47 PM, Josh Berkus wrote:
>>> 2. File name to store settings set by ALTER SYSTEM command is still
persistent.auto.conf
>> Why? Shouldn't it just be auto.conf? Or system.auto.conf?
>>
>> I prefer auto.conf, personally.
>
> Well,
On 19 June 2013 18:12, Peter Eisentraut wrote:
> On 6/19/13 11:50 AM, Dean Rasheed wrote:
>> On 19 June 2013 15:22, Peter Eisentraut wrote:
>>> We still don't have any support for this in psql, do we?
>>>
>>
>> No, but at least we now have an API that psql can use.
>>
>> There are still a number
On 6/19/13 1:49 PM, Josh Berkus wrote:
> On 06/19/2013 10:48 AM, Peter Eisentraut wrote:
>> On 6/13/13 5:47 PM, Josh Berkus wrote:
2. File name to store settings set by ALTER SYSTEM command is still
> persistent.auto.conf
>>> Why? Shouldn't it just be auto.conf? Or system.auto.conf?
>>>
On Jun 19, 2013 7:55 PM, "Peter Eisentraut" wrote:
>
> On 6/19/13 1:49 PM, Josh Berkus wrote:
> > On 06/19/2013 10:48 AM, Peter Eisentraut wrote:
> >> On 6/13/13 5:47 PM, Josh Berkus wrote:
> 2. File name to store settings set by ALTER SYSTEM command is still
> > persistent.auto.conf
> >>
On 6/7/13 12:14 AM, Amit Kapila wrote:
> I will change the patch as per below syntax if there are no objections:
>
> ALTER SYSTEM SET configuration_parameter {TO | =} {value, | 'value'};
I do like using ALTER SYSTEM in general, but now that I think about it,
the 9.3 feature to create global sett
The use case of the option is to be able to generate a continuous gentle
load for functional tests, eg in a practice session with students or for
testing features on a laptop.
Why does this need two option formats (-H and --throttle)?
On the latest version it is --rate and -R.
Because you m
number of transactions actually processed: 301921
Just a thought before spending too much time on this subtle issue.
The patch worked reasonnably for 301900 transactions in your above run,
and the few last ones, less than the number of clients, show strange
latency figures which suggest tha
On 06/19/13 14:34, Fabien COELHO wrote:
>
>>> The use case of the option is to be able to generate a continuous gentle
>>> load for functional tests, eg in a practice session with students or for
>>> testing features on a laptop.
>>
>> Why does this need two option formats (-H and --throttle)?
>
On 6/19/13 11:02 AM, Claudio Freire wrote:
On Wed, Jun 19, 2013 at 7:13 AM, Tatsuo Ishii wrote:
For now, my idea is pretty vague.
- Record info about modified blocks. We don't need to remember the
whole history of a block if the block was modified multiple times.
We just remember that t
On Wed, Jun 19, 2013 at 8:54 PM, Alvaro Herrera
wrote:
> Josh Berkus wrote:
>>
>> > I'd imagine having a "CF" entry per release, so after a set of minor
>> > releases, the "CF" is closed.
>>
>> How would we name these?
>>
>> Also, what about patches for beta? Should we have a "beta" CF?
>
> Don't
Le mercredi 19 juin 2013 18:48:21, Andrew Dunstan a écrit :
> On 06/19/2013 12:32 PM, Cédric Villemain wrote:
> > Le mercredi 19 juin 2013 18:20:11, Andrew Dunstan a écrit :
> >> On 06/19/2013 11:26 AM, Peter Eisentraut wrote:
> >>> On 6/19/13 10:19 AM, Andrew Dunstan wrote:
> What are they go
On 06/19/2013 08:24 AM, Peter Eisentraut wrote:
I think it's intentional that we don't tell the *client* that level of
detail. I could see emitting a log message about it, but it's not clear
whether that will help an unsophisticated user.
Usually, when I log in somewhere and the password is
Magnus Hagander wrote:
> On Jun 19, 2013 7:55 PM, "Peter Eisentraut" wrote:
> > generated_by_server.conf
>
> System.conf?
alter_system.conf ?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mai
On 6/17/13 5:31 PM, Alvaro Herrera wrote:
> This is a large patch. Do you intend to push the whole thing as a
> single commit, or split it?
I thought about splitting it up, but I didn't find a reasonable way to
do it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On 06/18/2013 02:25 AM, Markus Wanner wrote:
On 06/16/2013 06:02 PM, Joshua D. Drake wrote:
Instead of pushing extra info to the logs I decided that we could
without giving away extra details per policy. I wrote the error message
in a way that tells the most obvious problems, without admitting
Josh Berkus wrote:
>
> > I'd imagine having a "CF" entry per release, so after a set of minor
> > releases, the "CF" is closed.
>
> How would we name these?
>
> Also, what about patches for beta? Should we have a "beta" CF?
Don't we have the Open Items wiki page for those? Seems to work well
Peter Eisentraut wrote:
> On 6/19/13 12:20 PM, Andrew Dunstan wrote:
> > So you're saying to install extension headers, but into the main
> > directory where we put server headers?
>
> Yes, if we choose to install some extension headers, that is where we
> should put them.
The question of the nam
> This has been fixed by Joe Conway meanwhile.
>
Nice,
thaks!
On Wed, Jun 19, 2013 at 3:54 PM, Jim Nasby wrote:
> On 6/19/13 11:02 AM, Claudio Freire wrote:
>>
>> On Wed, Jun 19, 2013 at 7:13 AM, Tatsuo Ishii
>> wrote:
>>>
>>>
>>> For now, my idea is pretty vague.
>>>
>>> - Record info about modified blocks. We don't need to remember the
>>>whole histor
Peter Eisentraut writes:
> We could do something like
>
> PG_CONFIG = fake_intree_pg_config
> PGXS := $(shell $(PG_CONFIG) --pgxs)
> include $(PGXS)
There's something to that idea. Of course we would need to offer a
comment about the PG_CONFIG game and propose something else for real
world extens
Because you may want to put something very readable and understandable in
a script and like long options, or have to type it interactively every day
in a terminal and like short ones. Most UNIX commands include both kind.
Would it make sense then to add long versions for all the other standard
This probably is nit-picking, but it interests me in terms of how the
language is used and understood.
On 06/19/2013 08:55 PM, Joshua D. Drake wrote:
> I believe it actually can. The error message that is returned for a bad
> password, bad user or expired password is all the same. Which is why I
>
test=# select '100'::real + '5'::real;
?column?
--
1e+06
(1 row)
test=# select '100'::real + '6'::real;
?column?
-
1.1e+06
(1 row)
test=# select '0.1'::real + 0.0;
?column?
---
0.10001490116
(1 row)
--
Sent via pgsql-
On 06/19/2013 03:52 PM, Dimitri Fontaine wrote:
Peter Eisentraut writes:
We could do something like
PG_CONFIG = fake_intree_pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
There's something to that idea. Of course we would need to offer a
comment about the PG_CONFIG game and p
On 06/19/2013 01:18 PM, Markus Wanner wrote:
"Authentication failed or password has expired for user \"%s\""
Authentication failed covers any combination of a username/password
being wrong and obviously password expired covers the other.
Works for me. Considering the password to be the thing
Andrew Dunstan writes:
> Not true - you're forgetting there is no pgxs for MSVC builds.
Oh, indeed, totally forgot about that.
> If we're going to enable building of contrib modules using pgxs but without
> an install we will make targets for that, and buildfarm support.
So we would need some k
Le mercredi 19 juin 2013 21:06:23, Alvaro Herrera a écrit :
> Peter Eisentraut wrote:
> > On 6/19/13 12:20 PM, Andrew Dunstan wrote:
> > > So you're saying to install extension headers, but into the main
> > > directory where we put server headers?
> >
> > Yes, if we choose to install some extensi
Sorry folks. That email was misdirected by accident.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 19-06-2013 17:41, Kevin Grittner wrote:
>
> OK, pushed without the comment.
>
Works like a charm :)
Svenne
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQI5BAE
On 06/19/2013 04:47 PM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Not true - you're forgetting there is no pgxs for MSVC builds.
Oh, indeed, totally forgot about that.
If we're going to enable building of contrib modules using pgxs but without
an install we will make targets for that,
Le mercredi 19 juin 2013 22:22:22, Andrew Dunstan a écrit :
> On 06/19/2013 03:52 PM, Dimitri Fontaine wrote:
> > Peter Eisentraut writes:
> >> We could do something like
> >>
> >> PG_CONFIG = fake_intree_pg_config
> >> PGXS := $(shell $(PG_CONFIG) --pgxs)
> >> include $(PGXS)
> >
> > There's so
* Claudio Freire (klaussfre...@gmail.com) wrote:
> I don't see how this is better than snapshotting at the filesystem
> level. I have no experience with TB scale databases (I've been limited
> to only hundreds of GB), but from my limited mid-size db experience,
> filesystem snapshotting is pretty m
On Wed, Jun 19, 2013 at 8:41 AM, Kevin Grittner wrote:
> Peter Eisentraut wrote:
> > On 6/19/13 9:18 AM, Kevin Grittner wrote:
>
> >> Does anyone object to the attached change, so that regression tests
> >> pass when run in a Danish locale? I think it should be
> >> back-patched to 9.2, where t
On Thu, Feb 7, 2013 at 12:01 PM, Andres Freund wrote:
> On 2013-02-07 11:15:46 -0800, Jeff Janes wrote:
> >
> > Does anyone have suggestions on how to hack the system to make it
> > fast-forward the current transaction id? It would certainly make
> > testing this kind of thing faster if I could ma
On Wed, Jun 19, 2013 at 6:20 PM, Stephen Frost wrote:
> * Claudio Freire (klaussfre...@gmail.com) wrote:
>> I don't see how this is better than snapshotting at the filesystem
>> level. I have no experience with TB scale databases (I've been limited
>> to only hundreds of GB), but from my limited m
Jeff Janes wrote:
> Kevin Grittner wrote:
>> Peter Eisentraut wrote:
>>> On 6/19/13 9:18 AM, Kevin Grittner wrote:
>>
>>
Does anyone object to the attached change, so that regression tests
pass when run in a Danish locale? I think it should be
back-patched to 9.2, where the test
Claudio Freire escribió:
> On Wed, Jun 19, 2013 at 6:20 PM, Stephen Frost wrote:
> > * Claudio Freire (klaussfre...@gmail.com) wrote:
> >> I don't see how this is better than snapshotting at the filesystem
> >> level. I have no experience with TB scale databases (I've been limited
> >> to only hun
Josh Berkus writes:
> True, but can you think of a better word to mean "don't edit this by hand"?
The file name is not nearly as important for that as putting in a
header comment "# Don't edit this file by hand."
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Wed, Jun 19, 2013 at 7:18 PM, Alvaro Herrera
wrote:
> If you have the two technologies, you could teach them to work in
> conjunction: you set up WAL replication, and tell the WAL compressor to
> prune updates for high-update tables (avoid useless traffic), then use
> incremental backup to back
>> I'm thinking of implementing an incremental backup tool for
>> PostgreSQL. The use case for the tool would be taking a backup of huge
>> database. For that size of database, pg_dump is too slow, even WAL
>> archive is too slow/ineffective as well. However even in a TB
>> database, sometimes actu
On Wed, Jun 19, 2013 at 7:39 PM, Tatsuo Ishii wrote:
>>> I'm thinking of implementing an incremental backup tool for
>>> PostgreSQL. The use case for the tool would be taking a backup of huge
>>> database. For that size of database, pg_dump is too slow, even WAL
>>> archive is too slow/ineffective
On Wed, Jun 19, 2013 at 11:55 AM, Joshua D. Drake wrote:
>
> On 06/18/2013 02:25 AM, Markus Wanner wrote:
>
>>
>> On 06/16/2013 06:02 PM, Joshua D. Drake wrote:
>>
>>>
>>>
>> How about:
>> "password authentication failed or account expired for user \"%s\""
>>
>> It's a bit longer, but sounds more
>>> I'm trying to figure out how that's actually different from WAL..? It
>>> sounds like you'd get what you're suggesting with simply increasing the
>>> checkpoint timeout until the WAL stream is something which you can keep
>>> up with. Of course, the downside there is that you'd have to replay
* Tatsuo Ishii (is...@postgresql.org) wrote:
> Yeah, at first I thought using WAL was a good idea. However I realized
> that the problem using WAL is we cannot backup unlogged tables because
> they are not written to WAL.
Unlogged tables are also nuked on recovery, so I'm not sure why you
think a
> * Tatsuo Ishii (is...@postgresql.org) wrote:
>> Yeah, at first I thought using WAL was a good idea. However I realized
>> that the problem using WAL is we cannot backup unlogged tables because
>> they are not written to WAL.
>
> Unlogged tables are also nuked on recovery, so I'm not sure why yo
On Wed, Jun 19, 2013 at 4:47 PM, Simon Riggs wrote:
> On 18 June 2013 22:57, Fujii Masao wrote:
>> On Wed, Jun 19, 2013 at 2:40 AM, Simon Riggs wrote:
>>> On 18 June 2013 17:10, Fujii Masao wrote:
On Tue, Jun 18, 2013 at 1:06 PM, Jeff Janes wrote:
> On Tuesday, May 21, 2013, Simon Rig
* Tatsuo Ishii (is...@postgresql.org) wrote:
> > * Tatsuo Ishii (is...@postgresql.org) wrote:
> >> Yeah, at first I thought using WAL was a good idea. However I realized
> >> that the problem using WAL is we cannot backup unlogged tables because
> >> they are not written to WAL.
> >
> > Unlogged
> * Tatsuo Ishii (is...@postgresql.org) wrote:
>> > * Tatsuo Ishii (is...@postgresql.org) wrote:
>> >> Yeah, at first I thought using WAL was a good idea. However I realized
>> >> that the problem using WAL is we cannot backup unlogged tables because
>> >> they are not written to WAL.
>> >
>> > U
> On Wed, Jun 19, 2013 at 6:20 PM, Stephen Frost wrote:
>> * Claudio Freire (klaussfre...@gmail.com) wrote:
>>> I don't see how this is better than snapshotting at the filesystem
>>> level. I have no experience with TB scale databases (I've been limited
>>> to only hundreds of GB), but from my lim
* Tatsuo Ishii (is...@postgresql.org) wrote:
> I don't think using rsync (or tar or whatever general file utils)
> against TB database for incremental backup is practical. If it's
> practical, I would never propose my idea.
You could use rsync for incremental updates if you wanted, it'd
certainly
1 - 100 of 127 matches
Mail list logo
