2014-09-30 17:18 GMT+02:00 Alvaro Herrera :
>
> I have pushed this fix, except that instead of parsing the OID from the
> dropStmt as in your patch, I used te->catalogId.oid, which is much
> simpler.
>
yes, it is much better
>
> I tested this by pg_restoring to 8.4 (which doesn't have
> pg_larg
I have pushed this fix, except that instead of parsing the OID from the
dropStmt as in your patch, I used te->catalogId.oid, which is much
simpler.
I tested this by pg_restoring to 8.4 (which doesn't have
pg_largeobject_metadata); there is no error raised:
LOG: sentencia: SELECT CASE WHEN EXIST
Heikki Linnakangas wrote:
> On 09/24/2014 01:50 PM, Thom Brown wrote:
> >>I am sending two patches
> >>
> >>first is fast fix
> >>
> >>second fix is implementation of Heikki' idea.
> >
> >I'm guessing this issue is still unresolved? It would be nice to get this
> >off the open items list.
>
> Ye
On 09/24/2014 01:50 PM, Thom Brown wrote:
On 15 August 2014 16:31, Pavel Stehule wrote:
2014-08-14 9:03 GMT+02:00 Heikki Linnakangas :
On 08/14/2014 06:53 AM, Joachim Wieland wrote:
I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
not ready to handle BLOBs it seems:
On 15 August 2014 16:31, Pavel Stehule wrote:
> Hi
>
>
> 2014-08-14 9:03 GMT+02:00 Heikki Linnakangas :
>
>> On 08/14/2014 06:53 AM, Joachim Wieland wrote:
>>
>>> I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
>>> not ready to handle BLOBs it seems:
>>>
>>> pg_dump: pg_bac
On Thu, Aug 14, 2014 at 10:03:57AM +0300, Heikki Linnakangas wrote:
> On 08/14/2014 06:53 AM, Joachim Wieland wrote:
> >I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
> >not ready to handle BLOBs it seems:
> >
> >pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `
Hi
2014-08-14 9:03 GMT+02:00 Heikki Linnakangas :
> On 08/14/2014 06:53 AM, Joachim Wieland wrote:
>
>> I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
>> not ready to handle BLOBs it seems:
>>
>> pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `mark !=
>> ((v
Heikki Linnakangas wrote:
> The quick fix would be to add an exception for blobs, close to where
> Assert is. There are a few exceptions there already. A cleaner
> solution would be to add a new argument to ArchiveEntry and make the
> callers responsible for providing an "DROP IF EXISTS" query, bu
2014-08-14 15:11 GMT+02:00 Alvaro Herrera :
> Heikki Linnakangas wrote:
> > On 08/14/2014 06:53 AM, Joachim Wieland wrote:
> > >I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
> > >not ready to handle BLOBs it seems:
> > >
> > >pg_dump: pg_backup_archiver.c:472: RestoreArchi
Heikki Linnakangas wrote:
> On 08/14/2014 06:53 AM, Joachim Wieland wrote:
> >I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
> >not ready to handle BLOBs it seems:
> >
> >pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `mark !=
> >((void *)0)' failed.
> >
> >To
On 08/14/2014 06:53 AM, Joachim Wieland wrote:
I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
not ready to handle BLOBs it seems:
pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `mark !=
((void *)0)' failed.
To reproduce:
$ createdb test
$ pg_dump -c --if-e
I'm seeing an assertion failure with "pg_dump -c --if-exists" which is
not ready to handle BLOBs it seems:
pg_dump: pg_backup_archiver.c:472: RestoreArchive: Assertion `mark !=
((void *)0)' failed.
To reproduce:
$ createdb test
$ pg_dump -c --if-exists test (works, dumps empty database)
$ psql
Not that I can see. You still have to get the sequence object from
someplace, and having it be a distinct datatype is zero help for finding
a column-specific sequence.
What about allowing sequence qualifiers in the SERIAL definition?
Chris
---(end of broadcast)-
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Wouldn't a lot of this be solved (I know I am over simplyfing) by making
> serial a real type?
Not that I can see. You still have to get the sequence object from
someplace, and having it be a distinct datatype is zero help for finding
a column-speci
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
pg_dump will just emit "create table t1 (f1 serial)" with no hint that
the sequence ought to be set to CYCLE mode. I'm not sure about an
appropriate fix offhand --- we can't very well use ALTER SEQUENCE in
just this way in the dum
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> pg_dump will just emit "create table t1 (f1 serial)" with no hint that
>> the sequence ought to be set to CYCLE mode. I'm not sure about an
>> appropriate fix offhand --- we can't very well use ALTER SEQUENCE in
>> just this way in the dump, b
On Wed, 2 Feb 2005 19:04:04 -0300, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> > It is not pilot error if PostgreSQL allows it. There is
> > nothing "illegal" about the above commands in their execution.
> > The pg_dump application should recognize that the object has
> > changed and react accordin
pg_dump will just emit "create table t1 (f1 serial)" with no hint that
the sequence ought to be set to CYCLE mode. I'm not sure about an
appropriate fix offhand --- we can't very well use ALTER SEQUENCE in
just this way in the dump, because of the risk of the sequence name
being possibly different
3. When the default is changed, the dependency is updated
to reflect the new sequence. The old sequence is left intact
as an independent object.
What exactly is the use-case of that (or any other manipulation of a
serial column's default)? There is no point that I can see in just
rolling one
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> ISTM this is a bug, but it's not clear to me what is the solution.
>> I can think of two:
>>
>> 1. Changing the default is forbidden
>> 2. When the default is changed, the dependency on the sequence is
>> dropped, and the seq
On Wed, Feb 02, 2005 at 03:49:59PM -0800, Joshua D. Drake wrote:
> Alvaro Herrera wrote:
>
> >On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
> >
> >>It is not pilot error if PostgreSQL allows it. There is
> >>nothing "illegal" about the above commands in their execution.
> >>The
Alvaro Herrera wrote:
On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
It is not pilot error if PostgreSQL allows it. There is
nothing "illegal" about the above commands in their execution.
The pg_dump application should recognize that the object has
changed and react accordingly
On Wed, Feb 02, 2005 at 01:54:48PM -0800, Joshua D. Drake wrote:
> It is not pilot error if PostgreSQL allows it. There is
> nothing "illegal" about the above commands in their execution.
> The pg_dump application should recognize that the object has
> changed and react accordingly.
ISTM this is
create table foo (foo serial not null, bar text);
create sequence foo_seq;
alter table foo alter column foo set default nextval('foo_seq');
This is flat out pilot error: you do not get to mess with the default
expression of a SERIAL column, because it's part of the internal
implementation of
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> However if you do the following:
> create table foo (foo serial not null, bar text);
> create sequence foo_seq;
> alter table foo alter column foo set default nextval('foo_seq');
This is flat out pilot error: you do not get to mess with the default
Hello,
Ran into this little gem with a customer today:
This works:
create table foo (foo int not null, bar text);
create sequence foo_seq;
alter table foo alter column foo set default nextval('foo_seq');
pg_dump will correctly dump the table:
CREATE TABLE foo (
foo integer DEFAULT nextval('foo_s
I'm not really keen on this idea unless you're eager to make a 5-year
commitment to maintain the code. The load formats of other RDBMSes change
all the time -- MySQL is a particularly egregious example, with 2
incompatible changes in the last year -- and it would become a pain to keep
track.
Chris,
> I was thinking a pg_export utility that can output to a range of other
> databases SQL formats would also be a good idea. It would share about
> 90% of the pg_dump code, but I'm trying to think of how to avoid
> duplicating the code.
I'm not really keen on this idea unless you're eager
Christopher Kings-Lynne wrote:
I've been looking at this for a while now, and will probably give it
a go for 7.6/8.
Let me know when you do, I'd be interested in collaborating.
Command Prompt, if would help could help sponsor this project.
Sincerely,
Joshua D. Drake
Chris
--
Command Prompt, Inc
At 02:00 PM 3/08/2004, Christopher Kings-Lynne wrote:
I'd be interested in collaborating.
Sounds good.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
(A.B.N. 75 008 659 498)
I've been looking at this for a while now, and will probably give it a
go for 7.6/8.
Let me know when you do, I'd be interested in collaborating.
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
At 01:17 PM 3/08/2004, Christopher Kings-Lynne wrote:
Would be a bit of work though.
I've been looking at this for a while now, and will probably give it a go
for 7.6/8.
Philip Warner| __---_
Albatross C
Another reason to combine pg_dumpall into pg_dump...
No argument here. Are you thinking of that?
Yeah. Would be a bit of work though.
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Chris,
> Another reason to combine pg_dumpall into pg_dump...
No argument here. Are you thinking of that?
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
I find this behavior highly undesirable, and consider it a bug.The
globals dump should just add users, and not delete any.
Unless the --clean option is passed, yes I agree with you. The other
issue is that it is silly to have to use pg_dumpall to get the globals.
A person should be able to
AFAICS that happens only if you've specified the -c (--clean) option.
Hence, I don't think it's a bug.
Nope, happens even if you don't pass --clean.
Not in CVS tip ... but you're right, older versions did act that way.
Looks like someone addressed this already.
Yeah, was one of my fixes.
Should w
I've just found a bit of undesirable functionality which I would call a bug in
pg_dump. I'm not sure everyone would, but we'll see.
Problem: the script which dumps globals such as users (pg_dumpall -g)
involves deleting *all* users from the pg_shadow table via a direct update to
that table.
Josh Berkus <[EMAIL PROTECTED]> writes:
>> AFAICS that happens only if you've specified the -c (--clean) option.
>> Hence, I don't think it's a bug.
> Nope, happens even if you don't pass --clean.
Not in CVS tip ... but you're right, older versions did act that way.
Looks like someone addressed t
On Mon, 2 Aug 2004, Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Problem: the script which dumps globals such as users (pg_dumpall -g)
involves deleting *all* users from the pg_shadow table via a direct update to
that table.
AFAICS that happens only if you've specified the -c (--clean)
Tom,
> AFAICS that happens only if you've specified the -c (--clean) option.
> Hence, I don't think it's a bug.
Nope, happens even if you don't pass --clean.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 5
This is a non-trivial accident to have happen on a shared machine; once users
are dumped, all of their ownerships and permissions go with them. If you
have a complex permissions system, better hope you backed up first!
I find this behavior highly undesirable, and consider it a bug.The glo
Josh Berkus <[EMAIL PROTECTED]> writes:
> Problem: the script which dumps globals such as users (pg_dumpall -g)
> involves deleting *all* users from the pg_shadow table via a direct update to
> that table.
AFAICS that happens only if you've specified the -c (--clean) option.
Hence, I don't think
Chris,
I've just found a bit of undesirable functionality which I would call a bug in
pg_dump. I'm not sure everyone would, but we'll see.
Problem: the script which dumps globals such as users (pg_dumpall -g)
involves deleting *all* users from the pg_shadow table via a direct update to
that
KL,
> CREATE DATABASE phppgadmin WITH TEMPLATE = template0 OWNER = chriskl
> ENCODING = 'LATIN1';
> CREATE DATABASE usa WITH TEMPLATE = template0 OWNER = usadmin ENCODING =
> 'LATIN1';
Ok, so that would come under the heading of "already fixed". Great.
--
Josh Berkus
Aglio Database Solutions
S
In article <[EMAIL PROTECTED]>,
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Mon, 2004-07-19 at 12:36, Josh Berkus wrote:
>> Rod,
>>
>> > I think what we want is a clean template without all of the extras that
>> > template1 has.
>>
>> We have this, it's called Template0.
> Doesn't work for me.
On Mon, 2004-07-19 at 21:20, Christopher Kings-Lynne wrote:
> > We already are to some extent, since pg_dump will dump its comment and
> > privileges, which it would not do for any other predefined object.
> > I think this is actually an implementation artifact rather than
> > something that was ex
Actually, KL, that would solve a lot of these duplicate object problems. What
if pg_restore used Template0 and not Template1?It wouldn't fix the "drop
public schema" issue but it would solve the others.
Not sure what you mean here, but CVS pg_dump dumps like this:
CREATE DATABASE phppgadmin
We already are to some extent, since pg_dump will dump its comment and
privileges, which it would not do for any other predefined object.
I think this is actually an implementation artifact rather than
something that was explicitly intended at the time, but since no one
has complained about it, it'
On Mon, 2004-07-19 at 13:30, Josh Berkus wrote:
> Rod,
>
> > Remove the public schema from template0, but leave it in template1. Have
> > pg_dump treat the public schema the same as all of the other ones.
>
> Hmmm. No good; it wipes out the primary purpose of Template0, which is to
> restore a
Rod,
> Remove the public schema from template0, but leave it in template1. Have
> pg_dump treat the public schema the same as all of the other ones.
Hmmm. No good; it wipes out the primary purpose of Template0, which is to
restore a corrupted Template1.
--
-Josh Berkus
Aglio Database Solutio
Rod Taylor <[EMAIL PROTECTED]> writes:
> Remove the public schema from template0, but leave it in template1.
Does not sound very workable. One of the functions of template0 is to
be a backup for the virgin state of template1, and you'd lose that.
regards, tom lane
--
On Mon, 2004-07-19 at 12:36, Josh Berkus wrote:
> Rod,
>
> > I think what we want is a clean template without all of the extras that
> > template1 has.
>
> We have this, it's called Template0.
Doesn't work for me. I remove a number of things that are included by
default in template0, but yes, it
Rod,
> I think what we want is a clean template without all of the extras that
> template1 has.
We have this, it's called Template0.
Actually, KL, that would solve a lot of these duplicate object problems. What
if pg_restore used Template0 and not Template1?It wouldn't fix the "drop
publi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> I think that we should treat the public schema specially :)
We already are to some extent, since pg_dump will dump its comment and
privileges, which it would not do for any other predefined object.
I think this is actually an implementation art
On Sun, 2004-07-18 at 23:55, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I think what we want is a clean template without all of the extras that
> > template1 has.
>
> Sounds like a job for ... template0 !
It doesn't quite work in my case as I've removed items included in
templat
Sounds like a job for ... template0 !
Seriously, this thread would be more convincing if anyone in it betrayed
any knowledge that pg_dump wants you to start from template0 rather than
template1.
What if we made it so that template1 is always restored last? Won't
that be an improvement?
Chris
---
Rod Taylor <[EMAIL PROTECTED]> writes:
> I think what we want is a clean template without all of the extras that
> template1 has.
Sounds like a job for ... template0 !
Seriously, this thread would be more convincing if anyone in it betrayed
any knowledge that pg_dump wants you to start from templ
No, because pg_dump itself dumps template1's contents...
Are you planning on extending this line of thought to other things in
template1 such as operators?
Ah, I see where you are going with this
I think that we should treat the public schema specially :) That's
because it is much more likely
On Sun, 2004-07-18 at 07:42, Christopher Kings-Lynne wrote:
> > I am not sure that is really a bug. If someone really wants less than
> > what is in template1, they should be dropping stuff from template1
> > before recreating the database.
>
> No, because pg_dump itself dumps template1's contents
On Sun, Jul 18, 2004 at 19:42:09 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >I am not sure that is really a bug. If someone really wants less than
> >what is in template1, they should be dropping stuff from template1
> >before recreating the database.
>
> No, because pg_dump its
I am not sure that is really a bug. If someone really wants less than
what is in template1, they should be dropping stuff from template1
before recreating the database.
No, because pg_dump itself dumps template1's contents...
Chris
---(end of broadcast)--
On Sun, Jul 18, 2004 at 14:33:09 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>
> * If you drop your public schema, a drop command is not issued for it in
> the dump, so when you restore your public schema is back
I am not sure that is really a bug. If someone really wants less th
Hi everyone,
I've decided to attempt to nail all known bugs in pg_dump for 7.5 :)
So, please send me ALL your known bugs/issues with pg_dump, pg_dumpall
and pg_restore. Note that I am NOT interested in feature requests, ONLY
bugs.
A bug is considered to be an issue in pg_dump that means that wh
On Sat, Oct 04, 2003 at 14:24:40 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > The following is still a problem in current cvs (as of 2 hours ago).
>
> Not any more ;-)
Thanks. I tried it out and it is now working for me.
-
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have added this to the 7.4 open items list:
> Fix pg_dump of CREATE TABLE test (col1 BOOLEAN CONSTRAINT test
> CHECK (col1))
Fixed now.
regards, tom lane
---(end of broadcast)--
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> The following is still a problem in current cvs (as of 2 hours ago).
Not any more ;-)
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to cho
I have added this to the 7.4 open items list:
Fix pg_dump of CREATE TABLE test (col1 BOOLEAN CONSTRAINT test
CHECK (col1))
---
Bruno Wolff III wrote:
> The following is still a problem in current cvs (as of
When grilled further on (Sat, 4 Oct 2003 12:50:27 -0500),
Bruno Wolff III <[EMAIL PROTECTED]> confessed:
> The following is still a problem in current cvs (as of 2 hours ago).
> Normally I wouldn't bug people about this again this soon, but with talk of
> a release candidate next week I wanted to
The following is still a problem in current cvs (as of 2 hours ago).
Normally I wouldn't bug people about this again this soon, but with talk of
a release candidate next week I wanted to make sure that it wasn't forgotten.
On Sun, Sep 28, 2003 at 20:14:03 -0500,
Bruno Wolff III <[EMAIL PROTECTED
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> If you are referring to my patch, Bruce - that does not fix it. Mine
> only addresses psql.
It strikes me that maybe your patch should add parens always, rather
than just in the prettyprint case.
> I don't think that pg_dump uses pg_get_cons
Bruno Wolff III wrote:
> On Sun, Sep 28, 2003 at 23:16:48 -0400,
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Christopher Kings-Lynne wrote:
> > > If you are referring to my patch, Bruce - that does not fix it. Mine
> > > only addresses psql.
> > >
> > > I don't think that pg_dump uses pg_ge
On Sun, Sep 28, 2003 at 23:16:48 -0400,
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Christopher Kings-Lynne wrote:
> > If you are referring to my patch, Bruce - that does not fix it. Mine
> > only addresses psql.
> >
> > I don't think that pg_dump uses pg_get_constraintdef(). It's probably a
Christopher Kings-Lynne wrote:
> If you are referring to my patch, Bruce - that does not fix it. Mine
> only addresses psql.
>
> I don't think that pg_dump uses pg_get_constraintdef(). It's probably a
> side effect of switching from using consrc to conbin.
Oh, yea. If forgot the pretty prin
If you are referring to my patch, Bruce - that does not fix it. Mine
only addresses psql.
I don't think that pg_dump uses pg_get_constraintdef(). It's probably a
side effect of switching from using consrc to conbin.
Chris
Bruce Momjian wrote:
I have a fix for this in the patch queue and it w
I have a fix for this in the patch queue and it will be applied in 24
hours. If you want to try it, it is at:
http://momjian.postgresql.org/cgi-bin/pgpatches
---
Bruno Wolff III wrote:
> If you have a check const
If you have a check constraint that tests if a boolean column is not
false by just using the column name, pg_dump doesn't include parens
around the check constraint which causes a syntax error when reloading
the database.
Using the following to create a table:
create table test (col1 boolean const
[EMAIL PROTECTED] wrote:
> On Sun, 31 Aug 2003, Bruce Momjian wrote:
>
> > Date: Sun, 31 Aug 2003 21:51:02 -0400 (EDT)
> > From: Bruce Momjian <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> > Su
On Sun, 31 Aug 2003, Bruce Momjian wrote:
> Date: Sun, 31 Aug 2003 21:51:02 -0400 (EDT)
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: pgsql-hackers list <[EMAIL PROTECTED]>
> Subject: Re: [HACKERS] pg_dump bug?
>
> [EMAIL PROTECTED] wrot
[EMAIL PROTECTED] wrote:
> Hi all,
>
> This is on 7.3.4
> I had altered a user like this:
> alter user set search_path = shema1,public
>
> Then I had to pgdumpall, re-initdb and restore every thing.
>
> The alter user did'nt get through. and broke my app.
Yes, it seems pg_dump doesn't dump per-
Hi all,
This is on 7.3.4
I had altered a user like this:
alter user set search_path = shema1,public
Then I had to pgdumpall, re-initdb and restore every thing.
The alter user did'nt get through. and broke my app.
Is it a pg_dump bug? I haven't tested on 7.4b
BTW, would'nt it be more logical if
=?iso-8859-1?q?Mart=EDn=20Marqu=E9s?= <[EMAIL PROTECTED]> writes:
> PostgreSQL version: 7.1.3
> The dump puts first the permissions and after that the view creation,
Are you certain you are using the 7.1.3 version of pg_dump, and not
something older? This was fixed in 7.1.3 according to the CVS
Short! :-)
PostgreSQL version: 7.1.3
I do I dump of a database which has some views, rules, and different
permissions on each view.
The dump puts first the permissions and after that the view creation, so when
I import the dump back to the server (or another server) I get lts of errors,
and
On Thu, 14 Sep 2000 (Today), Trurl McByte wrote:
TM>
TM>
TM>
TM> pg_dump.c: In function `AsViewRule':
sorry - 'isViewRule'!
TM> pg_dump.c:267: parse error before `int'
TM> /* 'int len;' not in declaration block */
TM> pg_dump.c:268: 'len' undeclared (first use in this function)
pg_dump.c: In function `AsViewRule':
pg_dump.c:267: parse error before `int'
/* 'int len;' not in declaration block */
pg_dump.c:268: 'len' undeclared (first use in this function)
pg_dump.c:268: (Each undeclared identifier is reported only once
pg_dump.c:268: for each function it appears in.)
p
84 matches
Mail list logo
