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
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
> > 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
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
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.
Have you determined whether the problem is optimization or 64bit ?
> Are there any othe
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
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
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 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
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 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:
> 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 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
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 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
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
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
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
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
>
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
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
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
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
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 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
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
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
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
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
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
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
>> 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
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
>>> 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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
>> 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
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
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
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
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
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
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
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.
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
>> 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
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
* 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
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
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
>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
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
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
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
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
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
> 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.
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
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
> > 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
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
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
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,
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
79 matches
Mail list logo
