On Mon, Feb 9, 2009 at 9:16 AM, Amit Gupta wrote:
> Hi Emmanuel,
>
> We are considering to following approach:
> 1. metadata table pg_partitions is defined as follows:
> CATALOG(pg_partitions,2336) BKI_WITHOUT_OIDS
> {
>Oid partrelid; // partition table Oid
>Oid parentr
Hi,
alvhe...@postgresql.org (Alvaro Herrera) wrote:
> Log Message:
> ---
> Update autovacuum to use reloptions instead of a system catalog, for
> per-table overrides of parameters.
>
> This removes a whole class of problems related to misusing the catalog,
> and perhaps more importantly,
Hi Amit,
I will be traveling until next Tuesday and will have no access to email
so don't be surprised if I don't follow up this week.
The overall approach seems sound. The metadata table should help also
for DDL to find out overlapping ranges or duplicate list entries.
So far, I have not tried
The series of SE-PostgreSQL patches are updated:
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1530.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1530.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4devel-3-r1
> > Is there any way to stop autovacuum temporarily?(other than edit
> > postgresql.conf and reload it) Pgpool-II does not want autovacuum
> > running while doing "onlie recovery".
>
> It would be a significant hack but you could update pg_autovacuum to set
> all relations to false.
Thanks. Maybe
On Tue, 2009-02-10 at 10:15 +0900, Tatsuo Ishii wrote:
> Hi,
>
> Is there any way to stop autovacuum temporarily?(other than edit
> postgresql.conf and reload it) Pgpool-II does not want autovacuum
> running while doing "onlie recovery".
It would be a significant hack but you could update pg_auto
Hi,
Is there any way to stop autovacuum temporarily?(other than edit
postgresql.conf and reload it) Pgpool-II does not want autovacuum
running while doing "onlie recovery".
--
Tatsuo Ishii
SRA OSS, Inc. Japan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
> We don't want a pg_dump flag; the doc mention is good enough.
>
>
>Doh! Try this one instead. Postgres 8.3 changed the name of the
> flag mentioned in the doc.
[ Please avoid html-only email.]
OK, patch applied, but I removed the mention of pre-8.3 because this is
going only in the 8.
Bruce Momjian wrote:
Apologies. Turns out the name of the relevant setting was changed
for 8.3! So a revised patch is attached.
For backing, see:
http://www.postgresql.org/docs/8.3/static/release-8-3.html
" Numerous changes in administrative server parameters...
stats_bl
On Mon, Feb 9, 2009 at 1:44 PM, Robert Haas wrote:
>>> AIUI, the main reason for table groups would be to define different
>>> autovacuum policies for different groups of tables. Right now, that
>>> would be pretty stupid, because there are only two possible policies:
>>> "yes" and "no".
>>
>> no
Greg Stark writes:
> I think what you propose would be a mistake. We want to encourage
> people to move *away* from OIDS.
Why? I don't agree with that premise, and therefore not with any
of the rest of your argument.
regards, tom lane
--
Sent via pgsql-hackers mailing
Sorry, I was indeed thinking of newly added columns rather than
dropped columns. We define the row representation such that one may
have fewer rows than the tupledesc and how to interpret that in such a
way as to make adding nullable columns a convenient operation.
How is doing the same here and f
Kenneth Marshall writes:
> I have updated the patch posted by Jeff Davis on January 9th
> to include the micro-patch above as well as updated the polymorphism
> regressions tests. This applies cleanly to the latest CVS pull.
Applied --- thanks for being persistent about resolving the doubts on th
>Apologies. Turns out the name of the relevant setting was changed
> for 8.3! So a revised patch is attached.
>For backing, see:
>http://www.postgresql.org/docs/8.3/static/release-8-3.html
>" Numerous changes in administrative server parameters...
>stats_block_level and stats_r
Apologies. Turns out the name of the relevant setting was changed for
8.3! So a revised patch is attached.
For backing, see:
http://www.postgresql.org/docs/8.3/static/release-8-3.html
" Numerous changes in administrative server parameters...
stats_block_level and stats_row_level are merged in
Jeff Davis writes:
> On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote:
>> Well, there's nothing to force that plan to be invalidated when the
>> state of the pending list changes, is there?
> Would it be unreasonable to invalidate cached plans during the pending
> list cleanup?
If the pendin
* Alvaro Herrera:
> Euler Taveira is arguing in an autovacuum thread that we should give
> "storage parameters" a different name; his argument is that
> "autovacuum_enabled" is not really a parameter that relates to storage.
> He is proposing "relation parameters".
They also apply to indices, rig
Andrew Dunstan writes:
> I have clients I have not yet managed to ween off oids, because they
> have legacy apps, sometimes third party apps, that rely on them. I don't
> want to make it any harder to get them over the hurdle.
Surely the major cost there is going to be fixing those apps; I thin
>> AIUI, the main reason for table groups would be to define different
>> autovacuum policies for different groups of tables. Right now, that
>> would be pretty stupid, because there are only two possible policies:
>> "yes" and "no".
>
> not really... the idea is to let one group to have autovacuu
On Mon, Feb 9, 2009 at 12:31 PM, Robert Haas wrote:
>>> Hopefully the grouping of tables is not purely related to AV?
>>
>> Hmm, good question. I was envisioning it only for autovacuum, but it
>> hasn't been vetted on pgsql-hackers.
>
> I think we're in danger of inventing a solution in search of
Tom Lane wrote:
Considering that default_with_oids went false in 8.1 (?), affected are
users who are reusing their dumps or postgresql.conf from 8.0 and below.
No, they have upgraded along the way. pg_dump carefully preserves the
with/without oids property of the tables it is dumping.
Alvaro Herrera writes:
> Euler Taveira is arguing in an autovacuum thread that we should give
> "storage parameters" a different name; his argument is that
> "autovacuum_enabled" is not really a parameter that relates to storage.
> He is proposing "relation parameters".
> I am against the idea of
Marko Kreen writes:
> No. I'm not concerned with ALTER command, I'm concerned about reloading
> dumps from older versions. So my, uh, new argument is - starting with 8.4,
> it is very hard to get rid of oids on user tables because all the tools
> work against user.
That's a pretty overstated cl
Tom Lane escribió:
> Alvaro Herrera writes:
> > KaiGai Kohei escribi�:
> >> One melancholic thing is adding a member into pg_proc.
> >> It defines more than 2000 of entries which I have to modify correctly. :(
> >> Is there any script to help it?
>
> > Try a search for "coccinelle", "sdiff", or w
On Mon, Feb 9, 2009 at 12:19 PM, Alvaro Herrera
wrote:
> Euler Taveira is arguing in an autovacuum thread that we should give
> "storage parameters" a different name; his argument is that
> "autovacuum_enabled" is not really a parameter that relates to storage.
> He is proposing "relation paramete
On 2/9/09, Tom Lane wrote:
> Marko Kreen writes:
> > On 2/9/09, Heikki Linnakangas wrote:
> >> Do you still need the oids? If not, run ALTER TABLE WITHOUT OIDS before
> >> upgrading to 8.4, while it's still fast. If yes, you couldn't use the
> option
> >> to remove them at pg_dump anyway beca
Alvaro Herrera writes:
> Josh Berkus wrote:
>> Right. What I'm saying is that if it *didn't* require a sighup, then
>> users could cronjob starting and stopping Autovac themselves.
> Hmm, I'm not sure I understand what you're suggesting. Maybe what you
> want is that we have a SQL-accesible f
>> Hopefully the grouping of tables is not purely related to AV?
>
> Hmm, good question. I was envisioning it only for autovacuum, but it
> hasn't been vetted on pgsql-hackers.
I think we're in danger of inventing a solution in search of a problem here.
AIUI, the main reason for table groups wou
Bruce Momjian writes:
> I talked to Oleg on IM and he is waiting for an official review. Is
> someone going to review his work or should he commit it (with Teodor)
> because they know this area of the code better than anyone else?
Obviously they know the innards of GIN better than the rest of us
Hi,
Euler Taveira is arguing in an autovacuum thread that we should give
"storage parameters" a different name; his argument is that
"autovacuum_enabled" is not really a parameter that relates to storage.
He is proposing "relation parameters".
I am against the idea of renaming them, for two reaso
Alvaro Herrera writes:
> KaiGai Kohei escribió:
>> One melancholic thing is adding a member into pg_proc.
>> It defines more than 2000 of entries which I have to modify correctly. :(
>> Is there any script to help it?
> Try a search for "coccinelle", "sdiff", or was it "spatch"? It got
> feature
Josh Berkus wrote:
>>> On the other hand, I'd been keen on a runtime suset autovaccum=on/off
>>> which we could call from a cron job or the pgadmin scheduler in
>>> order to have maintenance windows. Unless that's already becoming
>>> possible?
>>
>> autovacuum=on/off is already SIGHUP as of
Robert Haas wrote:
> On Mon, Feb 9, 2009 at 9:39 AM, Bruce Momjian wrote:
> > There are now seven unapplied patches on the commit-fest page:
> >
> >http://wiki.postgresql.org/wiki/CommitFest_2008-11
> >
> > not counting the SE-PostgreSQL and "Recovery, Replication, Hot Standby"
> > patches
Marko Kreen writes:
> On 2/9/09, Heikki Linnakangas wrote:
>> Do you still need the oids? If not, run ALTER TABLE WITHOUT OIDS before
>> upgrading to 8.4, while it's still fast. If yes, you couldn't use the option
>> to remove them at pg_dump anyway because you still need them after the
>> upgrad
On 2/9/09, Robert Haas wrote:
> On Mon, Feb 9, 2009 at 11:36 AM, Marko Kreen wrote:
> > On 2/9/09, Tom Lane wrote:
> >> Marko Kreen writes:
> >> > But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs
> >> > or requires table rewrite, it turned from minor annoyance to bi
KaiGai Kohei escribió:
> One melancholic thing is adding a member into pg_proc.
> It defines more than 2000 of entries which I have to modify correctly. :(
> Is there any script to help it?
Try a search for "coccinelle", "sdiff", or was it "spatch"? It got
featured on http://LWN.net/ not many we
Simon Riggs wrote:
>
> On Thu, 2009-02-05 at 18:54 -0300, Alvaro Herrera wrote:
> > I don't see them as conflicting; I see yours as a missing feature,
> > namely the ability to add tables to an autovacuum "group", which could
> > have settings attached. Being able to do that is the whole point o
On 2/9/09, Heikki Linnakangas wrote:
> Marko Kreen wrote:
> > We've set default_with_oids = false, for quite a long time. But there
> > are still tables remaining with oids. And this discussion showed it
> > now easy to get rid of them.
>
> Do you still need the oids? If not, run ALTER TABLE WI
On Mon, Feb 9, 2009 at 11:36 AM, Marko Kreen wrote:
> On 2/9/09, Tom Lane wrote:
>> Marko Kreen writes:
>> > But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs
>> > or requires table rewrite, it turned from minor annoyance to big
>> annoyance.
>> > So I'd like have a rea
On Mon, Feb 9, 2009 at 9:39 AM, Bruce Momjian wrote:
> There are now seven unapplied patches on the commit-fest page:
>
>http://wiki.postgresql.org/wiki/CommitFest_2008-11
>
> not counting the SE-PostgreSQL and "Recovery, Replication, Hot Standby"
> patches.
>
> I can now see us closing th
Marko Kreen writes:
> On 2/9/09, Tom Lane wrote:
>> We've had SET WITHOUT OIDS since 7.3 or thereabouts. Anybody who hasn't
>> applied it in all that time either does not care, or actually needs the
>> OIDs and will be unhappy if we arbitrarily remove the feature.
> Sure I did not care. Becaus
Marko Kreen wrote:
We've set default_with_oids = false, for quite a long time. But there
are still tables remaining with oids. And this discussion showed it
now easy to get rid of them.
Do you still need the oids? If not, run ALTER TABLE WITHOUT OIDS before
upgrading to 8.4, while it's still
On 2/9/09, Robert Haas wrote:
> >> Why? What benefit do we get out of denying users this option?
> >
> > Why should we continue to support historical special case? It is not
> > a feature that adds anything to user experience with Postgres.
> >
> > Anyway, that was my vote only. If there
Tom Lane wrote:
Andrew Dunstan writes:
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
How about a pg_dump flag that simply suppresses OIDs from the data
and schema?
pg_dump -s postgres | sed -e 's/SET default_with_oids = true;/-- &/'
No good for non-text dumps.
Also it would fail badl
>>> Bruce Momjian wrote:
> Where are we on this: the original patch, and Kevin's slow queries?
Robert's patch is not the cause of the 8.4 problems with my queries,
and (as Robert pointed out) a separate thread has been started to
discuss those issues.
>From my perspective, Robert's patch has i
On 2/9/09, Tom Lane wrote:
> Marko Kreen writes:
> > But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs
> > or requires table rewrite, it turned from minor annoyance to big annoyance.
> > So I'd like have a reasonable path for getting rid of them, which we don't
> > have
>> Why? What benefit do we get out of denying users this option?
>
> Why should we continue to support historical special case? It is not
> a feature that adds anything to user experience with Postgres.
>
> Anyway, that was my vote only. If there are developers interested
> in supporting oids f
Andrew Dunstan writes:
> Heikki Linnakangas wrote:
>> Andrew Dunstan wrote:
>>> How about a pg_dump flag that simply suppresses OIDs from the data
>>> and schema?
>>
>> pg_dump -s postgres | sed -e 's/SET default_with_oids = true;/-- &/'
> No good for non-text dumps.
Also it would fail badly
Andrew Dunstan wrote:
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
How about a pg_dump flag that simply suppresses OIDs from the data
and schema?
pg_dump -s postgres | sed -e 's/SET default_with_oids = true;/-- &/'
No good for non-text dumps.
*shrug*, create a text dump then.
--
He
Marko Kreen writes:
> But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs
> or requires table rewrite, it turned from minor annoyance to big annoyance.
> So I'd like have a reasonable path for getting rid of them, which we don't
> have currently.
We've had SET WITHOUT OIDS sin
On 9 Feb 2009, at 16:04, Tom Lane wrote:
Hmm. I think -qnoansialias corresponds to gcc's -fno-strict-aliasing,
which we *know* is necessary to build a working Postgres on recent gcc
versions. I have not checked the exact symptoms of -fstrict-aliasing
recently, but what you're reporting is def
Heikki Linnakangas wrote:
Andrew Dunstan wrote:
How about a pg_dump flag that simply suppresses OIDs from the data
and schema?
pg_dump -s postgres | sed -e 's/SET default_with_oids = true;/-- &/'
No good for non-text dumps.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-h
Mihai Criveti writes:
> OK, I've compiled a 64 bit optimized version, and it works great! No issues
> what so ever in configure, make or install. Thanks a lot for all the support
> :-).
> PostgreSQL rocks!
> What I've used to build it:
> CC="xlc_r -q64 -qnoansialias"
Hmm. I think -qnoansialia
On 2/9/09, David Fetter wrote:
> On Mon, Feb 09, 2009 at 10:44:17AM -0500, Andrew Dunstan wrote:
> > Marko Kreen wrote:
> >> But now that I learned that ALTER TABLE WITHOUT OIDS either causes
> >> bugs or requires table rewrite, it turned from minor annoyance to
> >> big annoyance. So I'd lik
Andrew Dunstan wrote:
How about a pg_dump flag that simply suppresses OIDs from the data and
schema?
pg_dump -s postgres | sed -e 's/SET default_with_oids = true;/-- &/'
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On Mon, Feb 09, 2009 at 10:44:17AM -0500, Andrew Dunstan wrote:
> Marko Kreen wrote:
>> But now that I learned that ALTER TABLE WITHOUT OIDS either causes
>> bugs or requires table rewrite, it turned from minor annoyance to
>> big annoyance. So I'd like have a reasonable path for getting rid
>> of
On 2/9/09, Andrew Dunstan wrote:
> Marko Kreen wrote:
> > But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs
> > or requires table rewrite, it turned from minor annoyance to big
> annoyance.
> > So I'd like have a reasonable path for getting rid of them, which we don't
> > ha
Marko Kreen wrote:
But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs
or requires table rewrite, it turned from minor annoyance to big annoyance.
So I'd like have a reasonable path for getting rid of them, which we don't
have currently. Removing them completely is simplest
All regression tests work. Everything seems to be in order :-)
Followup with regression tests (rand the installchecks as postgres user):
$ gmake check
[..]
===
All 114 tests passed.
===
[after setting up the database and all:]
$ gmake installcheck
...
te
On 2/9/09, Robert Haas wrote:
> On Feb 9, 2009, at 7:47 AM, Marko Kreen wrote:
> > On 2/9/09, Andrew Dunstan wrote:
> > > David Fetter wrote:
> > > > On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
> > > >
> > > > > Now, if you want to argue that we should get rid of SET WITHOUT OIDS
>
A month ago I warned that we had an unusually high number of open items:
http://archives.postgresql.org/pgsql-hackers/2009-01/msg00321.php
Fortunately, thanks to a lot of hard work, my list of open items has
shrunk from +200 to 44:
http://momjian.us/cgi-bin/pgsql/open
Now, that
Hi Emmanuel,
We are considering to following approach:
1. metadata table pg_partitions is defined as follows:
CATALOG(pg_partitions,2336) BKI_WITHOUT_OIDS
{
Oid partrelid; // partition table Oid
Oid parentrelid; // Parent table Oid
int4parttype; // Type o
Hi Niranjan,
On Mon, Feb 9, 2009 at 10:39 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
> But after I login to replication database (note the active I had brought
> it down earlier & created a finish.trigger), I still cannot see the
> table that was created on the primary.
> Also please note that t
On Feb 9, 2009, at 7:47 AM, Marko Kreen wrote:
On 2/9/09, Andrew Dunstan wrote:
David Fetter wrote:
On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
Now, if you want to argue that we should get rid of SET WITHOUT
OIDS
altogether,
+1 for removing it altogether. Row OIDs are and
OK, I've compiled a 64 bit optimized version, and it works great! No issues
what so ever in configure, make or install. Thanks a lot for all the support
:-).
PostgreSQL rocks!
What I've used to build it:
CC="xlc_r -q64 -qnoansialias"
AR="ar -X64"
OBJECT_MODE=64
./configure --enable-cassert --ena
On Mon, Feb 09, 2009 at 03:19:55PM +0200, Marko Kreen wrote:
> > Making pg_dump not output the WITH OIDS option on tables may be an
> > easier option.
>
> I don't like it - it would require more work from users, but does
> not seem to be any way safer. You usually do the check if db works
> on
On 2/9/09, Martijn van Oosterhout wrote:
> Making pg_dump not output the WITH OIDS option on tables may be an
> easier option.
OTOH, the pg_dump already has option --oids. If the option is not given,
is there any point putting WITH OIDS / default_with_oids into dump?
--
marko
--
Sent via p
On 2/9/09, Heikki Linnakangas wrote:
> Martijn van Oosterhout wrote:
> > Making pg_dump not output the WITH OIDS option on tables may be an
> > easier option.
>
> Or just run ALTER TABLE WITHOUT OIDS for all the tables before dumping.
This does not work on dbs that are actually in use...
--
ma
On 2/9/09, Martijn van Oosterhout wrote:
> On Mon, Feb 09, 2009 at 02:47:21PM +0200, Marko Kreen wrote:
> > > That might be true but I know of apps that use them. Having the ability
> to
> > > migrate those slowly by using SET WITHOUT OIDS is a Good Thing (tm).
> >
> > +1 for removal.
> >
>
On 7 feb, 23:44, da...@fetter.org (David Fetter) wrote:
> On Sat, Feb 07, 2009 at 10:44:48PM -0500, David Lee Lambert wrote:
> > In the same spirit as the FreeBSD-native UUID generator that was
> > discussed here a couple months ago, I was able to link Postgres 8.4
> > against the UUID generator e
Martijn van Oosterhout wrote:
Making pg_dump not output the WITH OIDS option on tables may be an
easier option.
Or just run ALTER TABLE WITHOUT OIDS for all the tables before dumping.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (
On Mon, Feb 09, 2009 at 02:47:21PM +0200, Marko Kreen wrote:
> > That might be true but I know of apps that use them. Having the ability to
> > migrate those slowly by using SET WITHOUT OIDS is a Good Thing (tm).
>
> +1 for removal.
>
> Also, whether the removal happens or not, I would suggest a
On 2/9/09, Andrew Dunstan wrote:
> David Fetter wrote:
> > On Sun, Feb 08, 2009 at 11:51:22AM -0500, Tom Lane wrote:
> > > Now, if you want to argue that we should get rid of SET WITHOUT OIDS
> > > altogether,
> >
> > +1 for removing it altogether. Row OIDs are and ugly wart :P
>
> That might b
> Yes, I've had CC exported as xlC_r -q64 to do 64 bit builds, and use vacpp
> C++ instead of C. Guess it didn't like that, and ended up with some horrible
> compiler optimization or something that killed it.
Have you determined whether the problem is optimization or 64bit ?
> Are there any othe
Hi Niranjan,
On Mon, Feb 9, 2009 at 6:58 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
>> 1) pg_ctl -D /home/postgres/postgresHSB/actdata stop
>> 2) touch /home/postgres/postgresHSB/finish.trigger
>
> Yes. This the procedure that I followed. I have attached the relevant
> logs.
> "change_standby_mo
Yes, I've had CC exported as xlC_r -q64 to do 64 bit builds, and use vacpp
C++ instead of C. Guess it didn't like that, and ended up with some horrible
compiler optimization or something that killed it.
Are there any other tests I can run now that PostgreSQL is installed?
Seems to work fine for b
> > So if this is a compiler bug, it certainly isn't an obvious one. I'll dig
> > deeper to see how I can convince configure to use -qnooptimize.
>
> Set CFLAGS in its environment. The default is set in src/template/aix
> CFLAGS="-O2 -qmaxmem=16384 -qsrcmsg -qlonglong"
>
> > When I've use
OK, I've managed to compile a 32 bit PostgreSQL successfully and it runs.
I'm not yet sure if the issues are due to using the C++ compiler to compile
C code, optimization flags or 64 bit builts, but I'll rebuilt it a few times
to pinpoint the real issue.
Either way, I think it was my mistake to us
Hi Niranjan,
Thanks very much!
On Mon, Feb 9, 2009 at 3:08 PM, K, Niranjan (NSN - IN/Bangalore)
wrote:
> Now, the active and standby database are up & running even after the
> execution of the SQL (create table). What was the problem?
The problem is that 1-byte variable was assigned the value c
79 matches
Mail list logo
