> I'm not sure what the correct fix is. I suppose we could pfree() the old
> value before overwriting it, but I'm not sure if that's safe, or if
> there might still be references to the old value somewhere in the executor.
It will resolve the current problem but I am also not sure whether it can
On 06/19/2012 07:43 AM, Leif Halvorsen wrote:
Ronald,
Did you ever find a solution to this bug?
I'm fairly new to PostgreSQL and I've been fighting with
this for weeks. I think I'm going to be forced to use MySQL
instead even though I'd rather not.
6/18/12 7:42:35.188 PM com.apple.launchd:
(co
I wrote:
> 168; 1259 41968 TABLE public t1 postgres
> ; depends on: 5
> 1921; 2606 41975 CONSTRAINT public t1_pkey postgres
> ; depends on: 168 168
> 169; 1259 41976 VIEW public v1 postgres
> ; depends on: 1919 5
> 1922; 0 41968 TABLE DATA public t1 postgres
> ; depends on:
I wrote:
> We could possibly hack something for the special case of rules, but
> I don't think this would be the last time we hear about this type of
> issue. I'm inclined to think that the best solution would be to add
> generic logic to pg_dump that "looks through" any dependency references
> to
I wrote:
> Hmm ... check_functional_grouping does add the PK's OID to the query's
> constraintDeps list. Apparently we're losing that dependency knowledge
> somewhere between the parser and pg_dump?
I looked into this a bit. The dependency does exist in pg_depend, but
it is shown as a dependency
Alvaro Herrera writes:
> Excerpts from Ryan Kelly's message of mar jun 19 16:20:58 -0400 2012:
>> On Tue, Jun 19, 2012 at 07:49:20PM +, j...@tanga.com wrote:
>>> SELECT channels.id, channels.start_at, channels.end_at, channels.title
>>> FROM channels
>>> LEFT JOIN channels_products cp ON cp.ch
Excerpts from Ryan Kelly's message of mar jun 19 16:20:58 -0400 2012:
> On Tue, Jun 19, 2012 at 07:49:20PM +, j...@tanga.com wrote:
> > View definition:
> > SELECT channels.id, channels.start_at, channels.end_at, channels.title
> >FROM channels
> >LEFT JOIN channels_products cp ON cp
On Tue, Jun 19, 2012 at 07:49:20PM +, j...@tanga.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6699
> Logged by: Joe Van Dyk
> Email address: j...@tanga.com
> PostgreSQL version: 9.1.4
> Operating system: OSX
> Description:
>
>
The following bug has been logged on the website:
Bug reference: 6699
Logged by: Joe Van Dyk
Email address: j...@tanga.com
PostgreSQL version: 9.1.4
Operating system: OSX
Description:
$ pg_restore -O -j 4 ~/tanga.dump -d tanga_dev_full_backup
pg_restore: [archiver (
Ronald,
Did you ever find a solution to this bug?
I'm fairly new to PostgreSQL and I've been fighting with
this for weeks. I think I'm going to be forced to use MySQL
instead even though I'd rather not.
6/18/12 7:42:35.188 PM com.apple.launchd:
(com.edb.launchd.postgresql-9.1[3736]) Exited with
On 19.06.2012 04:01, armando.mirag...@stud-inf.unibz.it wrote:
The following bug has been logged on the website:
Bug reference: 6698
Logged by: Armando Miraglia
Email address: armando.mirag...@stud-inf.unibz.it
PostgreSQL version: 9.1.2
Operating system: Arch Linux/Ubuntu
De
11 matches
Mail list logo
