Re: [HACKERS] enable-thread-safety defaults?

On Fri, Nov 20, 2009 at 7:39 AM, Magnus Hagander wrote: > 2009/11/20 Peter Eisentraut : >> On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote: >>> Is there any actual reason why we are building without thread safety >>> by default on most platforms? >> >> Consistent defaults on all platforms

Re: [HACKERS] Summary and Plan for Hot Standby

Simon, > This post isn't really very helpful. You aren't providing the > second part of the discussion, nor even requesting that this issue be > fixed. I can see such comments being taken up by people with a clear > interest in dissing HS. OK, I'm requesting that the issue be fixed. I'm not sur

Re: [HACKERS] enable-thread-safety defaults?

2009/11/20 Peter Eisentraut : > On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote: >> Is there any actual reason why we are building without thread safety >> by default on most platforms? > > Consistent defaults on all platforms? So why do we have largefile enabled by default? And zlib? And

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: > On Fri, 2009-11-20 at 06:47 +, Greg Stark wrote: >> I missed the original discussion of this problem, do you happen to >> remember the subject or url for the details? > > December 2008; hackers; you, me and Heikki. Yep: http://archives.postgresql.org/message-id/494b5ffe.4

Re: [HACKERS] Syntax for partitioning

On Thu, 2009-11-19 at 10:53 -0500, Robert Haas wrote: > On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote: > > Hi, > > > > Robert Haas wrote: > >> > >> Settling on a syntax, and an internal representation for that syntax, > > > > I've been under the impression that this was only about syntax. W

Re: [HACKERS] enable-thread-safety defaults?

On fre, 2009-11-20 at 02:41 +0100, Magnus Hagander wrote: > Is there any actual reason why we are building without thread safety > by default on most platforms? Consistent defaults on all platforms? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your s

Re: [HACKERS] Python 3.1 support

On tor, 2009-11-19 at 13:12 -0700, James Pye wrote: > > I think of a PL/Python function as a Python script file stored > > in the database. > > For Python, I think that's a mistake. Python scripts are independent > applications. Is there any precedent for the sort of behavior that you are implem

Re: [HACKERS] Summary and Plan for Hot Standby

On Fri, 2009-11-20 at 06:47 +, Greg Stark wrote: > On Fri, Nov 20, 2009 at 2:58 AM, Andrew Dunstan wrote: > > Right. The major use I was hoping for from HS was exactly to be able to run > > long-running queries. In once case I am thinking of we have moved the > > business intelligence uses off

Re: [HACKERS] Summary and Plan for Hot Standby

On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote: > On 11/15/09 11:07 PM, Heikki Linnakangas wrote: > > - When replaying b-tree deletions, we currently wait out/cancel all > > running (read-only) transactions. We take the ultra-conservative stance > > because we don't know how recent the tuples

Re: [HACKERS] Syntax for partitioning

Peter Eisentraut writes: > 2) I would prefer that you apply sizeof on the variable, not on the > type. That way, the expression is independent of any type changes of > the variable, and can be reviewed without having to scroll around for > the variable definition. FWIW, I think the general proje

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Joachim Wieland wrote: > The example you brought up fails if > Session 2 disregards the notifications based on the current set of > channels that it is listening to at this point. Right. Session 2 might not be listening at all yet. > If I understand you > correctly what you are suggesting is to n

Re: [HACKERS] Summary and Plan for Hot Standby

On Fri, Nov 20, 2009 at 2:58 AM, Andrew Dunstan wrote: > Right. The major use I was hoping for from HS was exactly to be able to run > long-running queries. In once case I am thinking of we have moved the > business intelligence uses off the OLTP server onto a londiste replica, and > I was really

Re: [HACKERS] Why do OLD and NEW have special internal names?

On 11/20/2009 1:12 AM, Tom Lane wrote: Jan Wieck writes: But this brings up another point about the recent discussion of what RENAME is good for. Removing RENAME may conflict with using OLD/NEW in UPDATE ... RETURNING. No? Um ... not sure why. Specific example please?

Re: [HACKERS] Summary and Plan for Hot Standby

On Fri, Nov 20, 2009 at 11:14 AM, Josh Berkus wrote: > On 11/15/09 11:07 PM, Heikki Linnakangas wrote: >> - When replaying b-tree deletions, we currently wait out/cancel all >> running (read-only) transactions. We take the ultra-conservative stance >> because we don't know how recent the tuples be

Re: [HACKERS] Summary and Plan for Hot Standby

Joshua D. Drake wrote: > On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote: >> On 11/15/09 11:07 PM, Heikki Linnakangas wrote: >>> - When replaying b-tree deletions, we currently wait out/cancel all >>> running (read-only) transactions. We take the ultra-conservative stance >>> because we don't

Re: [HACKERS] Syntax for partitioning

Nikhil Sontakke writes: >>> partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); >> >> 1) Please stop casting the results of palloc and malloc.  We are not >> writing C++ here. > I thought it was/is a good C programming practice to typecast (void *) > always to the returning struc

Re: [HACKERS] Summary and Plan for Hot Standby

Simon Riggs wrote: On Thu, 2009-11-19 at 17:15 +0900, Tatsuo Ishii wrote: Simon Riggs wrote: Recovery does *not* take the same locks as the original statements on the master took. For example, the WAL record for an INSERT just makes its changes without acquiring locks. This is OK as long as we

Re: [HACKERS] Why do OLD and NEW have special internal names?

Jan Wieck writes: > But this brings up another point about the recent discussion of what > RENAME is good for. Removing RENAME may conflict with using OLD/NEW in > UPDATE ... RETURNING. No? Um ... not sure why. Specific example please? regards, tom lane -- Sent via p

Re: [HACKERS] Python 3.1 support

On tor, 2009-11-19 at 13:43 -0500, Tom Lane wrote: > But in any case, my main concern here is that I don't want to have > to predetermine which python version a user of Red Hat/Fedora will > have to use. If they can only use one at a time, that's still a > good bit better than not having a choice

Re: [HACKERS] Summary and Plan for Hot Standby

On Thu, 2009-11-19 at 17:15 +0900, Tatsuo Ishii wrote: > > Simon Riggs wrote: > > > Recovery does *not* take the same locks as the original statements on > > > the master took. For example, the WAL record for an INSERT just makes > > > its changes without acquiring locks. This is OK as long as we o

Re: [HACKERS] Summary and Plan for Hot Standby

On Thu, 2009-11-19 at 10:13 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > Recovery does *not* take the same locks as the original statements on > > the master took. For example, the WAL record for an INSERT just makes > > its changes without acquiring locks. This is OK as long as we onl

Re: [HACKERS] Syntax for partitioning

On fre, 2009-11-20 at 11:14 +0530, Nikhil Sontakke wrote: > Hi, > > >> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); > > > > 1) Please stop casting the results of palloc and malloc. We are not > > writing C++ here. > > > > I thought it was/is a good C programming practice

Re: [HACKERS] Union test case broken in make check?

Kenneth Marshall writes: > Without an order by, the order is not defined. Yeah, but with the same data and the same software it should generally give the same result; as evidenced by the fact that these same regression tests have worked for most people for years. There's something odd happening

Re: [HACKERS] Syntax for partitioning

Hi, >> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); > > 1) Please stop casting the results of palloc and malloc.  We are not > writing C++ here. > I thought it was/is a good C programming practice to typecast (void *) always to the returning structure type!! Regards, Nik

Re: [HACKERS] operator exclusion constraints

RObert, > I guess I'm going to have to vote -1 on this proposal. I code see > inventing a pgsql-specific SQLSTATE value for exclusion constraints, > since they will be a pgsql-specific extension, but reusing the unique > key violation value seems misleading. I admit it may help in a > limited nu

Re: [HACKERS] Why do OLD and NEW have special internal names?

On 11/5/2009 4:33 PM, Tom Lane wrote: So I was testing the next step of plpgsql modification, namely actually letting the parser hooks do something, and it promptly blew up in trigger functions, like so: + ERROR: OLD used in query that is not in a rule + LINE 1: SELECT OLD + ^

Re: [HACKERS] AFTER triggers & RETURN

On 11/5/2009 8:10 PM, Robert Haas wrote: On Thu, Nov 5, 2009 at 4:57 PM, Tom Lane wrote: Andrew Dunstan writes: Robert Haas wrote: Since the return value is ignored anyway, why do we have to complain if it's left out altogether? Granted, it's easy to work around, but still. Isn't is a re

Re: [HACKERS] operator exclusion constraints

On Wed, Nov 18, 2009 at 9:21 AM, Josh Berkus wrote: > All, > > FWIW, I'm doing a redesign of a client's production web application > right now.  I was able, by combining OEC and the Period type from > pgfoundry, to make a set of constraints for declaratively asserting in a > sports database: > > T

Re: [HACKERS] operator exclusion constraints

On Wed, Nov 18, 2009 at 9:00 AM, Jeff Davis wrote: > I'm in Tokyo right now, so please excuse my abbreviated reply. > > On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote: >> Forgive me if this is discussed before, but why does this store the >> strategy numbers of the relevant operators instead

Re: [HACKERS] Summary and Plan for Hot Standby

Joshua D. Drake wrote: On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote: On 11/15/09 11:07 PM, Heikki Linnakangas wrote: - When replaying b-tree deletions, we currently wait out/cancel all running (read-only) transactions. We take the ultra-conservative stance because we don't kno

Re: [HACKERS] Union test case broken in make check?

Then I guess that we need to fix the test. Emmanuel Kenneth Marshall wrote: Without an order by, the order is not defined. The answers are the same but the test gives a false failure because of the lack of ordering. Regards, Ken On Thu, Nov 19, 2009 at 07:54:30PM -0500, Emmanuel Cecchet wrote

Re: [HACKERS] Union test case broken in make check?

Without an order by, the order is not defined. The answers are the same but the test gives a false failure because of the lack of ordering. Regards, Ken On Thu, Nov 19, 2009 at 07:54:30PM -0500, Emmanuel Cecchet wrote: > Tom Lane wrote: >> Andrew Dunstan writes: >> >>> Emmanuel Cecchet wrote:

[HACKERS] column DEFAULTs and prepared statements

Hi While trying to come up with a patch to handle domain DEFAULTs in plpgsql I've stumbled across the following behavior regarding domain DEFAULTs and prepared statements. session 1: create domain myint as int default 0 ; session 1: create table mytable (i myint) ; session 2: prepare ins as inse

Re: [HACKERS] Summary and Plan for Hot Standby

On Fri, 2009-11-20 at 11:14 +0900, Josh Berkus wrote: > On 11/15/09 11:07 PM, Heikki Linnakangas wrote: > > - When replaying b-tree deletions, we currently wait out/cancel all > > running (read-only) transactions. We take the ultra-conservative stance > > because we don't know how recent the tuples

Re: [HACKERS] Summary and Plan for Hot Standby

On 11/15/09 11:07 PM, Heikki Linnakangas wrote: > - When replaying b-tree deletions, we currently wait out/cancel all > running (read-only) transactions. We take the ultra-conservative stance > because we don't know how recent the tuples being deleted are. If we > could store a better estimate for

[HACKERS] DEFAULT of domain ignored in plpgsql (8.4.1)

Hi It seems that pl/pgsql ignores the DEFAULT value of domains for local variables. With the following definitions in place create domain myint as int default 0; create or replace function myint() returns myint as $body$ declare v_result myint; begin return v_result; end; $body$ language plp

[HACKERS] enable-thread-safety defaults?

Is there any actual reason why we are building without thread safety by default on most platforms? Seems I get asked that every time somebody forgets to add a "--enable-thread-safety". Wouldn't it be more logical to have that be the default, and provide "--disable-thread-safety" if there are platfo

Re: [HACKERS] [COMMITTERS] pgsql: /home/peter/commit-msg

2009/11/16 Peter Eisentraut : > On mån, 2009-11-16 at 10:05 -0500, Tom Lane wrote: >> Heikki Linnakangas writes: >> > Magnus Hagander wrote: >> >> On Mon, Nov 16, 2009 at 08:29, David Fetter wrote: >> >>> On Mon, Nov 16, 2009 at 06:56:54AM +0200, Peter Eisentraut wrote: >> Yeah, sorry guys.

Re: [HACKERS] Union test case broken in make check?

Tom Lane wrote: Andrew Dunstan writes: Emmanuel Cecchet wrote: Is it just me or the union test case fails in CVS head? The buildfarm is pretty much all green: So it looks like it's you :-) When in doubt, try "make

[HACKERS] plruby code and postgres ?

Does anyone have a link for pl/ruby? I found a link under the postgres documentation and found a web site from there talking about the code. However when I clicked on the link to download it I noticed ftp wouldn't respond on their site. Thanks! -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] plperl and inline functions -- first draft

On Wed, Nov 18, 2009 at 12:38:00PM +0200, Alexey Klyukin wrote: > Yes, current_call_data can't be allocate in the SPI memory context, since > it's used to extract the result after SPI_finish is called, although it > doesn't lead to problems here since no result is returned. Anyway, I'd move > SP

Re: [HACKERS] Union test case broken in make check?

Andrew Dunstan writes: > Emmanuel Cecchet wrote: >> Is it just me or the union test case fails in CVS head? > The buildfarm is pretty much all green: > > So it looks like it's you :-) When in doubt, try "make distclean" and a full rebuild befo

Re: [HACKERS] Syntax for partitioning

On ons, 2009-11-18 at 13:52 +0900, Itagaki Takahiro wrote: > > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); > > Oops, it should be "p"alloc. Thanks. A very low-level comment: 1) Please stop casting the results of palloc and malloc. We are not writing C++ here. 2) I would

Re: [HACKERS] Timezones (in 8.5?)

> "Kevin" == Kevin Grittner writes: >>> For example, if you have a type T which incorporates a timestamp >>> and a timezone, what semantics does the T = T operator have? What >>> semantics apply if the definitions of timezones change? Kevin> I'd rather sort that out once and implement

Re: [HACKERS] Patch to change a pg_restore message

Le jeudi 19 novembre 2009 à 23:05:16, Peter Eisentraut a écrit : > On tor, 2009-11-19 at 16:47 +0100, Guillaume Lelarge wrote: > > "pg_restore --help" gives this message for the --no-tablespaces > > parameter: > > > > --no-tablespaces do not dump tablespace assignments > > > > The message

Re: [HACKERS] Patch to change a pg_restore message

On tor, 2009-11-19 at 16:47 +0100, Guillaume Lelarge wrote: > "pg_restore --help" gives this message for the --no-tablespaces parameter: > > --no-tablespaces do not dump tablespace assignments > > The message should say "restore" and not "dump". You'll find a patch attached > that fixe

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Thu, Nov 19, 2009 at 6:55 PM, Heikki Linnakangas wrote: > Hmm, ignoring 2PC for a moment, I think the patch suffers from a little > race condition: > > Session 1: BEGIN; > Session 1: INSERT INTO foo ..; > Session 1: NOTIFY 'foo'; > Session 1: COMMIT -- commit begins > Session 1: [commit process

Re: [HACKERS] PL/Python array support

On fre, 2009-11-13 at 18:46 +0300, Teodor Sigaev wrote: > CREATE OR REPLACE FUNCTION incr(stuff int[]) RETURNS int[] AS $$ > for x in stuff: > yield x+1 > $$ > LANGUAGE 'plpythonu'; > > # select incr(ARRAY[1,2,3]); > ERROR: invalid memory alloc request size 18446744073709551608 > CONTEXT: w

Re: [HACKERS] Union test case broken in make check?

Emmanuel Cecchet wrote: Hi, Is it just me or the union test case fails in CVS head? The buildfarm is pretty much all green: So it looks like it's you :-) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] Very bad FTS performance with the Polish config

Tom Lane wrote: *SNIP* So about 55% of the time is going into affix pattern matching. I wonder whether that couldn't be made faster. A lot of the cycles are spent on coping with variable-length characters --- perhaps the ispell code should convert to wchar representation before doing this? T

Re: [HACKERS] Listen / Notify - what to do when the queue is full

g...@turnstep.com ("Greg Sabino Mullane") writes: >> BTW, did we discuss the issue of 2PC transactions versus notify? >> The current behavior of 2PC with notify is pretty cheesy and will >> become more so if we make this change --- you aren't really >> guaranteed that the notify will happen, even t

[HACKERS] Union test case broken in make check?

Hi, Is it just me or the union test case fails in CVS head? manu -- Emmanuel Cecchet Aster Data Web: http://www.asterdata.com -- 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] Question about ECPGset_noind_null() and ECPGis_noind_null()

Tom Lane írta: > Andrew Dunstan writes: > >> Boszormenyi Zoltan wrote: >> >>> Is it *really* a bug? I recalled a comment from my C teacher >>> in '92 or '93 about this exact issue, that the prefix/postfix >>> increment/decrement operators are executed in the >>> statement in an implementat

Re: [HACKERS] Architecture of walreceiver (Streaming Replication)

Fujii Masao wrote: > On Tue, Nov 3, 2009 at 12:33 AM, Robert Haas wrote: >> On Mon, Nov 2, 2009 at 10:14 AM, Euler Taveira de Oliveira >> wrote: >>> BTW, are you going to submit another WIP patch for next commitfest? >> Well, Heikki was going to keep working on this and Hot Standby between >> Com

Re: [HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Andrew Dunstan writes: > Boszormenyi Zoltan wrote: >> Is it *really* a bug? I recalled a comment from my C teacher >> in '92 or '93 about this exact issue, that the prefix/postfix >> increment/decrement operators are executed in the >> statement in an implementation-defined order, > Not if they

Re: [HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Boszormenyi Zoltan wrote: Is it *really* a bug? I recalled a comment from my C teacher in '92 or '93 about this exact issue, that the prefix/postfix increment/decrement operators are executed in the statement in an implementation-defined order, Not if they come after a short-circuit oper

Re: [HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Boszormenyi Zoltan írta: > Tom Lane írta: > >> Boszormenyi Zoltan writes: >> >> >>> for (; length > 0 && ptr[--length] == 0xff;); >>> >>> >> >> >>> I suspect that GCC does the "--length" after checking >>> "length > 0" and before checking the "ptr[...] == 0xf

Re: [HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Tom Lane írta: > Boszormenyi Zoltan writes: > >> for (; length > 0 && ptr[--length] == 0xff;); >> > > >> I suspect that GCC does the "--length" after checking >> "length > 0" and before checking the "ptr[...] == 0xff", >> but HP CC does it before checking "length > 0". >> >

Re: [HACKERS] Python 3.1 support

On Nov 19, 2009, at 11:32 AM, Peter Eisentraut wrote: > But you wouldn't, for example, get away with breaking SQL (or even > improving it incompatibly) to facilitate a better elog. This doesn't fit the situation. I'm not breaking PL/Python. I'm trying to add PL/Python3. =) > I think of a PL/Pyth

Re: [HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Tom Lane wrote: Boszormenyi Zoltan writes: for (; length > 0 && ptr[--length] == 0xff;); I suspect that GCC does the "--length" after checking "length > 0" and before checking the "ptr[...] == 0xff", but HP CC does it before checking "length > 0". If it does, that

Re: [HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Boszormenyi Zoltan writes: > for (; length > 0 && ptr[--length] == 0xff;); > I suspect that GCC does the "--length" after checking > "length > 0" and before checking the "ptr[...] == 0xff", > but HP CC does it before checking "length > 0". If it does, that is *unquestionably* a bug in HP

Re: [HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Boszormenyi Zoltan írta: > Hi, > > my question is that what platform were these > functions developed and tested? > > We have come across a value that fails a NOT NULL > constraint upon INSERT under HP-UX/IA64, but not > under x86-64 Linux. The value in question is > 1.9998 assigned to

Re: [HACKERS] TRIGGER with WHEN clause

Itagaki Takahiro writes: > [ TRIGGER WHEN patch ] I'm starting to work this over now, and I've found one rather serious omission: FreeTriggerDesc doesn't free the expression tree. This means that trigger WHEN clauses will leak memory in CacheMemoryContext any time we do a relcache flush on the r

Re: [HACKERS] Python 3.1 support

Peter Eisentraut writes: > By the way, it occurred to me that having two different versions of > libpython loaded into the same process is probably not going to work > sanely. Why not? There's no way they'd even know about each other. We tell the loader not to make the symbols globally visible.

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 13:36 -0700, James Pye wrote: > On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote: > > The question is whether it helps the user, not the implementer. > > Sure, but do you have a patch waiting to implement tracebacks? > > I'd argue the reason it's never been done is due to

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 12:28 -0500, Tom Lane wrote: > "Joshua D. Drake" writes: > > On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote: > >> Yes. That's exactly what I was complaining about upthread. I'm not > >> a Python user, but from what I can gather of the 2-to-3 changes, > >> having to choos

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Tom Lane wrote: > Heikki Linnakangas writes: >> A better approach is to do something similar to what we do now: at >> prepare, just store the notifications in the state file like we do >> already. In notify_twophase_postcommit(), copy the messages to the >> shared queue. Although it's the same app

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Tom Lane wrote: "Florian G. Pflug" writes: Tom Lane wrote: This is still ignoring the complaint: you are creating a clear risk that COMMIT PREPARED will fail. I'd see no problem with "COMMIT PREPARED" failing, as long as it was possible to retry the COMMIT PREPARED at a later time. There su

Re: [HACKERS] Python 3.1 support

On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote: > The other approach, which is what James Pye's > new implementation proposes (as I understand it), is to convert > PostgreSQL types into specially made Python objects, such as > Postgres.types.record or Postgres.types.timestamp. Convert is not

Re: [HACKERS] Timezones (in 8.5?)

Robert Haas wrote: > On Wed, Nov 18, 2009 at 11:18 PM, Andrew Gierth > wrote: >>> "Kevin" == "Kevin Grittner" writes: >> >> >> If he meant (A), then you store the event as: >> >> (ts,tz) = (timestamp '2010-07-27 10:30:00', >> >> 'Chile/Santiago') >> >> >> If he meant (B), then you store

Re: [HACKERS] Listen / Notify - what to do when the queue is full

"Florian G. Pflug" writes: > Tom Lane wrote: >> This is still ignoring the complaint: you are creating a clear risk >> that COMMIT PREPARED will fail. > I'd see no problem with "COMMIT PREPARED" failing, as long as it was > possible to retry the COMMIT PREPARED at a later time. There surely are

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Tom Lane wrote: Heikki Linnakangas writes: A better approach is to do something similar to what we do now: at prepare, just store the notifications in the state file like we do already. In notify_twophase_postcommit(), copy the messages to the shared queue. Although it's the same approach we

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Thu, 19 Nov 2009 14:23:57 +0100 Joachim Wieland wrote: > On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum > wrote: > > And in addition i don't like the idea of having the sender sitting > > around until there's room for more messages in the queue, because some > > very old backends did

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Heikki Linnakangas writes: > A better approach is to do something similar to what we do now: at > prepare, just store the notifications in the state file like we do > already. In notify_twophase_postcommit(), copy the messages to the > shared queue. Although it's the same approach we have now, it

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Florian G. Pflug wrote: > Heikki Linnakangas wrote: >> At a quick glance, it doesn't seem hard to support 2PC. Messages should >> be put to the queue at prepare, as just before normal commit, but the >> backends won't see them until they see that the XID has committed. > > Yeah, but if the server

Re: [HACKERS] Syntax for partitioning

On Thu, Nov 19, 2009 at 9:58 AM, Markus Wanner wrote: > Hi, > > Robert Haas wrote: >> >> Settling on a syntax, and an internal representation for that syntax, > > I've been under the impression that this was only about syntax. What are the > internal additions? I haven't looked at it in detail, b

Re: [HACKERS] Very bad FTS performance with the Polish config

Wojciech Knapik writes: > Tom Lane wrote: >> I tried to duplicate this test, but got no further than here: >> ERROR: syntax error >> CONTEXT: line 174 of configuration file >> "/home/tgl/testversion/share/postgresql/tsearch_data/polish.affix": " L E C >> > -C,GÅEM

[HACKERS] Patch to change a pg_restore message

Hi, "pg_restore --help" gives this message for the --no-tablespaces parameter: --no-tablespaces do not dump tablespace assignments The message should say "restore" and not "dump". You'll find a patch attached that fixes this issue. Thanks. Regards. -- Guillaume. http://www.postg

Re: [HACKERS] Summary and Plan for Hot Standby

Tom Lane wrote: > Heikki Linnakangas writes: >> Tatsuo Ishii wrote: >>> Sorry for confusion. My example is under normal PostgreSQL, not under >>> HS enabled. > >> You get the same result in standby: > > AFAICT Tatsuo's example just shows that we might wish to add a check > for read-only transact

Re: [HACKERS] Summary and Plan for Hot Standby

Heikki Linnakangas writes: > Tatsuo Ishii wrote: >> Sorry for confusion. My example is under normal PostgreSQL, not under >> HS enabled. > You get the same result in standby: AFAICT Tatsuo's example just shows that we might wish to add a check for read-only transaction mode before parsing an INS

Re: [HACKERS] Rejecting weak passwords

"Albe Laurenz" writes: > I did not know that contrib modules get translated too, else I would > have thrown the error messages there. I'm not sure whether contrib is currently covered by the translation teams, but it could someday be. In any case, an inadequate error message is not made less ina

Re: [HACKERS] xpath_table equivalent

Robert Haas wrote: On Thu, Nov 19, 2009 at 12:03 AM, Scott Bailey wrote: The nice thing about XMLTABLE is that it adds xquery support. I think the majority of xquery engines seem to be written in Java. XQuilla is C++. I'm not sure if our licensing is compatible, but it I would love the iro

Re: [HACKERS] Syntax for partitioning

Hi, Robert Haas wrote: Settling on a syntax, and an internal representation for that syntax, I've been under the impression that this was only about syntax. What are the internal additions? Generally speaking, I'd agree with Simon or even vote for doing the internals first and add the synt

Re: [HACKERS] xpath_table equivalent

On Thu, Nov 19, 2009 at 12:03 AM, Scott Bailey wrote: > The nice thing about XMLTABLE is that it adds xquery support. I think the > majority of xquery engines seem to be written in Java. XQuilla is C++. I'm > not sure if our licensing is compatible, but it I would love the irony of > using Berkele

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Heikki Linnakangas wrote: Joachim Wieland wrote: On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane wrote: Yes, I have been thinking about that also. So what should happen when you prepare a transaction that has sent a NOTIFY before? From the user's point of view, nothing should happen at prepare. At

Re: [HACKERS] Listen / Notify - what to do when the queue is full

Joachim Wieland wrote: > On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane wrote: >> BTW, did we discuss the issue of 2PC transactions versus notify? >> The current behavior of 2PC with notify is pretty cheesy and will >> become more so if we make this change --- you aren't really >> guaranteed that the n

Re: [HACKERS] xpath_table equivalent

Scott Bailey wrote: I agree that the syntax of XMLTABLE is odd. But not demonstrably worse than xpathtable. That's not saying much. I dislike both. Why the SQL committee feels the need to invent arcane special case grammar rules is beyond me. I understand why the author of xpathtable des

Re: [HACKERS] Timezones (in 8.5?)

On Wed, Nov 18, 2009 at 11:18 PM, Andrew Gierth wrote: >> "Kevin" == "Kevin Grittner" writes: > >  >> If he meant (A), then you store the event as: >  >> (ts,tz) = (timestamp '2010-07-27 10:30:00', >  >> 'Chile/Santiago') > >  >> If he meant (B), then you store the event as >  >> (tsz,tz) = (

Re: [HACKERS] Listen / Notify - what to do when the queue is full

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 >> (4) drop *old* notifications if the queue is full. >> >> Since everyone has made the point that LISTEN is not m

Re: [HACKERS] add more frame types in window functions (ROWS)

2009/11/19 Andrew Gierth : > Here's the rest of the review, as far as I've taken it given the > problems with the code. > > The patch applied cleanly and includes regression tests but not docs. > > Small nitpicks: there are some comments not updated (e.g. the > big one at the start of eval_windowag

[HACKERS] Question about ECPGset_noind_null() and ECPGis_noind_null()

Hi, my question is that what platform were these functions developed and tested? We have come across a value that fails a NOT NULL constraint upon INSERT under HP-UX/IA64, but not under x86-64 Linux. The value in question is 1.9998 assigned to a "double" variable. Under HP-UX/IA64, te

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Thu, Nov 19, 2009 at 1:51 PM, Andreas 'ads' Scherbaum wrote: > And in addition i don't like the idea of having the sender sitting > around until there's room for more messages in the queue, because some > very old backends didn't remove the stuff from the same. The only valid reason why a back

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Thu, Nov 19, 2009 at 4:12 AM, Tom Lane wrote: > There will now be a nonzero chance > of transactions failing at commit because of queue full.  If the > chance is large this will be an issue.  (Is it sane to wait for > the queue to be drained?) Exactly. The whole idea of putting the notificatio

Re: [HACKERS] Listen / Notify - what to do when the queue is full

On Wed, 18 Nov 2009 22:12:18 -0500 Tom Lane wrote: > Josh Berkus writes: > > (4) drop *old* notifications if the queue is full. > > > Since everyone has made the point that LISTEN is not meant to be a full > > queueing system, I have no problem dropping notifications LRU-style. > > NO, NO, NO,

Re: [HACKERS] Very bad FTS performance with the Polish config

ts_headline calls ts_lexize equivalent to break the text. Off course there is algorithm to process the tokens and generate the headline. I would be really surprised if the algorithm to generate the headline is somehow dependent on language (as it only processes the tokens). So Oleg is right w

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 11:32 -0800, Nathan Boley wrote: > I took a cursory look at this patch and, while the logic seems sound > and roughly in line with the suggested python porting procedure, I'm > not quite certain what this implies for potential future patches. > > For instance, if I wanted to

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 08:43 -0800, Nathan Boley wrote: > > Again, I'm only one user. But so far I haven't seen anyone else speak > > up here, and clearly accepting this for inclusion will need nontrivial > > convincing. > > Well, FWIW, I am excited about better type integration. Let's clarify, a

Re: [HACKERS] Python 3.1 support

On ons, 2009-11-18 at 09:48 -0800, Joshua D. Drake wrote: > Although I wonder if longer > term (2.x is going to be support a long time) we will end up with > frustration within the single source file trying to keep things > straight. There are five million Python modules with C code out there with

Re: [HACKERS] Summary and Plan for Hot Standby

Tatsuo Ishii wrote: > Sorry for confusion. My example is under normal PostgreSQL, not under > HS enabled. You get the same result in standby: postgres=# begin; BEGIN postgres=# prepare a(int) as insert into foo values($1); PREPARE postgres=# SELECT * FROM pg_locks; locktype │ database │ relati

Re: [HACKERS] add more frame types in window functions (ROWS)

Here's the rest of the review, as far as I've taken it given the problems with the code. The patch applied cleanly and includes regression tests but not docs. Small nitpicks: there are some comments not updated (e.g. the big one at the start of eval_windowaggregates). A couple of lines are commen

  1   2   >