Hi Josh,
I think that any special "features" common to all on system tables would
go nicely near the top of 44.1 "System Catalogs Overview". That plus a
specific error message, not just a "PERMISSION DENIED", so that someone
like me can put the error message in the PostgreSQL.org search box to
fi
> Well, I found at least part of the problem:
> http://archives.postgresql.org/message-id/20090606023940.bd4b8753...@cvs.postgresql.org
>
> This is in perfectly sequential code. The reason it has
> nondeterministic effects is that (so far as I can tell) the only
> non-crash case where there would
I wrote:
> ... What I think is happening is that there's some inadequately
> locked page-changing logic in there, and if you can get autovacuum to
> happen on msginfo concurrently with the data reload step, it'll mess up.
> Given that we've not seen reports of this on 8.3, I'll bet lunch that
> the
Dimitri Fontaine wrote:
> Hi,
>
> Ah, we need module/extension/package/plugin so badly...
>
> Le 5 juin 09 ? 22:19, Bruce Momjian a ?crit :
> > I am afraid /contrib is going to be a mine field for this type of
> > problem so I am going to recommend uninstaling the /contrib module if
> > possible
Josh Berkus wrote:
> Bruce,
>
> Assuming a contrib module *hasn't* changed its API, does pg_migrator
> link against the 8.4 version of the module's .so, or the old 8.3 version?
8.4 version, or whatever is in the 8.4 lib, which should be 8.4.
--
Bruce Momjian http://momjian.us
Ente
Complete list of changes included in this patch:
- Remove unnecesary parameters nkeys, keycols, and qlabel from
show_sort_keys(), and completely unused parameter scanrelid from
show_scan_qual().
- Include the StringInfo buffer used as a staging area for EXPLAIN
output in the ExplainState object, r
On Fri, Jun 5, 2009 at 6:11 PM, Dimitri Fontaine wrote:
> Some example modules that I can think of and are wildspread in the field, as
> far as I know, are ip4r (data type and indexes), orafce (functions, views,
> tables), and some less spread are prefix (data type and indexes) or temporal
> (peri
Emmanuel Cecchet writes:
> Following the issue with temp tables and 2PC, we thought that each
> session in Postgres was supposed to generate a unique namespace for its
> temporary tables.
You made that up out of sheer wishful thinking. There is one pg_temp
schema per backendid slot.
Hi all,
Following the issue with temp tables and 2PC, we thought that each
session in Postgres was supposed to generate a unique namespace for its
temporary tables.
But if we execute the following scenario:
*
First session*.
BEGIN;
CREATE TEMP TABLE foo (x int) ON COMMIT DROP;
PREPARE TRANSACT
I wrote:
>> I poked around in the dump for awhile. I still can't reproduce the
>> failure from a standing start.
I've had a bit of success with reproducing the failure from scratch.
After loading the SQL dump that Tatsuo previously supplied into a UTF8,
C-locale database, generate a data-only dum
Greg,
this despite PostgreSQL happily accepting:
GRANT REFERENCES ON pg_namespace TO greg;
We should probably error out on this.
I found the change in tablecmds.c and a mention of it in PostgreSQL
Weekly News - May 17 2009, yet I don't understand why referencing
a system table in this m
Bruce,
Assuming a contrib module *hasn't* changed its API, does pg_migrator
link against the 8.4 version of the module's .so, or the old 8.3 version?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi,
Ah, we need module/extension/package/plugin so badly...
Le 5 juin 09 à 22:19, Bruce Momjian a écrit :
I am afraid /contrib is going to be a mine field for this type of
problem so I am going to recommend uninstaling the /contrib module if
possible and retry the migration. That should work i
"J. Greg Davidson" writes:
> from my code which has a column
> schema_name name NOT NULL REFERENCES pg_namespace ON DELETE CASCADE
You can't do that; it never has worked and is not likely to work in the
foreseeable future, because we don't support triggers on system catalogs.
Perhaps the syst
Hi,
I've been working some more on this documentation:
Le 20 mai 09 à 18:10, Dimitri Fontaine a écrit :
- consistent signature update for 8.4 (recheck arg)
- compress/decompress non void example
This means the multi-column support part is still missing, as proper
english review too.
But I
In testing my software on postgresql-8.4beta[12] I got
ERROR: 42501: permission denied: "pg_namespace" is a system catalog
LOCATION: ATAddForeignKeyConstraint, tablecmds.c:4599
from my code which has a column
schema_name name NOT NULL REFERENCES pg_namespace ON DELETE CASCADE
this
Tom Lane wrote:
> Bruce Momjian writes:
> > Brad Nicholson wrote:
> >> At the very least, a mention in the documentation of incompatible
> >> contrib module(s) would be nice. Even better would be a sanity check
> >> added to prevent this.
>
> > OK, I am looking to the hackers group for recomment
Bruce Momjian wrote:
> > There is no nice answer to this. It goes way beyond data types: you
> > could be using the module stuff in indexes, functions, views etc. You
> > can't just drop the stuff. The best I have been able to do in similar
> > cases is to install the updated module in the datab
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> >> At the very least, a mention in the documentation of incompatible
> >> contrib module(s) would be nice. Even better would be a sanity check
> >> added to prevent this.
> >>
> >
> > OK, I am looking to the hackers group for recommentation
Brad Nicholson wrote:
> > When you say "corrupted", I assume you mean you have remove the _old
> > suffixes to restart your 8.3 instance, right? I hope that is the only
> > corruption issue --- please confirm.
>
> Unfortunately no - when I try and start the old version, I get:
>
> pg_ctl -D pgsq
Bruce Momjian writes:
> Brad Nicholson wrote:
>> At the very least, a mention in the documentation of incompatible
>> contrib module(s) would be nice. Even better would be a sanity check
>> added to prevent this.
> OK, I am looking to the hackers group for recommentations on this.
One thing I w
On Fri, 2009-06-05 at 15:50 -0400, Bruce Momjian wrote:
> Brad Nicholson wrote:
> > I've been kicking the tires on this a bit, and I've found an issue when
> > dealing with contrib/ (specifically dblink, although I haven't looked
> > around anymore).
> >
> > dblink_current_query() is not in the 8.
Bruce Momjian wrote:
At the very least, a mention in the documentation of incompatible
contrib module(s) would be nice. Even better would be a sanity check
added to prevent this.
OK, I am looking to the hackers group for recommentations on this. I
wonder if I should recommend uninstall
Brad Nicholson wrote:
> I've been kicking the tires on this a bit, and I've found an issue when
> dealing with contrib/ (specifically dblink, although I haven't looked
> around anymore).
>
> dblink_current_query() is not in the 8.4 version - when I run
> pg_migrator on an 8.3 cluster that has dbli
I've been kicking the tires on this a bit, and I've found an issue when
dealing with contrib/ (specifically dblink, although I haven't looked
around anymore).
dblink_current_query() is not in the 8.4 version - when I run
pg_migrator on an 8.3 cluster that has dblink installed, I get the
following:
* Andrew Dunstan [090605 14:41]:
> The whole point is that we want something better *that suits our work
> patterns*. Almost all the backpatching that gets done is by the
> committers. So we have a bunch of concerns that are not relevant to that
> vast majority of developers. In particular,
Aidan Van Dyk wrote:
* Andrew Dunstan [090605 13:55]:
Yeah, a requirement to work from the back branch forward is quite
unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
help, not to force an unnatural work pattern on us.
Again, just to make it clear, git i
* Andrew Dunstan [090605 13:55]:
> Yeah, a requirement to work from the back branch forward is quite
> unacceptable IMNSHO. It's also quite unreasonable. The tool is there to
> help, not to force an unnatural work pattern on us.
Again, just to make it clear, git isn't going to *force* anyone
flippo00110001 writes:
> tupstore = tuplestore_begin_heap(true, false, SortMem);
SortMem? What are you testing, 7.4?
But anyway, the question I was going to ask is whether you made sure the
data set you're trying to return fits in memory. If the tuplestore
spills to disk then it's certai
Pavel Stehule wrote:
>
> Hello
>
> can you send source code? There are two types of C SRF functions. One
> returns row ro by row, second store returned rows and returns block.
> What did you use?
>
I had originally used the style that returns row by row, but after reading
the page i created a
Folks,
Here's Harada-san's moving average windowing function, expressed as a
contrib module. It has tests, etc.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Con
Now that pg_migrator is in beta (http://pgfoundry.org/frs/?group_id=1000235),
I was wondering if we want to mention pg_migrator anywhere in our docs
or release notes? Josh Berkus is already mentioning it in the draft
press release.
I expect a final pg_migrator 8.4 release by the end of next wee
Tom Lane wrote:
> Robert Haas writes:
> > [ about micro commits ]
> > (As a side benefit, if one of my little micro-commits turns out to
> > have a bug, you can easily revert *just that commit*, without having
> > to manually sort out exactly which pieces related to that change.)
>
> I don't actu
On Fri, Jun 5, 2009 at 12:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ about micro commits ]
>> (As a side benefit, if one of my little micro-commits turns out to
>> have a bug, you can easily revert *just that commit*, without having
>> to manually sort out exactly which pieces related to th
Robert Haas writes:
> [ about micro commits ]
> (As a side benefit, if one of my little micro-commits turns out to
> have a bug, you can easily revert *just that commit*, without having
> to manually sort out exactly which pieces related to that change.)
I don't actually have a lot of faith in su
On Fri, Jun 5, 2009 at 11:37 AM, Tom Lane wrote:
> However, given that we don't do any real development on the back
> branches, it might be that trying to be smart about this is a waste of
> time anyway. Surely only the HEAD version of the patch is going to be
> something that other developers car
Robert Haas writes:
> I'm sure someone is going to come in here and again recommend merging,
> but I'm going to again recommend not merging. Cherry-picking is the
> way to go here. Or just commit to each branch completely separately
> with the same commit message; cherry-pick at least IMO is jus
On Fri, Jun 5, 2009 at 9:38 AM, Tom Lane wrote:
> "Markus Wanner" writes:
>> Note that a requirement for daggy fixes is that "the bug is fixed
>> close to the point where it was introduced". So fixing it on the
>> oldest stable branch that introduced a bug instead of fixing it on
>> HEAD and then
On Fri, Jun 5, 2009 at 1:19 PM, Andrew Dunstan wrote:
>
>
> OK. try with this please:
>
> my @perl_libs = grep { /perl\d+.lib$/ }
> glob($solution->{options}->{perl} . '\lib\CORE\perl*.lib');
That looks good.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
--
Sent
Hi,
> -Original Message-
> From: ext Fujii Masao [mailto:masao.fu...@gmail.com]
> Sent: Friday, June 05, 2009 9:19 AM
> To: Kolb, Harald (NSN - DE/Munich)
> Cc: pgsql-hackers@postgresql.org; Czichy, Thoralf (NSN - FI/Helsinki)
> Subject: Re: [HACKERS] Synchronous replication: status of s
After some discussion the core committee has agreed that it's time to
wind down the 8.4 beta cycle. We will be shooting for:
RC1 wrap Thursday 6/11 for release Monday 6/15.
RC2 (if needed) the following Thursday.
8.4.0 wrap Thursday 6/25 for release Monday 6/29.
This is optimistic, of course,
Andrew Dunstan writes:
> I think we need to float a bug upstream to the perl guys on this, but as
> a holding position I suggest that we alter the #ifdef test to avoid
> calling PERL_SYS_INIT3() where MYMALLOC is defined.
+1 on both.
> BTW, it's not caused by passing NULL as the third argument
Andrew Dunstan wrote:
> [hours of digging later]
>
> On FBSD at least, this is failing in the function Perl_do_taint(). I
> can't see anything too terrible in the source for this, but to dig
> further I'd have to build another perl with debugging turned on. Anyway,
> it turns out that this actu
Tom Lane wrote:
"Markus Wanner" writes:
Note that a requirement for daggy fixes is that "the bug is fixed
close to the point where it was introduced". So fixing it on the
oldest stable branch that introduced a bug instead of fixing it on
HEAD and then back-porting would certainly be a
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan writes:
That's what we have a buildfarm for ;-) There's a failure on FBSD
too by the look of it. I'll dig some more to see what I can find.
I see this when building HEAD on Fedora 10:
plperl.c: In function 'plperl_init_interp'
Fujii Masao wrote:
> Hi,
>
> On Fri, Jun 5, 2009 at 5:10 PM, Fujii Masao wrote:
> >> psql $DB_NAME -c "SELECT pg_stop_backup();"
> >> sleep 10 # Why we need this?
> >> rm /var/lib/pgsql/backup_in_progress
> >> tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
> >
> > Since all WAL files g
"Markus Wanner" writes:
> Note that a requirement for daggy fixes is that "the bug is fixed
> close to the point where it was introduced". So fixing it on the
> oldest stable branch that introduced a bug instead of fixing it on
> HEAD and then back-porting would certainly be a step into the
(Grrr, declension, not declination.)
> "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 :n%10>=2 &&
> n%10<=4 && (n%100<10 ||n%100>=20) ? 1 : 2;\n"
Thanks. The above (ignoring backslash-EOL) is the form recommended for Russian
(inter alia(s)) in the Texinfo manual for gettext ("info g
Hi,
> -Original Message-
> From: ext Fujii Masao [mailto:masao.fu...@gmail.com]
> Sent: Friday, June 05, 2009 8:14 AM
> To: Kolb, Harald (NSN - DE/Munich)
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] postmaster recovery and automatic
> restart suppression
>
> Hi,
>
> O
> I poked around in the dump for awhile. I still can't reproduce the
> failure from a standing start. It looks to me like Tatsuo's database
> was possibly produced from separate schema and data load steps, followed
> by some update operations. It would be nice to have a full script for
> reprodu
Em Sex, 2009-06-05 às 16:19 +0900, Fujii Masao escreveu:
> BTW. Which kind of status should be detectable when combining replication
> with Hot Standby? There are several statuses. For example, the last commit
> transaction in the primary server has been;
>
> 1) not sent to the standby server yet
Dave Page wrote:
On Thu, Jun 4, 2009 at 5:23 PM, Andrew Dunstan wrote:
Yeah. The patch below should be far more future-proof (and past-proof, for
that matter).
Dave, any chance you can test it?
Doesn't work here, presumably because there is a PerlEz.lib in the
same directory as Pe
Hi,
On Fri, Jun 5, 2009 at 5:10 PM, Fujii Masao wrote:
>> psql $DB_NAME -c "SELECT pg_stop_backup();"
>> sleep 10 # Why we need this?
>> rm /var/lib/pgsql/backup_in_progress
>> tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
>
> Since all WAL files generated during backup have to be add
On Thu, Jun 4, 2009 at 5:23 PM, Andrew Dunstan wrote:
> Yeah. The patch below should be far more future-proof (and past-proof, for
> that matter).
>
> Dave, any chance you can test it?
Doesn't work here, presumably because there is a PerlEz.lib in the
same directory as Perl510.lib, causing the g
Hi,
On Fri, Jun 5, 2009 at 4:18 PM, Yoshinori Sano wrote:
> Hi, all
>
> I posted this message to the pgsql-general mailing list, however there was
> no response. So, I repost the mail to pgsql-hackers.
>
> I want to achieve a simple, safe hot backup and recovery using PostgreSQL 8.3
> or later.
>
Hi,
On Thu, Jun 4, 2009 at 7:53 PM, Kolb, Harald (NSN - DE/Munich)
wrote:
> We are planning to use the HotStandby feature too.
> That would require to have the correct state information since we have
> to
> control the DB clients when and how they can connect or reconnect.
> But also in general,
Hi, all
I posted this message to the pgsql-general mailing list, however there was
no response. So, I repost the mail to pgsql-hackers.
I want to achieve a simple, safe hot backup and recovery using PostgreSQL 8.3
or later.
The standalone hot backup script listed in "24.3.5.1. Standalone hot bac
Hi,
Quoting "Ron Mayer" :
Seems you'd want to do is create a new branch as close to the point
where the bug was introduced - and then merge that forward into each
of the branches.
Thank you for pointing this out. As a fan of monotone I certainly know
and like that way. However, for people wh
58 matches
Mail list logo
