On Thu, Nov 17, 2005 at 07:11:42PM -0500, Neil Conway wrote:
> On Thu, 2005-11-17 at 13:07 -0800, David Fetter wrote:
> > This is still a bug, or at least a big gotcha.
>
> It's not a bug, merely an unimplemented feature. If no one beats me
> to it I'll take a look at doing this for 8.2.
Fantast
On Thu, 2005-11-17 at 13:07 -0800, David Fetter wrote:
> This is still a bug, or at least a big gotcha.
It's not a bug, merely an unimplemented feature. If no one beats me to
it I'll take a look at doing this for 8.2.
-Neil
---(end of broadcast)-
On Thu, Nov 17, 2005 at 05:32:43PM -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Thu, Nov 17, 2005 at 04:37:14PM -0500, Tom Lane wrote:
> >> CREATE TEMP TABLE foo ... ON COMMIT DROP;
>
> > It's that first little elipsis mark that's the problem. Is there
> > something re
David Fetter <[EMAIL PROTECTED]> writes:
> On Thu, Nov 17, 2005 at 04:37:14PM -0500, Tom Lane wrote:
>> CREATE TEMP TABLE foo ... ON COMMIT DROP;
> It's that first little elipsis mark that's the problem. Is there
> something really clever I've been missing on how to do a dynamic table
> creation?
On Thu, Nov 17, 2005 at 04:37:14PM -0500, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > This is still a bug,
>
> No, it's a feature request, and a rather low-priority one considering
> you can already do
>
> CREATE TEMP TABLE foo ... ON COMMIT DROP;
It's that first little
David Fetter <[EMAIL PROTECTED]> writes:
> This is still a bug,
No, it's a feature request, and a rather low-priority one considering
you can already do
CREATE TEMP TABLE foo ... ON COMMIT DROP;
INSERT INTO foo SELECT ...
regards, tom lane
---
On Thu, Nov 17, 2005 at 03:26:21PM -0500, Jaime Casanova wrote:
> On 11/17/05, David Fetter <[EMAIL PROTECTED]> wrote:
> >
> > The following bug has been logged online:
> >
> > Bug reference: 2051
> > Logged by: David Fetter
> > Email address: [EMAIL PROTECTED]
> > PostgreSQL ver
On 11/17/05, David Fetter <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 2051
> Logged by: David Fetter
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0x
> Operating system: Linux
> Description:CREATE TEMP TABLE A
The following bug has been logged online:
Bug reference: 2051
Logged by: David Fetter
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0x
Operating system: Linux
Description:CREATE TEMP TABLE AS SELECT doesn't play nice with ON
COMMIT DROP
Details:
CREATE TEMP
Matt <[EMAIL PROTECTED]> writes:
> Yesterday I added 20 more join statements to the query (identical to
> existing statements) and now the main query which would run in <30
> seconds, runs indefinitely with the process stuck at "PARSE" in version
> 7.4, or "BIND" in version 8.0.3.
You *really* nee
>Hmm, the CLUSTER on vehicle_unit_data_200407 wouldn't have taken any
>lock on vehicle_unit_data_200301. Were you perhaps issuing a series
>of CLUSTERs inside a transaction block? That would pile up exclusive
>locks on all the tables involved, which is certainly deadlock-prone.
Ah, that explains
"Mikael Carneholm" <[EMAIL PROTECTED]> writes:
> dfol=> select pgc.oid, pgc.relname from pg_class pgc where pgc.oid in (68950,
> 68122);
> oid | relname
> ---+--
> 68950 | vehicle_unit_data_200407
> 68122 | vehicle_unit_data_200301
> NOTICE: Clu
oops, you're right.
dfol=> select pgc.oid, pgc.relname from pg_class pgc where pgc.oid in (68950,
68122);
oid | relname
---+--
68950 | vehicle_unit_data_200407
68122 | vehicle_unit_data_200301
NOTICE: Clustering idx_vehicle_unit_data_200407_per
"Mikael Carneholm" <[EMAIL PROTECTED]> writes:
> Unfortunately, relfilenodes 68950 and 68122 don't exist anymore,
You should be looking at pg_class.oid, not relfilenode.
regards, tom lane
---(end of broadcast)---
TIP 2: Don'
Unfortunately, relfilenodes 68950 and 68122 don't exist anymore, could be that
they were temporary copies of tables or indexes. I know that process 15865 was
the autovacuum pid, I looked that up when it happened (pg was restarted with
autovacuum=off afterwards, so that process is also gone)
Cou
Forgot to mention:
dfol=> select version();
version
-
PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)
-Original Message-
From: Tom Lane [mailto:[EMAIL P
(-resend)
Hi,
I have a nightly process which distills a range of statistics from a
third-party database into a set of temporary tables, and then from those
tables, aggregates and joins these figures into two main tables. Each
temporary table contains a moderate number of rows and few columns.
Th
"Mikael Carneholm" <[EMAIL PROTECTED]> writes:
> variant: CLUSTER indexname ON tablename
Hmph. Looking at the code, that should always lock the table first,
so I don't see where the problem is. Would you look up the numbers
for us --- exactly which relations were involved in the deadlock,
and (i
variant: CLUSTER indexname ON tablename
Maybe there should be something about this in the docs, so that users don't get
surprised when this happens and start sending stupid emails to the pgsql-bugs
list :)
/Mikael
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: den
"Mikael Carneholm" <[EMAIL PROTECTED]> writes:
> Don't know if this is a bug or just undocumented, but it seems as you should
> turn off autovacuum before you run CLUSTER, otherwise you might run into a
> deadlock:
Which variant of CLUSTER were you using? ISTR that some of them lock
the index b
Don't know if this is a bug or just undocumented, but it seems as you should
turn off autovacuum before you run CLUSTER, otherwise you might run into a
deadlock:
NOTICE: Clustering idx_vehicle_unit_data_200407_person_information__id on
vehicle_unit_data_200407
ERROR: deadlock detected
DETAIL:
... continued ...
-- Join account hold crosstabs
FULL JOIN tmp_stats_dhb_crosstab_num USING (csid,case_upload_date)
FULL JOIN tmp_stats_dhb_crosstab_amt USING (csid,case_upload_date)
FULL JOIN tmp_stats_dhb_crosstab_fbal USING (csid,case_upload_date)
FULL JOIN tmp_stats_dhb_cross
22 matches
Mail list logo
