>On Sunday, October 07, 2012 5:42 AM Tatsuo Ishii wrote:
>Ok, committed with minor editings(fix header comments in testlo64.c).
>Thank you Kaigai-san for review!
Hello Tatsuo Ishii San,
Today when I tried to build the latest code on my windows m/c, I got few errors
from the checkin of this pat
On Sun, Oct 7, 2012 at 3:17 AM, Tom Lane wrote:
> Atri Sharma writes:
>> The issue I am trying to resolve is that if two scans are taking place
>> on the same backend(due to the same query),then,the server is
>> crashing.
>
> That sounds like an FDW bug ... which FDW are we talking about?
>
>> I
Developers,
Please do re-initdb...
> Bump up catalog vesion due to 64-bit large object API functions
> addition.
>
> Branch
> --
> master
>
> Details
> ---
> http://git.postgresql.org/pg/commitdiff/b51a65f5bf4b68bc91d33d88108837d13d29df98
>
> Modified Files
> --
> src/inclu
Ok, committed with minor editings(fix header comments in testlo64.c).
Thank you Kaigai-san for review!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> As a committer, I have looked into the patch and it seems it's good to
> comm
Atri Sharma writes:
> The issue I am trying to resolve is that if two scans are taking place
> on the same backend(due to the same query),then,the server is
> crashing.
That sounds like an FDW bug ... which FDW are we talking about?
> I think it is because I am not saving the state of the scan,s
I wrote:
> What the README file actually suggests is that periodically we should
> re-evaluate the set of default abbreviations.
I looked through the diffs between the 2005m Olson time zone files
(which is what we were using at the time the tznames files were created)
and current. There are sever
On Mon, Oct 1, 2012 at 2:28 PM, Selena Deckelmann wrote:
> On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann wrote:
>> On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane wrote:
>>> Selena Deckelmann writes:
The check_temp_buffers() problem seems like a regression and blocks us
from upgrading to
On Sat, Oct 6, 2012 at 4:05 PM, Tom Lane wrote:
> Atri Sharma writes:
>> On Sat, Oct 6, 2012 at 3:45 PM, Tom Lane wrote:
>>> Atri Sharma writes:
I am trying to identify foreign scans uniquely.
>
>>> What do you mean by "identify"? What are you trying to accomplish,
>>> and in what context
Atri Sharma writes:
> On Sat, Oct 6, 2012 at 3:45 PM, Tom Lane wrote:
>> Atri Sharma writes:
>>> I am trying to identify foreign scans uniquely.
>> What do you mean by "identify"? What are you trying to accomplish,
>> and in what context?
> I am trying to identify the situation where a query
On 10/06/2012 03:35 PM, Tom Lane wrote:
"David E. Wheeler" writes:
On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
Now, having said that, I think it has to be the reponsibility of the FDW
to apply any required check ... which makes this a bug report against
oracle_fdw, not the core system. (FWI
On Sat, Oct 6, 2012 at 3:45 PM, Tom Lane wrote:
> Atri Sharma writes:
>> I am trying to identify foreign scans uniquely.
>
> What do you mean by "identify"? What are you trying to accomplish,
> and in what context?
>
> regards, tom lane
Hi Tom,
I am trying to identify t
Atri Sharma writes:
> I am trying to identify foreign scans uniquely.
What do you mean by "identify"? What are you trying to accomplish,
and in what context?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On 6 October 2012 00:56, Tom Lane wrote:
> 1. These operations think they can use ordinary heap_update operations
> to change pg_index entries when they don't have exclusive lock on the
> parent table. The lack of ex-lock means that another backend could be
> currently loading up its list of ind
"David E. Wheeler" writes:
> On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
>> Now, having said that, I think it has to be the reponsibility of the FDW
>> to apply any required check ... which makes this a bug report against
>> oracle_fdw, not the core system. (FWIW, contrib/file_fdw depends on the
On 10/06/12 3:45 AM, Heikki Linnakangas wrote:
At the SQL level, there's the convert(bytea, name, name) function.
ahhh, right. (forehead slap)
a 2nd function would do the same, but replace
errors with the substitution character in the target charset and not
error.
Hmm, I don't think we
2012/10/2 Alvaro Herrera :
> Excerpts from Alvaro Herrera's message of vie sep 28 18:17:32 -0300 2012:
>> Excerpts from Kohei KaiGai's message of lun sep 10 08:08:32 -0300 2012:
>>
>> > As attached, I split off the original one into three portions; for
>> > set-schema,
>> > set-owner and rename-to
Hi,
I am trying to identify foreign scans uniquely.I am trying to do that
by struct ForeignScanState,but I am confused as to how I can identify
the scan.
Is there a member of ForeignScanState that can be used for this purpose?
Atri
--
Regards,
Atri
l'apprenant
--
Sent via pgsql-hackers mai
On Sat, Oct 6, 2012 at 1:34 PM, David E. Wheeler wrote:
> On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
>
>> Probably not so much "assumed" as "nobody thought about it". In
>> e.g. plperl we expend the cycles to do encoding validity checking on
>> *every* string entering the system from Perl. I'm
On Oct 5, 2012, at 6:12 PM, Tom Lane wrote:
> Probably not so much "assumed" as "nobody thought about it". In
> e.g. plperl we expend the cycles to do encoding validity checking on
> *every* string entering the system from Perl. I'm not sure why foreign
> tables ought to get a pass on that, esp
Marc Balmer writes:
> These files are maintained by PostgreSQL, there is even a README with an
> explicit mention that changes should be reported to pgsql-hackers
What the README file actually suggests is that periodically we should
re-evaluate the set of default abbreviations. I'm not that
On 10/05/2012 09:03 PM, Tom Lane wrote:
Note that allowing subsequent requests to jump the queue would not be a
good fix for this; if you do that, it's likely the ex-lock will never be
granted, at least not till the next system idle time.
Offering that option to the admin sounds like a good thi
On Thursday, October 04, 2012 8:03 PM Heikki Linnakangas wrote:
On Wednesday, October 03, 2012 9:33 PM Amit Kapila wrote:
On Friday, September 28, 2012 7:03 PM Amit Kapila wrote:
> > On Thursday, September 27, 2012 6:39 PM Amit Kapila wrote:
> > > On Thursday, September 27, 2012 4:12 PM Heikki Linn
On Sat, Oct 6, 2012 at 02:46:03PM +0200, Marc Balmer wrote:
> Bruce,
>
> > The Postgres community does not maintain the timezone database; we ship
> > copies of the IANA timezone database; you will have to request the
> > changes from them:
> >
> > http://www.iana.org/time-zones
>
> Pleas
On Thursday, October 04, 2012 7:22 PM Heikki Linnakangas wrote:
> > On Wednesday, October 03, 2012 8:45 PM Heikki Linnakangas wrote:
> > On Tuesday, October 02, 2012 4:21 PM Heikki Linnakangas wrote:
> > > Thanks for the thorough review! I committed the xlog.c refactoring
> > patch
> > > now. Attac
Bruce,
> The Postgres community does not maintain the timezone database; we ship
> copies of the IANA timezone database; you will have to request the
> changes from them:
>
> http://www.iana.org/time-zones
Please take a second look at the diffs, they do *NOT* change the files
in the time
On Sat, Jul 21, 2012 at 5:36 PM, Tom Lane wrote:
> Martijn van Oosterhout writes:
>> On Sat, Jul 21, 2012 at 01:08:58AM +0100, Daniele Varrazzo wrote:
>>> In a libpq application, if there is an application error between
>>> PQsendQuery and PQgetResult, is there a way to revert a connection
>>> ba
The Postgres community does not maintain the timezone database; we ship
copies of the IANA timezone database; you will have to request the
changes from them:
http://www.iana.org/time-zones
---
On Sat, Oct 6, 2012
On 06.10.2012 05:14, John R Pierce wrote:
I'd like to see some encoding validation and substitution functions in
postgres. for instance, one that can take any supported encoding and
convert it to the database encoding and generate an error on any invalid
character. this translation could be ident
The attached patch would add the FET timezone abbreviation to the
Default list _and_ the list of european abbreviations.
- mb
diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default
index 1369f47..7223ce5 100644
--- a/src/timezone/tznames/Default
+++ b/src/timezone/tznames/Default
FET stands for Further-eastern European Time and is the official time in
e.g. Belarus (Europe/Minsk).
The attched patch adds FET to the list of Default timezone abbreviations.
- Marc Balmer
diff --git a/src/timezone/tznames/Default b/src/timezone/tznames/Default
index 1369f47..7223ce5 100644
---
30 matches
Mail list logo
