Re: URGENT: temporary table not recognized?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Kreen <markokr(at)gmail(dot)com>
Cc: Steve Crawford <scrawford(at)pinpointresearch(dot)com>, Phoenix Kiula <phoenix(dot)kiula(at)gmail(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: URGENT: temporary table not recognized?
Date: 2012-01-06 22:57:54
Message-ID: 25579.1325890674@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Marko Kreen <markokr(at)gmail(dot)com> writes:
> On Fri, Jan 6, 2012 at 11:24 PM, Steve Crawford
> <scrawford(at)pinpointresearch(dot)com> wrote:
>> On 01/06/2012 01:11 PM, Phoenix Kiula wrote:
>>> How can I make sure pgbouncer takes it all in the same session? I also
>>> tried the two commands within a transaction.

>> Sounds like you are using statement pooling - every statement can be
>> assigned to a different server connection. You may need transaction pooling
>> or session pooling:
>> http://pgbouncer.projects.postgresql.org/doc/usage.html

> Statement pooling throws error on open transaction.

Yeah, if it still fails within a single transaction, it gets harder to
blame pgbouncer. But there are not very many other candidates. I
wondered about a funny setting of search_path, but ISTM that could at
worst result in copying into the wrong table (ie some other table named
"vl"), not failure to find any "vl" at all.

It might be worth turning on statement logging and ensuring that
log_line_prefix includes the process PID. Then the postmaster log would
provide indisputable evidence whether the CREATE and the COPY are
executed in the same session or not.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Phoenix Kiula 2012-01-06 23:12:11 Re: URGENT: temporary table not recognized?
Previous Message Marko Kreen 2012-01-06 22:27:14 Re: URGENT: temporary table not recognized?