On Monday, September 17, 2012 07:35:06 AM Tom Lane wrote:
> Robert Haas writes:
> > On Sep 15, 2012, at 11:32 PM, Tom Lane wrote:
> >> Right, but we do a shutdown checkpoint at the end of crash recovery.
(as noted somewhere else and tackled by Simon, a END_OF_RECOVERY didn't sync
those before)
Robert Haas writes:
> On Sep 15, 2012, at 11:32 PM, Tom Lane 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 pa
于2012年9月17日 12:47:11,Tom Lane写到:
Bruce Momjian 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
于2012年9月17日 12:32:36,Bruce Momjian写到:
On Sun, Sep 16, 2012 at 06:04:16PM -0400, Tom Lane wrote:
Bruce Momjian 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 wh
Bruce Momjian 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 transfer that t
On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
> Rural Hunter writes:
> > # select oid, * from pg_class WHERE reltoastrelid = 16439148;
> >oid| relname| relnamespace | reltype | reloftype |
> > relowner | relam | relfilenode | reltablespace | relpages | reltuples |
> >
On Sun, Sep 16, 2012 at 06:04:16PM -0400, Tom Lane wrote:
> Bruce Momjian 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
On Monday, September 17, 2012 1:39 AM Jeff Janes wrote:
On Wed, Jul 4, 2012 at 7:38 AM, Amit Kapila 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
wrote:
Suggestions?
>
>>> I suggest you add this
Rural Hunter 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 never manually
于2012年9月17日 9:48:58,Tom Lane写到:
Rural Hunter writes:
# select oid, * from pg_class WHERE reltoastrelid = 16439148;
oid| relname| relnamespace | reltype | reloftype |
relowner | relam | relfilenode | reltablespace | relpages | reltuples |
reltoastrelid | reltoastidxid | relhasinde
Rural Hunter writes:
> # select oid, * from pg_class WHERE reltoastrelid = 16439148;
>oid| relname| relnamespace | reltype | reloftype |
> relowner | relam | relfilenode | reltablespace | relpages | reltuples |
> reltoastrelid | reltoastidxid | relhasindex | relisshared |
> relpe
于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 resear
On Monday, September 17, 2012 12:35:32 AM Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 problem).
On 5.9.2012 06:17, Robert Haas wrote:
> On Tue, Sep 4, 2012 at 11:31 PM, Peter Eisentraut 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 tenfold in
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 inser
---
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
--- a/src/backend
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, pg_r
Bruce Momjian 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 what tabl
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
On Wed, Jul 4, 2012 at 7:38 AM, Amit Kapila 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 wrote:
>>> Suggestions?
>
>> I suggest you add this to the next CommitFest. :-)
>
>> https://commitfest.postg
Peter Eisentraut 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 warnings
>
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, a
On Sun, 2012-09-16 at 00:41 -0400, Tom Lane wrote:
> Peter Eisentraut 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 th
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 e
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 o
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=castoroides&dt=2012-09-15%2015%3A42%3A52
I bel
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=castoroides&dt=2012-09-15%2015%3A42%3A52
I believe what's probably happening there is tha
Gurjeet Singh 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 far more dependencies on
Andrew Dunstan 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
> setting CFLA
On 09/16/2012 12:41 AM, Tom Lane wrote:
Peter Eisentraut 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 source
over to the
On Saturday, September 15, 2012 07:21:44 PM Tom Lane wrote:
> Andres Freund 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 here.
> >
> >
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 Sep 15, 2012, at 11:32 PM, Tom Lane 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
now get modified AGA
34 matches
Mail list logo
