On 19 October 2011 05:20, Tom Lane wrote:
> Peter Eisentraut writes:
>> I wouldn't add extra special checks for that. It might not be
>> completely unreasonable to have a standby that no one can connect to,
>> for example.
>
> Well, you couldn't monitor its state then, so I don't find that examp
On Mon, Oct 24, 2011 at 10:05 AM, Tom Lane wrote:
>> as it seems to me that any
>> client that is paranoid enough to care about sync rep had better
>> already be handling the case of a connection loss during commit.
>
> Agreed, but that is a problem that by definition we can't help with.
> Also, t
On Mon, Oct 24, 2011 at 16:12, Jaime Casanova wrote:
> On Mon, Oct 24, 2011 at 7:40 AM, Magnus Hagander wrote:
>>
>>> synchronous_standby_names='*' is prone to such confusion in general, but it
>>> seems that it's particularly surprising if a running pg_basebackup lets a
>>> commit in synchronous
Hi!
On Mon, Oct 17, 2011 at 12:38 PM, Jeff Davis wrote:
> > I started implementing subtype_diff, and I noticed that it requires
> > defining an extra function for each range type. Previously, the numeric
> > types could just use a cast, which was convenient for user-defined range
> > types.
> >
On Mon, Sep 12, 2011 at 11:53 AM, Alexey Klyukin
wrote:
> This works in 9.1, but not in HEAD:
>
> CREATE TABLE parent(id INTEGER, CONSTRAINT id_check CHECK(id>1));
> CREATE TABLE child() INHERITS(parent);
>
> ALTER TABLE ONLY parent DROP CONSTRAINT id_check;
>
> I'm getting:
> ERROR: relation 164
On Fri, Sep 23, 2011 at 4:05 PM, Dan McGee wrote:
> On Fri, Sep 23, 2011 at 2:49 PM, Robert Haas wrote:
>> On Mon, Sep 19, 2011 at 4:36 PM, Dan McGee wrote:
>>> [ patch ]
>>
>> I suppose it's Tom who really needs to comment on this, but I'm not
>> too enthusiastic about this approach. Duplicati
On 24.10.2011 15:29, Fujii Masao wrote:
+
+
+ Copy the pg_control file from the cluster directory to the global
+ sub-directory of the backup. For example:
+
+ cp $PGDATA/global/pg_control /mnt/server/backupdir/global
+
+
+
Why is this step required? The control fi
On Sun, Oct 23, 2011 at 6:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, there is a general problem that anything which throws an ERROR
>> too late in the commit path is Evil; and sync rep makes that worse to
>> the extent that it adds more stuff late in the commit path, but it
>> didn't i
On 24.10.2011 15:29, Fujii Masao wrote:
In your patch, FPW is always WAL-logged at startup even when FPW has
not been changed since last shutdown. I don't think that's required.
I changed the recovery code so that it keeps track of last FPW indicated
by WAL record. Then, at end of startup, if tha
On Mon, Oct 24, 2011 at 4:57 AM, Omar Bettin
wrote:
> I have tried 9.1.1 win64 version and when I am trying to declare a cursor
> for a very large view (lot of joins and aggregate functions),
>
> postgres is using around 3GB of memory and the query never returns.
Hmm. A 59-table join is pretty e
...sorry guys...
was a misconfiguration of database.
9.1.1 is working good.
is ~4% faster than 9.0.5 for same query.
Thanks a lot.
Regards
-Messaggio originale-
Da: Pavel Stehule [mailto:pavel.steh...@gmail.com]
Inviato: lunedì 24 ottobre 2011 12:13
A: Omar Bettin
Cc: pgsql-hacker
On Mon, Oct 24, 2011 at 10:25 AM, Euler Taveira de Oliveira
wrote:
> On 24-10-2011 10:57, Robert Haas wrote:
>>
>> I think the main reason why vacuumlo is a contrib module rather than
>> in core is that it is just a heuristic, and it might not be what
>> everyone wants to do. You could store a bu
Hi Tom,
...are about two hours I am trying to communicate that the problem has been
solved, but I do not see the messages in the mailing list...
Anyway,
the problems was a bad installation of database (pgsql functions).
9.1.1 is working good.
is 4% to 8% faster than 9.0.5.
Thanks a lot to ever
On Mon, Oct 24, 2011 at 11:33 AM, Heikki Linnakangas
wrote:
> On 24.10.2011 15:29, Fujii Masao wrote:
>>
>> In your patch, FPW is always WAL-logged at startup even when FPW has
>> not been changed since last shutdown. I don't think that's required.
>> I changed the recovery code so that it keeps t
"Omar Bettin" writes:
> I have tried 9.1.1 win64 version and when I am trying to declare a cursor
> for a very large view (lot of joins and aggregate functions),
> postgres is using around 3GB of memory and the query never returns.
Could we see a self-contained test case? I'm not about to try t
Euler Taveira de Oliveira writes:
> The main point of autovacuum is maintenance tasks. Currently, it executes
> VACUUM and ANALYZE commands. I want to propose that we incorporate vacuumlo
> functionality into it.
I'm not terribly thrilled with that because (a) large objects seem like
mostly a l
Robert Haas writes:
> On Sun, Oct 23, 2011 at 6:34 PM, Tom Lane wrote:
>> BTW, it strikes me that if we want to do something about that, it ought
>> to be possible; but it has to be built into error handling, not a
>> localized hack for sync rep.
> I actually think that emitting a NOTICE or WARN
On Mon, Oct 24, 2011 at 13:46, Heikki Linnakangas
wrote:
>> + /*
>> + * Looks like an xlog file. Parse it's position.
>
> s/it's/its/
>
>> + */
>> + if (sscanf(dirent->d_name, "%08X%08X%08X", &tli, &log,
>> &seg) != 3)
>> + {
On Sun, Oct 23, 2011 at 7:01 PM, Jeff Janes wrote:
> On Fri, Oct 21, 2011 at 12:52 PM, Robert Haas wrote:
>>
>> Also, this line is kind of expensive:
>>
>> if (!visibilitymap_test(scandesc->heapRelation,
>> ItemPointerGetBlockNumber(tid),
>>
On Mon, Oct 24, 2011 at 7:40 AM, Magnus Hagander wrote:
>
>> synchronous_standby_names='*' is prone to such confusion in general, but it
>> seems that it's particularly surprising if a running pg_basebackup lets a
>> commit in synchronous replication to proceed. Maybe we just need a warning
>> in
+ /*
+* Looks like an xlog file. Parse it's position.
s/it's/its/
+*/
+ if (sscanf(dirent->d_name, "%08X%08X%08X", &tli, &log, &seg) !=
3)
+ {
+ fprintf(stderr, _("%s: could not parse xlog filename
On Mon, Oct 24, 2011 at 01:26, Tom Lane wrote:
> Andreas Karlsson writes:
>> Thanks for cleaning up the code to some sanity, I should have done so
>> myself when I noticed the problem.
>
>> A new version is attached.
>
> Committed with minor adjustments --- I didn't see any need to make this
> wa
On Fri, Oct 21, 2011 at 12:01 PM, Robert Haas wrote:
> On Thu, Oct 20, 2011 at 9:51 PM, Fujii Masao wrote:
>> On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas wrote:
>>> OK, so this is an artifact of the changes to make libpq communication
>>> bidirectional. But I'm still confused about where the e
On Mon, Oct 24, 2011 at 12:56 AM, Euler Taveira de Oliveira
wrote:
> The main point of autovacuum is maintenance tasks. Currently, it executes
> VACUUM and ANALYZE commands. I want to propose that we incorporate vacuumlo
> functionality into it. While dealing with large objects (LO), we have lo
>
On 24/10/11 10:57, Omar Bettin wrote:
>
> [monster query]
I see that your problem is already solved, but incidentially I'm working
on a join order planning module and I'm looking for real-life examples
of humongous queries like that to benchmark against them.
Any chance you could share the schem
Hi All,
I have not been able to reproduce this error, but wanted to report this
in case it might be useful.
Commit -id: 0f39d5050dc0dce99258381f33f1832c437aff85
Configure options:
--prefix=/mnt/storage/gurjeet/dev/builds//master/db --enable-debug
--enable-cassert CFLAGS=-O0 --ena
...sorry guys...
was a bad configuration of database.
9.1.1 is working good.
is 4% to 8% faster than 9.0.5.
Thanks a lot.
Regards
Omar
P.s.
attached EXPLAIN
>Hmm. A 59-table join is pretty enormous
and is not the biggest, basically are delivery notes for one day seen in
vertical.
--
S
On Mon, Sep 26, 2011 at 10:37, Magnus Hagander wrote:
> On Sun, Sep 25, 2011 at 15:06, Dean Rasheed wrote:
>> On 24 September 2011 11:59, Magnus Hagander wrote:
>>> TABLE tab completion in psql only completes to tables, not views. but
>>> the TABLE command works fine for both tables and views (a
2011/10/24 Omar Bettin :
> ...sorry guys...
>
> was a bad configuration of database.
>
> 9.1.1 is working good.
>
> is 4% to 8% faster than 9.0.5.
>
> Thanks a lot.
>
> Regards
>
> Omar
>
> P.s.
> attached EXPLAIN
>
attachment is missing
Pavel
>
>>Hmm. A 59-table join is pretty enormous
>
> an
Hello
please, send a result of explain analyze on 9.1.1 and older
please, use http://explain.depesz.com/
Regards
Pavel Stehule
2011/10/24 Omar Bettin :
> Hello,
>
>
>
> I have tried 9.1.1 win64 version and when I am trying to declare a cursor
> for a very large view (lot of joins and aggregate
Gurjeet Singh writes:
> Starting from line 89 of terminal1.txt we see this snippet:
> postgres=# rollback;
> ROLLBACK
> postgres=# begin TRANSACTION ;
> BEGIN
> postgres=# set transaction snapshot '02C8-1';
> ERROR: SET TRANSACTION SNAPSHOT must be called before any query
> postgres=# ro
On 17.10.2011 01:09, Jeff Davis wrote:
On Sat, 2011-10-15 at 01:46 +0300, Heikki Linnakangas wrote:
* The binary i/o format includes the length of the lower and upper
bounds twice, once explicitly in range_send, and second time within the
send-function of the subtype. Seems wasteful.
Any ideas
Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011:
> Starting from line 89 of terminal1.txt we see this snippet:
>
> postgres=# rollback;
> ROLLBACK
> postgres=# begin TRANSACTION ;
> BEGIN
> postgres=# set transaction snapshot '02C8-1';
> ERROR: SET TRANSACTION SN
On 24-10-2011 10:57, Robert Haas wrote:
I think the main reason why vacuumlo is a contrib module rather than
in core is that it is just a heuristic, and it might not be what
everyone wants to do. You could store a bunch of large objects in the
database and use the returned OIDs to generate links
Hi,
Since the data are of third parties, will prepare a database suitable for the
purpose.
In any case, the compressed backup will be around 20 MB.
Regards,
Omar Bettin
-Messaggio originale-
Da: Jan Urbański [mailto:wulc...@wulczer.org]
Inviato: lunedì 24 ottobre 2011 18:56
A: Omar B
Robert Haas writes:
>> [ oom_score_adj business ]
> Did we do anything about this? Anyone else have an opinion on what
> ought to be done?
I held off doing anything because it didn't seem like we had consensus.
OTOH, it may well be that it's not important enough to demand real
consensus, and he
On 24-10-2011 11:36, Tom Lane wrote:
Euler Taveira de Oliveira writes:
The main point of autovacuum is maintenance tasks. Currently, it executes
VACUUM and ANALYZE commands. I want to propose that we incorporate vacuumlo
functionality into it.
I'm not terribly thrilled with that because (a) l
On 24/10/11 19:16, Omar Bettin wrote:
> Hi,
>
> Since the data are of third parties, will prepare a database suitable for the
> purpose.
> In any case, the compressed backup will be around 20 MB.
If you are able to prepare a database dump that doesn't contain private
data, it would be awesome.
Tom Lane wrote:
> It might be that it'd work to deal with this by reducing the
> reported strength of all such cases from ERROR to WARNING. Not
> sure that that's a good idea, but it might work.
Throwing an error on commit of a transaction when its work has
actually been persisted seems as ba
On 19.10.2011 17:58, Simon Riggs wrote:
On Wed, Oct 19, 2011 at 3:29 PM, Fujii Masao wrote:
On Wed, Oct 19, 2011 at 9:45 PM, Robert Haas wrote:
I don't really see any reason to break the monitoring view just
because we did some internal refactoring. I'd rather have backward
compatibility.
On Mon, Oct 24, 2011 at 1:17 PM, Tom Lane wrote:
> Robert Haas writes:
>>> [ oom_score_adj business ]
>
>> Did we do anything about this? Anyone else have an opinion on what
>> ought to be done?
>
> I held off doing anything because it didn't seem like we had consensus.
> OTOH, it may well be th
On 25.09.2011 16:03, Dean Rasheed wrote:
On 25 September 2011 09:43, Kohei KaiGai wrote:
Hi Heikki,
I checked your patch, then I have a comment and two questions here.
2011/9/14 Heikki Linnakangas:
Attached is a new version of the patch. It is now complete, including WAL
replay code.
Hi,
Tom Lane wrote:
> I had wondered whether it'd be worth optimizing that along the
> lines of slot_getallattrs(). But most indexes probably have only
> one column, or anyway not enough to make for a useful savings.
>From a heavily-used production database:
cir=> select indnatts, count(*) from
On Mon, Oct 24, 2011 at 1:08 PM, Alvaro Herrera
wrote:
>
> Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011:
>
> > Starting from line 89 of terminal1.txt we see this snippet:
> >
> > postgres=# rollback;
> > ROLLBACK
> > postgres=# begin TRANSACTION ;
> > BEGIN
> > postg
"Kevin Grittner" writes:
> Tom Lane wrote:
>> I had wondered whether it'd be worth optimizing that along the
>> lines of slot_getallattrs(). But most indexes probably have only
>> one column, or anyway not enough to make for a useful savings.
>> From a heavily-used production database:
> cir
On Wed, October 19, 2011 15:01, Kerem Kat wrote:
> Adding CORRESPONDING to Set Operations
> Initial patch, filename: corresponding_clause_v2.patch
I had a quick look at the behaviour of this patch.
Btw, the examples in your email were typoed (one select is missing):
> SELECT 1 a, 2 b, 3 c UNION
Tom Lane wrote:
> Yeah, TOAST indexes are 2-column. It would be best to exclude
> those from your counts, since it seems pretty unlikely that anyone
> will care how fast nodeIndexonlyscan.c is for scans on toast
> tables.
User indexes (excluding toast):
indnatts | count
--+---
Copy/paste problems -- the first set includes the system tables
except for toast. User tables would be the difference between the
results below. Sorry.
-Kevin
"Kevin Grittner" wrote:
> Tom Lane wrote:
>
>> Yeah, TOAST indexes are 2-column. It would be best to exclude
>> those from your
On Mon, Oct 24, 2011 at 2:15 PM, Kevin Grittner
wrote:
>> It doesn't look to me like the mean is above 2 (unless you have
>> many fewer toast tables than I suspect), so trying to optimize
>> many-column cases isn't going to help.
>
> The mean is 2.4 (give or take a little depending on whether you
Robert Haas writes:
> But even though Tom's statement that most indexes are one column might
> be a slight exaggeration, I suspect it probably is true that the
> optimizations he's talking about for large numbers of columns won't
> produce any material benefit even for a 3 or 4 column index. Whic
On 10/24/11 12:35 PM, Tom Lane wrote:
> Your point about people trying to create wider indexes to exploit
> index-only scans is an interesting one, but I think it's premature to
> optimize on the basis of hypotheses about what people might do in
> future.
I don't think that this is hypothetical at
On Mon, Oct 24, 2011 at 3:35 PM, Tom Lane wrote:
> Your point about people trying to create wider indexes to exploit
> index-only scans is an interesting one, but I think it's premature to
> optimize on the basis of hypotheses about what people might do in
> future.
Well, I don't think it's too m
Josh Berkus wrote:
> On 10/24/11 12:35 PM, Tom Lane wrote:
>> Your point about people trying to create wider indexes to exploit
>> index-only scans is an interesting one, but I think it's
>> premature to optimize on the basis of hypotheses about what
>> people might do in future.
>
> I don't th
Robert Haas writes:
> On Mon, Oct 24, 2011 at 3:35 PM, Tom Lane wrote:
>> I wonder how trustworthy the measure of the visibilitymap_test call site
>> as a consumer of cycles really is.
> I'm not sure either. I guess we could try short-circuiting
> visibilitymap_test and see what that does to pe
Hackers,
After Hekki's talk on PgConf.EU about SSI, some idea comes to my mind.
Coundn't be predicate locking implementation in SSI be used for in-database
cache invalidation.
It could be possible to implement in-database cache which will acquire
predicate locks like SSI transactions. In case of a
Alexander Korotkov wrote:
> Coundn't be predicate locking implementation in SSI be used for
> in-database cache invalidation.
It would not necessarily be limited to *in-database* caches. The
main thing would be to design a good API to the predicate locking
portion of SSI, which I think is abo
Tom Lane wrote:
> I don't understand the SSI code well enough to tell if this is
> sufficient or not, so I hope you guys will take a closer look at
> the issue when you have time.
I will definitely give it a look. Right now we have a "perfect
storm" of time demands due to some recently-passed
On Tue, Oct 25, 2011 at 1:46 AM, Kevin Grittner wrote:
> Alexander Korotkov wrote:
>
> > Coundn't be predicate locking implementation in SSI be used for
> > in-database cache invalidation.
>
> It would not necessarily be limited to *in-database* caches. The
> main thing would be to design a goo
Thanks for the review!
On Tue, Oct 25, 2011 at 12:24 AM, Heikki Linnakangas
wrote:
> On 24.10.2011 15:29, Fujii Masao wrote:
>>
>> +
>> +
>> + Copy the pg_control file from the cluster directory to the global
>> + sub-directory of the backup. For example:
>> +
>> + cp $PGDATA/
On Mon, Oct 24, 2011 at 11:40 AM, Heikki Linnakangas
wrote:
> The patch looks sane, it's mostly just moving existing code around, but
> there's one thing that's been bothering me about this whole idea from the
> get-go:
>
> If the bgwriter and checkpointer are two different processes, whenever
>
On Tue, Oct 25, 2011 at 12:33 AM, Heikki Linnakangas
wrote:
> One problem with this whole FPW-tracking is that pg_lesslog makes it fail.
> I'm not sure what we need to do about that - maybe just add a warning to the
> docs. But it leaves a bit bad feeling in my mouth. Usually we try to make
> feat
On Tue, Oct 25, 2011 at 2:41 AM, Gurjeet Singh wrote:
> On Mon, Oct 24, 2011 at 1:08 PM, Alvaro Herrera
> wrote:
>>
>> Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011:
>>
>> > Starting from line 89 of terminal1.txt we see this snippet:
>> >
>> > postgres=# rollback;
>>
Hello,
my experience is that as soon as index only scans are available they are used -
sometimes just because of the simple logic that a user thinks it is faster.
Even when the index is so ridiculously long just to have all info in the
index...
Regards
Wolfgang Wilhelm
_
On 25.10.2011 08:12, Fujii Masao wrote:
On Tue, Oct 25, 2011 at 12:24 AM, Heikki Linnakangas
wrote:
On 24.10.2011 15:29, Fujii Masao wrote:
+
+
+ Copy the pg_control file from the cluster directory to the global
+ sub-directory of the backup. For example:
+
+ cp $PGDATA/global/pg_c
64 matches
Mail list logo
