Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Tom Lane píše v čt 11. 03. 2010 v 11:37 -0500: > Zdenek Kotala writes: > > "-xO4 -xalias_level=basic" generates problem. > > "-xO3 -xalias_level=basic" works fine > > "-xO5" works fine > > > As documentation say: > > > Cite from Sun studio compiler guide: > > http://docs.sun.com/app/docs/doc/819

Re: [HACKERS] Server crash with older tzload library

Tom Lane wrote: > Heikki Linnakangas writes: >> No, Jeevan is talking about tzcode, not tzdata. The zoneinfo library is >> split into two parts, we update the data part at each release, but we >> don't sync up our code with upstream code changes regularly. > > It strikes me that maybe we are putt

Re: [HACKERS] [GENERAL] trouble with to_char('L')

Bruce Momjian wrote: > OK, I have created a new function, win32_wchar_to_db_encoding(), to > share the conversion from wide characters to the database encoding. > New patch attached. Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify db_encoding_strdup() with the function. L

[HACKERS] Reposnse from backend when wrong user/database request send

It seems between 8.4 and CVS HEAD backend responses 'E' packet (error/fatal message) if a startup packet sent with wrong user and/or database. Before backend responses 'R' packet first followd by 'E' packet. Does anybody know why this change made? I do not againt this change because this is correc

Re: [HACKERS] Dyamic updates of NEW with pl/pgsql

Merlin Moncure escribió: > (small aside: the other biggie would be able to push a composite type > in to an update statement...something like 'update foo set foo = > new'). This is really great...some variant of this question is > continually asked it seems. Can't you already do that with EXECU

Re: [HACKERS] Dyamic updates of NEW with pl/pgsql

On Wed, Mar 10, 2010 at 7:50 AM, Andrew Dunstan wrote: >>> 2010/3/9 strk : How can a pl/pgsql trigger change the values of dynamic fields in NEW record ? By "dynamic" I mean that the field name is a variable in the trigger context. I've been told it's easy to do

Re: [HACKERS] Warning about invalid .pgpass passwords

Bruce Momjian wrote: + /* If it was 'invalid authorization', add .pgpass mention */ + if (conn->dot_pgpass_used && conn->password_needed && conn->result && + /* only works with >= 9.0 servers */ + strcmp(PQresultErrorField(conn->result, PG_DIAG_SQLSTATE),

Re: [HACKERS] Warning about invalid .pgpass passwords

Robert Haas wrote: > On Thu, Mar 11, 2010 at 4:19 PM, Bruce Momjian wrote: > > ? ? ? ?$ sql -h localhost test > > ? ? ? ?psql: FATAL: ?password authentication failed for user "postgres" > > ? ? ? ?password retrieved from .pgpass > > I find this not quite explicit enough for my taste. Maybe somet

Re: [HACKERS] Warning about invalid .pgpass passwords

On Thu, Mar 11, 2010 at 4:19 PM, Bruce Momjian wrote: >        $ sql -h localhost test >        psql: FATAL:  password authentication failed for user "postgres" >        password retrieved from .pgpass I find this not quite explicit enough for my taste. Maybe something like this? the failing pa

Re: [HACKERS] buildfarm logging versus embedded nulls

Tom Lane wrote: I was looking at this recent nonrepeatable buildfarm failure: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-03-11%2021:45:10 which has several instances of the known "pgstat wait timeout" problem during the parallel regression tests. I was disappointed

Re: [HACKERS] [patch] build issues on Win32

On Thu, Mar 11, 2010 at 01:34:34PM -0800, Steve Atkins wrote: > On Mar 11, 2010, at 1:06 PM, Tom Lane wrote: > > > > BTW, I'm not sure I buy the argument that commercial software > > requires static linking. Red Hat would be as interested in that > > market as anybody, and as I said, they don't t

Re: [HACKERS] Warning about invalid .pgpass passwords

Tom Lane wrote: > Bruce Momjian writes: > > + #define ERRCODE_INVALID_PASSWORD_SPECIFICATION MAKE_SQLSTATE('2','8', > > '0','0','1') > > Oh, another thought: you're infringing on SQL-committee-controlled code > space there. Probably 28P01 would be a safer choice. OK, updated patch with code "2

Re: [HACKERS] [BUGS] log : bad file dscriptor????

On Wed, Mar 18, 2009 at 3:47 AM, Heikki Linnakangas < heikki.linnakan...@enterprisedb.com> wrote: > Gurjeet Singh wrote: > >>On Windows, the write to log file is done by a thread (whose main >> function is pipeThread() ), and since it works completely independent of >> the >> SysLoggerMain() (

Re: [HACKERS] renameatt() can rename attribute of index, sequence, ...

(2010/03/11 23:55), Robert Haas wrote: > 2010/3/10 KaiGai Kohei: >> Indeed, it is useful to allow renaming attribute of composite types. >> >> However, it is also useless to allow to rename attribute of sequences, >> but harmless, like renames on indexes. It seems to me it is fair enough >> to allo

[HACKERS] buildfarm logging versus embedded nulls

I was looking at this recent nonrepeatable buildfarm failure: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-03-11%2021:45:10 which has several instances of the known "pgstat wait timeout" problem during the parallel regression tests. I was disappointed to see that the post

Re: [HACKERS] Warning about invalid .pgpass passwords

Bruce Momjian writes: > + #define ERRCODE_INVALID_PASSWORD_SPECIFICATION MAKE_SQLSTATE('2','8', > '0','0','1') Oh, another thought: you're infringing on SQL-committee-controlled code space there. Probably 28P01 would be a safer choice. regards, tom lane -- Sent via pg

Re: [HACKERS] Warning about invalid .pgpass passwords

Bruce Momjian writes: ERRCODE_INVALID_PASSWORD_SPECIFICATION BTW, why not just "ERRCODE_INVALID_PASSWORD"? The extra word doesn't seem to promote anything except carpal tunnel syndrome. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] Warning about invalid .pgpass passwords

Tom Lane wrote: > Bruce Momjian writes: > > Alvaro Herrera wrote: > >> This bit seems strange ... I think we just do strcmp() to compare > >> sqlstates? > > > Uh, the PQresultErrorField is a string, while > > ERRCODE_INVALID_PASSWORD_SPECIFICATION is a 4-byte value in base-64. > > Yea, it's t

Re: [HACKERS] plperl db access documentation enhancement

Bruce Momjian wrote: > Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > > > > Patch applied for 9.0. We don't normally backpatch such documentation > > > improvements unless we receive multiple reports of confusion. > > > > I think that's a mistake in this case. The documentation wasn't > >

Re: [HACKERS] Warning about invalid .pgpass passwords

Bruce Momjian writes: > Alvaro Herrera wrote: >> This bit seems strange ... I think we just do strcmp() to compare sqlstates? > Uh, the PQresultErrorField is a string, while > ERRCODE_INVALID_PASSWORD_SPECIFICATI is a 4-byte value in base-64. > Yea, it's true. For excitement, see the MAKE_SQL

Re: [HACKERS] HeapTupleData.t_self garbage values

Tom Lane wrote: > I don't want to put weasel wording into the comment. If you're > bothered by the discrepancy then we should fix the code to > initialize all the struct fields. Maybe for 9.1. At this point, unless it's breaking something I can't see that anything beyond a comment would be j

Re: [HACKERS] Warning about invalid .pgpass passwords

Alvaro Herrera wrote: > Bruce Momjian wrote: > > > + static void > > + dot_pg_pass_warning(PGconn *conn) > > + { > > + /* If it was 'invalid authorization', add .pgpass mention */ > > + if (conn->dot_pgpass_used && conn->password_needed && conn->result && > > + /* only works with >=

Re: [HACKERS] [patch] build issues on Win32

On Mar 11, 2010, at 1:06 PM, Tom Lane wrote: > > > BTW, I'm not sure I buy the argument that commercial software requires > static linking. Red Hat would be as interested in that market as > anybody, and as I said, they don't think it's necessary to ship static > libraries (with a *very* short

Re: [HACKERS] Warning about invalid .pgpass passwords

Bruce Momjian wrote: > + static void > + dot_pg_pass_warning(PGconn *conn) > + { > + /* If it was 'invalid authorization', add .pgpass mention */ > + if (conn->dot_pgpass_used && conn->password_needed && conn->result && > + /* only works with >= 9.0 servers */ > + a

Re: [HACKERS] Warning about invalid .pgpass passwords

Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian writes: > > > Tom Lane wrote: > > >> I'm inclined to think that maybe we should make the server return a > > >> distinct SQLSTATE for "bad password", and have libpq check for that > > >> rather than just assuming that the failure must be bad

Re: [HACKERS] HeapTupleData.t_self garbage values

"Kevin Grittner" writes: > At a minimum, it might be good to qualify the comment in htup.h and > add a comment where there is an exception. This can be startling in > a debugger if you don't know that the comment isn't really true. > (And I've found another place where t_tableOid isn't set, but

Re: [HACKERS] [patch] build issues on Win32

Greg Stark writes: > The two (separate) goals which are useful are 1) Provide a library > others can link against to produce a binary which has no run-time > dependency on your library. In this case the only library they might > want to link against would be libpq. The encoding libraries etc aren'

Re: [HACKERS] HeapTupleData.t_self garbage values

Tom Lane wrote: > Yeah, the correct TID value would be > ItemPointerGetBlockNumber(tid) plus the current offnum. Thanks! > However we don't have enough information in this function to set > t_tableOid correctly, so maybe it would be best to just set both > fields invalid. Or do nothing ---

Re: [HACKERS] HeapTupleData.t_self garbage values

"Kevin Grittner" writes: > Tom Lane wrote: >> ItemPointerSetInvalid(&(tuple.t_self)); > Aren't those tuples pointing to a disk buffer? Oh, I should have looked at the code before commenting ;-). Yeah, the correct TID value would be ItemPointerGetBlockNumber(tid) plus the current offnum. Howe

Re: [HACKERS] [patch] build issues on Win32

Tom Lane wrote: Now libpq doesn't often have critical security bugs filed against it, but it certainly has bugs. Do you really want to have to remember to rebuild every piece of dependent software when you update it? The OP's case apparently involves multiple independent libraries that he wan

Re: [HACKERS] [patch] build issues on Win32

2010/3/11 Tom Lane : > Now libpq doesn't often have critical security bugs filed against it, > but it certainly has bugs.  Do you really want to have to remember to > rebuild every piece of dependent software when you update it? I absolutely agree that linking statically is a terrible idea for dis

Re: [HACKERS] HeapTupleData.t_self garbage values

Tom Lane wrote: > "Kevin Grittner" writes: >> According to htup.h: >> * t_self and t_tableOid should be valid if the HeapTupleData >> * points to a disk buffer, or if it represents a copy of a tuple >> * on disk. They should be explicitly set invalid in manufactured >> * tuples. > >> In the

Re: [HACKERS] HeapTupleData.t_self garbage values

"Kevin Grittner" writes: > According to htup.h: > * t_self and t_tableOid should be valid if the HeapTupleData points > * to a disk buffer, or if it represents a copy of a tuple on disk. > * They should be explicitly set invalid in manufactured tuples. > In the heap_hot_search_buffer function

[HACKERS] HeapTupleData.t_self garbage values

According to htup.h: * t_self and t_tableOid should be valid if the HeapTupleData points * to a disk buffer, or if it represents a copy of a tuple on disk. * They should be explicitly set invalid in manufactured tuples. In the heap_hot_search_buffer function of heapam.c this is not true. I c

Re: [HACKERS] [patch] build issues on Win32

Greg Stark writes: > 2010/3/10 David Fetter : --disable-shared, as previously mentioned. >> >> +1 for de-supporting this option. > I would be sad about this. It seems likely there are platforms where > it's important. Any such platform would already be contending with plpgsql not working,

Re: [HACKERS] Server crash with older tzload library

Heikki Linnakangas writes: > No, Jeevan is talking about tzcode, not tzdata. The zoneinfo library is > split into two parts, we update the data part at each release, but we > don't sync up our code with upstream code changes regularly. It strikes me that maybe we are putting ourselves at risk by

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

2010/3/11 Alvaro Herrera : > Pavel Stehule escribió: >> 2010/3/11 Tom Lane : >> > Pavel Stehule writes: >> >> The problem is in very large small allocations - there are 853215 nodes. >> >> I replaced palloc0 inside mkSPnode by balloc >> > >> > This goes back to the idea we've discussed from time t

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

Pavel Stehule escribió: > 2010/3/11 Tom Lane : > > Pavel Stehule writes: > >> The problem is in very large small allocations - there are 853215 nodes. > >> I replaced palloc0 inside mkSPnode by balloc > > > > This goes back to the idea we've discussed from time to time of having a > > variant memo

Re: [HACKERS] Server crash with older tzload library

On Thu, Mar 11, 2010 at 1:49 PM, Tom Lane wrote: > Jeevan Chalke writes: >> The upstream zoneinfo project just released a new tzcode version, 2010c. >> After syncing the code to this version does not lead to server crash. The >> new release is now initializing the tzstate variable with zeros to a

Re: [HACKERS] operator exclusion constraints

On Thu, 2010-03-11 at 00:29 -0500, Tom Lane wrote: Patch changes: > > Indexes: > > "foo_pkey" PRIMARY KEY, btree (f1), tablespace "ts1" > > "foo_f2_exclusion" btree (f2), tablespace "ts1" > > "foo_f3_exclusion" btree (f3) DEFERRABLE INITIALLY DEFERRED > > Exclusion constraints: > >

Re: [HACKERS] Server crash with older tzload library

Jeevan Chalke writes: > The upstream zoneinfo project just released a new tzcode version, 2010c. > After syncing the code to this version does not lead to server crash. The > new release is now initializing the tzstate variable with zeros to avoid any > garbage values. > PFA, patch which will bri

[HACKERS] tsearch - using a transformed data files

Hello we are able to go down load time of ispell dictionaries if we can remove upper to lower transformations (and some flag check). these operations take about 40% of dictionary initialisation time. so maybe we can thinking about some flag for ispell_dictionary - like clean, or some similar? R

Re: [HACKERS] [patch] build issues on Win32

Magnus Hagander writes: > In particular, libpq only exports a fixed subset of symbols on any > platform that supports that (which includes Windows). > AFAIK, there is no way to make that restriction on static libraries, > at least not on Windows. Right, and not anyplace else either except by pre

Re: [HACKERS] [patch] build issues on Win32

2010/3/11 Dag-Erling Smørgrav : > Greg Stark writes: >> I would be sad about this. It seems likely there are platforms where >> it's important. But I'm not really about to spend the effort to fix it >> up myself and I agree it wouldn't be worth hacking the source to get >> it to work. I'm a bit pu

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

2010/3/11 Tom Lane : > Pavel Stehule writes: >> The problem is in very large small allocations - there are 853215 nodes. >> I replaced palloc0 inside mkSPnode by balloc > > This goes back to the idea we've discussed from time to time of having a > variant memory context type in which pfree() is a

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

Pavel Stehule writes: > The problem is in very large small allocations - there are 853215 nodes. > I replaced palloc0 inside mkSPnode by balloc This goes back to the idea we've discussed from time to time of having a variant memory context type in which pfree() is a no-op and we dispense with all

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

2010/3/11 Pavel Stehule : > 2010/3/11 Tom Lane : >> Pavel Stehule writes: >>> There are some wrong in our implementation NISortDictionary. After >>> initialisation is ts_cache memory context 55MB long and pg takes >>> 190MB. >> >> What's your tsearch configuration exactly? >> I have a 64bit Linux

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Dne 11.03.10 17:37, Tom Lane napsal(a): Zdenek Kotala writes: "-xO4 -xalias_level=basic" generates problem. "-xO3 -xalias_level=basic" works fine "-xO5" works fine As documentation say: Cite from Sun studio compiler guide: http://docs.sun.com/app/docs/doc/819-5265/bjapp?a=view xalias_l

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Dne 11.03.10 16:24, Greg Stark napsal(a): On Wed, Mar 10, 2010 at 11:37 PM, Tom Lane wrote: My conclusion is that this is probably a compiler bug. Both buildfarm animals appear to be using Sun Studio, although on different architectures which weakens the compiler-bug theory a bit. Even though

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Zdenek Kotala writes: > "-xO4 -xalias_level=basic" generates problem. > "-xO3 -xalias_level=basic" works fine > "-xO5" works fine > As documentation say: > Cite from Sun studio compiler guide: > http://docs.sun.com/app/docs/doc/819-5265/bjapp?a=view > xalias_level=basic > -- > I

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Hi Tom, I'm sorry that I did not look on it early. I played with it and there are some facts. gothic(sparc) and codlin(x86) uses Sun Studio 12 nad I setup them to use very high optimization. Gothic: --- -xalias_level=basic -xarch=native -xdepend -xmemalign=8s -xO5 -xprefetch=auto,explici

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

2010/3/11 Tom Lane : > Pavel Stehule writes: >> There are some wrong in our implementation NISortDictionary. After >> initialisation is ts_cache memory context 55MB long and pg takes >> 190MB. > > What's your tsearch configuration exactly? > files: http://www.pgsql.cz/data/czech.tar.gz configura

Re: [HACKERS] Can we still trust plperl?

Tom Lane wrote: AFAICS the DBA has to participate in setting up that module, so it's no different from any other PL language. You can insert stuff into the trusted interpreter in pltcl too. It's on the DBA's head to not insert stuff that's insecure --- so what? To my mind it's a feature not

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

Pavel Stehule writes: > There are some wrong in our implementation NISortDictionary. After > initialisation is ts_cache memory context 55MB long and pg takes > 190MB. What's your tsearch configuration exactly? regards, tom lane -- Sent via pgsql-hackers mailing list (pg

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Greg Stark writes: > On Wed, Mar 10, 2010 at 11:37 PM, Tom Lane wrote: >> My conclusion is that this is probably a compiler bug. > Could be this: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6750087 Hmmm ... that doesn't seem to be quite an exact match, because the setting and testing o

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Greg Stark writes: > Incidentally Zdenek came to the same conclusion that it was a compiler > bug in <4aa775a9.80...@sun.com> Drat, I had forgotten that exchange. I reconstructed Teodor's advice the hard way :-( regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] tsearch profiling - czech environment - take 55MB

2010/3/11 Pavel Stehule : > Hello > > There are some wrong in our implementation NISortDictionary. After > initialisation is ts_cache memory context 55MB long and pg takes > 190MB. > > dispell_init > cspell: 1024 total in 1 blocks; 136 free (1 chunks); 888 used > After dictionary loading > cspell:

[HACKERS] tsearch profiling - czech environment - take 55MB

Hello There are some wrong in our implementation NISortDictionary. After initialisation is ts_cache memory context 55MB long and pg takes 190MB. dispell_init cspell: 1024 total in 1 blocks; 136 free (1 chunks); 888 used After dictionary loading cspell: 3072 total in 2 blocks; 568 free (5 chunks);

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

Incidentally Zdenek came to the same conclusion that it was a compiler bug in <4aa775a9.80...@sun.com> -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] gothic_moth, codlin_moth failures on REL8_2_STABLE

On Wed, Mar 10, 2010 at 11:37 PM, Tom Lane wrote: > My conclusion is that this is probably a compiler bug.  Both buildfarm > animals appear to be using Sun Studio, although on different > architectures which weakens the compiler-bug theory a bit.  Even though > we are not seeing the failure in lat

Re: [HACKERS] Dyamic updates of NEW with pl/pgsql

On Thu, Mar 11, 2010 at 03:27:23PM +0100, strk wrote: > On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote: > > > Using an hstore in 9.0 it's not too bad, > > Does it still have a limit of 65535 bytes per field ? No. :) Cheers, David. -- David Fetter http://fetter.org/ Phone: +1 4

Re: [HACKERS] Can we still trust plperl?

Andrew Dunstan writes: > Last night my attention was drawn to this: > > I'm wondering if we can reasonably continue to support plperl as a > trusted language, or at least redefine what "trusted" ac

Re: [HACKERS] Server crash with older tzload library

Jeevan Chalke writes: > While setting timezone using SET command (say GMT+3:30), postgres sometimes > crashes randomly. I can't reproduce that: regression=# SET TimeZone = 'GMT+3:30'; SET regression=# SELECT '1969-12-31 20:30:00'::timestamptz; timestamptz

Re: [HACKERS] renameatt() can rename attribute of index, sequence, ...

2010/3/10 KaiGai Kohei : > Indeed, it is useful to allow renaming attribute of composite types. > > However, it is also useless to allow to rename attribute of sequences, > but harmless, like renames on indexes. It seems to me it is fair enough > to allow renaming attributes of tables, views and co

Re: [HACKERS] Can we still trust plperl?

Andrew Dunstan wrote: > I'm wondering if we can reasonably continue to support plperl as > a trusted language > would still be plperlu, with the downside that the functions have > to be installed by a superuser. One of my PGExperts colleagues > told me his reaction was "Well, I might just as w

Re: [HACKERS] Can we still trust plperl?

On Thu, Mar 11, 2010 at 09:31:46AM -0500, Andrew Dunstan wrote: > > Last night my attention was drawn to this: > > > > I'm wondering if we can reasonably continue to support plperl as a trusted > lang

Re: [HACKERS] operator exclusion constraints

Greg Stark writes: > There is a third option -- print PRIMARY keys twice, once as a btree > index and again as a constraint where it says somehting like "USING > index foo_pkey" No, that's exactly what I hate about the current behavior for exclusion constraints, and I'd like it even less for more

[HACKERS] Can we still trust plperl?

Last night my attention was drawn to this: I'm wondering if we can reasonably continue to support plperl as a trusted language, or at least redefine what "trusted" actually means. Does it mean "c

Re: [HACKERS] Dyamic updates of NEW with pl/pgsql

On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote: > Using an hstore in 9.0 it's not too bad, Does it still have a limit of 65535 bytes per field ? --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html -- Sent via pgsql-hackers mailing l

Re: [HACKERS] operator exclusion constraints

On Thu, Mar 11, 2010 at 5:29 AM, Tom Lane wrote: >> Indexes: >>     "foo_pkey" PRIMARY KEY, btree (f1), tablespace "ts1" >>     "foo_f2_exclusion" btree (f2), tablespace "ts1" >>     "foo_f3_exclusion" btree (f3) DEFERRABLE INITIALLY DEFERRED >> Exclusion constraints: >>     "foo_f2_exclusion" EXC

Re: [HACKERS] [patch] build issues on Win32

Greg Stark writes: > I would be sad about this. It seems likely there are platforms where > it's important. But I'm not really about to spend the effort to fix it > up myself and I agree it wouldn't be worth hacking the source to get > it to work. I'm a bit puzzled why the symbol conflicts occur o

Re: [HACKERS] [patch] build issues on Win32

2010/3/10 David Fetter : >> > --disable-shared, as previously mentioned. >> >> Oh.  Well, we don't really support that, and there is a proposal on >> the table to remove it altogether from the configure script.  I >> don't think we're going to contort our source code in order to make >> a marginal

Re: [HACKERS] Server crash with older tzload library

On Thu, Mar 11, 2010 at 12:09 PM, Heikki Linnakangas wrote: > Dave Page wrote: >> On Thu, Mar 11, 2010 at 10:51 AM, Jeevan Chalke >> wrote: >> >>> PFA, patch which will bring us up-to date to 2010c. >> >> Hi Jeevan, >> >> We're already up to 2010e in CVS: >> http://archives.postgresql.org/pgsql-c

Re: [HACKERS] Server crash with older tzload library

Dave Page wrote: > On Thu, Mar 11, 2010 at 10:51 AM, Jeevan Chalke > wrote: > >> PFA, patch which will bring us up-to date to 2010c. > > Hi Jeevan, > > We're already up to 2010e in CVS: > http://archives.postgresql.org/pgsql-committers/2010-03/msg00131.php > (not 2010d as the commit message mis

Re: [HACKERS] Server crash with older tzload library

On Thu, Mar 11, 2010 at 11:20 AM, Jeevan Chalke wrote: > BTW, I am using git repository and there I didn't see any changes on master > branch. > Is it possible to sync git with cvs? Hmm, that should happen automagically within a few minutes of a commit to CVS I thought. Magnus? -- Dave Page E

Re: [HACKERS] Server crash with older tzload library

Hi Dave, On Thu, Mar 11, 2010 at 4:38 PM, Dave Page wrote: > On Thu, Mar 11, 2010 at 10:51 AM, Jeevan Chalke > wrote: > > > PFA, patch which will bring us up-to date to 2010c. > > Hi Jeevan, > > We're already up to 2010e in CVS: > http://archives.postgresql.org/pgsql-committers/2010-03/msg00131

Re: [HACKERS] Server crash with older tzload library

On Thu, Mar 11, 2010 at 10:51 AM, Jeevan Chalke wrote: > PFA, patch which will bring us up-to date to 2010c. Hi Jeevan, We're already up to 2010e in CVS: http://archives.postgresql.org/pgsql-committers/2010-03/msg00131.php (not 2010d as the commit message mistakenly states) -- Dave Page Ente

Re: [HACKERS] Server crash with older tzload library

Oops... Forgot to attach the patch. Attached here Thanks On Thu, Mar 11, 2010 at 4:21 PM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Hi Tom, > > While setting timezone using SET command (say GMT+3:30), postgres sometimes > crashes randomly. > After debugging into the code, it is o

[HACKERS] Server crash with older tzload library

Hi Tom, While setting timezone using SET command (say GMT+3:30), postgres sometimes crashes randomly. After debugging into the code, it is observed that if tzload() call fails in pg_tzset() for whatever reason, the returned value of the function then have garbage values for state variable. And thi

Re: [HACKERS] Dyamic updates of NEW with pl/pgsql

> How can a pl/pgsql trigger change the > values of dynamic fields in NEW record ? > > By "dynamic" I mean that the field name > is a variable in the trigger context. It's not possible in plpgsql, but you can write plperl function, and later use it in plpgsql triggers. Regards, Dmitry -- Sen

Re: [HACKERS] Assertion failure twophase.c (2) (testing HS/SR)

On Thu, Mar 11, 2010 at 6:29 PM, Heikki Linnakangas wrote: > Erik Rijkers wrote: >> in a 9.0devel, primary+standby, cvs from 2010.03.04 01:30 >> >> With three patches: >> >>   new_smart_shutdown_20100201.patch http://archives.postgresql.org/pgsql-hackers/2010-01/msg03116.php >>   extend_format_o

Re: [HACKERS] Assertion failure twophase.c (2) (testing HS/SR)

Erik Rijkers wrote: > in a 9.0devel, primary+standby, cvs from 2010.03.04 01:30 > > With three patches: > > new_smart_shutdown_20100201.patch > extend_format_of_recovery_info_funcs_v4.20100303.patch Got a link to these two patches? I couldn't find them with a quick search. > fix-KnownAssi