On Sunday, September 16, 2012 12:14 AM Fujii Masao wrote:
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila amit.kap...@huawei.com wrote:
On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila amit.kap...@huawei.com wrote:
On Thursday, September
On Sep 15, 2012, at 11:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, but we do a shutdown checkpoint at the end of crash recovery.
Yes, but that only writes the buffers that are dirty. It doesn't fix the lack
of a BM_PERMANENT flag on a buffer that ought to have had one. So that page can
I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
directly or indirectly. Also, in timestamp.h different code is enabled
depending on HAVE_INT64_TMESTAMP being defined, but even though that macro
is defined in pg_config.h, it does not automatically trickle down into this
file, as
On Saturday, September 15, 2012 07:21:44 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Saturday, September 15, 2012 07:32:45 AM Tom Lane wrote:
Well, actually, that just brings us to the main point which is: I do not
believe that circular links are a good design choice
On 09/16/2012 12:41 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
_FORTIFY_SOURCE=2 appears to be the default for package building on many
Linux distributions now, as part of harding or security options. But we
often hear about problems related to this only when we hand the
Andrew Dunstan and...@dunslane.net writes:
On 09/16/2012 12:41 AM, Tom Lane wrote:
Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.
Might be worth having a buildfarm animal or two building with it, say by
Gurjeet Singh singh.gurj...@gmail.com writes:
I noticed that xlog.h uses PGDLLIMPORT, but it does not include c.h
directly or indirectly.
In general, all include files in Postgres assume that you've included
postgres.h or postgres_fe.h (as appropriate) first; and practically
all of them have
It's annoying that the buildfarm animals running on older versions of
Solaris randomly fail with Connection refused errors, such as in
today's example:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroidesdt=2012-09-15%2015%3A42%3A52
I believe what's probably happening there is that
On 09/16/2012 12:04 PM, Tom Lane wrote:
It's annoying that the buildfarm animals running on older versions of
Solaris randomly fail with Connection refused errors, such as in
today's example:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=castoroidesdt=2012-09-15%2015%3A42%3A52
I
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
OK, I see many new ALTER TABLE commands, but nothing that would cause a
difference in relation count.
Attached is a patch that will return the OID of the old/new mismatched
entries. Please research the pg_class objects on the
Hi,
On Sunday, September 16, 2012 04:23:14 PM Andres Freund wrote:
What do you think about something like:
typedef struct dlist_iter
{
/*
* Use a union with equivalent storage as dlist_node to make it possible
to * initialize the struct inside a macro without multiple
On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
_FORTIFY_SOURCE=2 appears to be the default for package building on many
Linux distributions now, as part of harding or security options. But we
often hear about problems related to this only when
On Sun, 2012-09-16 at 10:36 -0400, Andrew Dunstan wrote:
Might be worth having a buildfarm animal or two building with it, say by
setting CFLAGS before configure?
I don't really see the value in that. Either this is part of our
standard set of warnings and checks that we are interested in,
Peter Eisentraut pete...@gmx.net writes:
On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote:
Doesn't seem like a good idea to me to add platform-specific options
with unspecified effects to platform-independent upstream sources.
It's effectively a warning option, and we end up fixing all the
On Wed, Jul 4, 2012 at 7:38 AM, Amit Kapila amit.kap...@huawei.com wrote:
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Tuesday, July 03, 2012 9:43 PM
On Mon, Jul 2, 2012 at 8:08 AM, Amit Kapila amit.kap...@huawei.com wrote:
Suggestions?
I suggest you add this to the next
Jeff Davis wrote:
On Mon, 2012-09-10 at 11:15 -0500, Kevin Grittner wrote:
Do you have any suggested wording [...] ?
Attached. I thought about putting it as a note, but it seems like
it's easy to go overboard with those.
I agree about a note being overkill for this.
I'm attaching an
Bruce Momjian br...@momjian.us writes:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
I ran the pg_upgrade with the patch and found the problematic object
is a toast object.
OK, this is exactly what I wanted to see, and it explains why pg_dump
didn't show it. Can you find out
Now that I proposed a new syscache upthread its easily possible to provide
pg_relation_by_filenode which I wished for multiple times in the past when
looking at filesystem activity and wondering which table does what. You can
sortof get the same result via
SELECT oid FROM (
SELECT oid,
---
src/backend/utils/cache/relmapper.c | 53 +
src/include/utils/relmapper.h | 2 ++
2 files changed, 55 insertions(+)
diff --git a/src/backend/utils/cache/relmapper.c b/src/backend/utils/cache/relmapper.c
index 6f21495..771f34d 100644
---
This requires the previously added RELFILENODE syscache.
---
doc/src/sgml/func.sgml | 23 -
src/backend/utils/adt/dbsize.c | 78 ++
src/include/catalog/pg_proc.h | 2 ++
src/include/utils/builtins.h | 1 +
4 files changed, 103
On 5.9.2012 06:17, Robert Haas wrote:
On Tue, Sep 4, 2012 at 11:31 PM, Peter Eisentraut pete...@gmx.net wrote:
On Tue, 2012-09-04 at 23:14 -0400, Robert Haas wrote:
Actually, this whole things seems like a solution in search of a
problem to me. We just reduced the verbosity of pgbench -i
Andres Freund and...@2ndquadrant.com writes:
This requires the previously added RELFILENODE syscache.
[ raised eyebrow... ] There's a RELFILENODE syscache? I don't see one,
and I doubt it would work given that the contents of
pg_class.relfilenode aren't unique (the zero entries are the
On Monday, September 17, 2012 12:35:32 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
This requires the previously added RELFILENODE syscache.
[ raised eyebrow... ] There's a RELFILENODE syscache? I don't see one,
and I doubt it would work given that the contents of
于2012年9月17日 1:17:46,Bruce Momjian写到:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
OK, I see many new ALTER TABLE commands, but nothing that would cause a
difference in relation count.
Attached is a patch that will return the OID of the old/new mismatched
entries. Please
Rural Hunter ruralhun...@gmail.com writes:
# select oid, * from pg_class WHERE reltoastrelid = 16439148;
oid| relname| relnamespace | reltype | reloftype |
relowner | relam | relfilenode | reltablespace | relpages | reltuples |
reltoastrelid | reltoastidxid | relhasindex |
于2012年9月17日 9:48:58,Tom Lane写到:
Rural Hunter ruralhun...@gmail.com writes:
# select oid, * from pg_class WHERE reltoastrelid = 16439148;
oid| relname| relnamespace | reltype | reloftype |
relowner | relam | relfilenode | reltablespace | relpages | reltuples |
reltoastrelid |
Rural Hunter ruralhun...@gmail.com writes:
äº2012å¹´9æ17æ¥ 9:48:58,Tom Laneåå°:
I wonder whether you dropped and recreated the information_schema in
the lifetime of this database? We have recommended doing that in the
past, IIRC. Could such a thing have confused pg_dump?
No, I have
On Monday, September 17, 2012 1:39 AM Jeff Janes wrote:
On Wed, Jul 4, 2012 at 7:38 AM, Amit Kapila amit.kap...@huawei.com wrote:
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Tuesday, July 03, 2012 9:43 PM
On Mon, Jul 2, 2012 at 8:08 AM, Amit Kapila amit.kap...@huawei.com
wrote:
On Sun, Sep 16, 2012 at 06:04:16PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
I ran the pg_upgrade with the patch and found the problematic object
is a toast object.
OK, this is exactly what I wanted to
On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
Rural Hunter ruralhun...@gmail.com writes:
# select oid, * from pg_class WHERE reltoastrelid = 16439148;
oid| relname| relnamespace | reltype | reloftype |
relowner | relam | relfilenode | reltablespace | relpages |
Bruce Momjian br...@momjian.us writes:
On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
Well, that's even stranger, because (1) information_schema.sql_features
ought to have a toast table in either version, and (2) neither pg_dump
nor pg_upgrade ought to be attempting to dump or
于2012年9月17日 12:32:36,Bruce Momjian写到:
On Sun, Sep 16, 2012 at 06:04:16PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
I ran the pg_upgrade with the patch and found the problematic object
is a toast object.
OK,
于2012年9月17日 12:47:11,Tom Lane写到:
Bruce Momjian br...@momjian.us writes:
On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
Well, that's even stranger, because (1) information_schema.sql_features
ought to have a toast table in either version, and (2) neither pg_dump
nor pg_upgrade ought
Robert Haas robertmh...@gmail.com writes:
On Sep 15, 2012, at 11:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right, but we do a shutdown checkpoint at the end of crash recovery.
Yes, but that only writes the buffers that are dirty. It doesn't fix the lack
of a BM_PERMANENT flag on a buffer
34 matches
Mail list logo
