From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | Vincenzo Romano <vincenzo(dot)romano(at)notorand(dot)it>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amy Smith <vah123(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgres external table |
Date: | 2010-01-20 07:57:06 |
Message-ID: | 4B56B752.7060402@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Craig Ringer wrote:
> On 19/01/2010 1:13 AM, Vincenzo Romano wrote:
>
>> Another case, Tom, could be when the file is updated from a non-DB
>> application and you need to synchronize
>> the data with other DB applications ...
>
> How can that work without a transactional file system, though? If the
> external process writes to the file while you're half-way through
> reading it, what's the database to do? In general, how do external
> tables cope with the fact that they're on non-transactional storage?
With Oracle's implementation, you version the input files (timestamp or
something) and then do ALTER TABLE to change the location the external
table points to. That will block waiting for exclusive access before it
fires, then you get a clean switch to the new location. There is no
smartness here to cope with weird behavior built-in here--I expect it
will just crash the query. One thing you always have to be careful
about when using these is that an external table might return a weird
query error under odd circumstances such as you describe, which you
might not normally expect from a simple SELECT.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | tmp | 2010-01-20 08:59:28 | Size of row-metadata? |
Previous Message | Yan Cheng Cheok | 2010-01-20 07:56:36 | Re: Why Stored Procedure is Slower In The Following Case? |