[HACKERS] Kernel changes to O_SYNC / O_DSYNC

Hi folks It looks like there are some upcoming changes to the Linux kernel's handling of O_SYNC and O_DSYNC that I thought might be worth pointing out: http://lwn.net/Articles/350219/ -- Craig Ringer -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to y

Re: [HACKERS] Largeobject Access Controls (r2460)

Robert Haas wrote: > 2009/12/16 KaiGai Kohei : > ? ?long desc: When turned on, privilege checks on large objects perform > with > ? ? ? ? ? ? ? backward compatibility as 8.4.x or earlier releases. > Mostly English quality, but there are some other issues too. Proposed > patch a

Re: [HACKERS] Largeobject Access Controls (r2460)

(2009/12/17 13:20), Robert Haas wrote: > 2009/12/16 KaiGai Kohei: >> (2009/12/17 7:25), Robert Haas wrote: >>> On Thu, Dec 10, 2009 at 10:41 PM, Takahiro Itagaki >>> wrote: KaiGai Koheiwrote: > What's your opinion about: > long desc: When turned on, privilege chec

Re: [HACKERS] Range types

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 16, 2009 at 04:45:54PM -0300, Alvaro Herrera wrote: > to...@tuxteam.de wrote: > > > (and as Andrew Dunstan pointed out off-list: I was wrong with my bold > > assertion that one can squeeze infinitely many (arbitrary length) > > strings bet

Re: [HACKERS] Largeobject Access Controls (r2460)

2009/12/16 KaiGai Kohei : > (2009/12/17 7:25), Robert Haas wrote: >> On Thu, Dec 10, 2009 at 10:41 PM, Takahiro Itagaki >>  wrote: >>> >>> KaiGai Kohei  wrote: >>> What's your opinion about:    long desc: When turned on, privilege checks on large objects perform with          

Re: [HACKERS] SE-PostgreSQL/Lite Review

(2009/12/12 6:27), Robert Treat wrote: >> One point. I'd like to introduce a use case without row-level granularity. >> >> The page.24 in this slide: >>http://sepgsql.googlecode.com/files/JLS2009-KaiGai-LAPP_SELinux.pdf >> >> shows SELinux performs as a logical wall between virtual domains in >

Re: [HACKERS] Does "verbose" Need to be Reserved?

> "Euler" == Euler Taveira de Oliveira writes: > David E. Wheeler escreveu: >> A list of such words, to be included in the Changes file, would be >> most useful I expect. I'm guessing "Keywords listed as reserved in appendix C no longer work as variable names in pl/pgsql, even though they

Re: [HACKERS] Does "verbose" Need to be Reserved?

David E. Wheeler escreveu: > A list of such words, to be included in the Changes file, would be most > useful I expect. > As we're on this topic, could we expose keywords in a system view like say pg_keywords? -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers

Re: [HACKERS] determine snapshot after obtaining locks for first statement

"Kevin Grittner" writes: > Tom Lane wrote: >> (Besides which the lock acquired by UPDATE isn't exclusive and >> wouldn't block anyway...) > It blocks other UPDATEs. Not at the table level. If you could lock only at the tuple level maybe you'd have something, but it seems like you can't find t

Re: [HACKERS] PATCH: Add hstore_to_json()

On Wed, Dec 16, 2009 at 5:58 PM, David E. Wheeler wrote: > On Dec 16, 2009, at 2:45 PM, Robert Haas wrote: > >> I like it.  The regression tests you've added seem to cover a lot of >> cases that aren't really different without covering some that are >> probably worth trying, like multiple key/valu

Re: [HACKERS] determine snapshot after obtaining locks for first statement

Tom Lane wrote: > With the code you give, the snapshot is acquired at the beginning > of processing the UPDATE command, before it finds out that the > target is t2a and acquires a lock on it. Right. The optimization would be to wait to determine the snapshot for the UPDATE statement until we

Re: [HACKERS] Largeobject Access Controls (r2460)

(2009/12/17 7:25), Robert Haas wrote: > On Thu, Dec 10, 2009 at 10:41 PM, Takahiro Itagaki > wrote: >> >> KaiGai Kohei wrote: >> >>> What's your opinion about: >>>long desc: When turned on, privilege checks on large objects perform with >>> backward compatibility as 8.4.x or ea

Re: [HACKERS] determine snapshot after obtaining locks for first statement

"Kevin Grittner" writes: > Tom Lane wrote: >> Yes --- it's not an "optimization", it's necessary for basic >> functionality to work correctly. > Hmmm... Testing seems to indicate that this doesn't work per the > described optimization: You'd need an explicit LOCK TABLE t2a after starting the

Re: [HACKERS] determine snapshot after obtaining locks for first statement

Tom Lane wrote: > "Kevin Grittner" writes: >> The Cahill thesis mentions an interesting optimization -- they >> defer determination of the snapshot until after any locks >> required for the first statement have been acquired. Where the >> first statement was, for example, an UPDATE, this reduced

Re: [HACKERS] PATCH: Add hstore_to_json()

On Dec 16, 2009, at 2:45 PM, Robert Haas wrote: > I like it. The regression tests you've added seem to cover a lot of > cases that aren't really different without covering some that are > probably worth trying, like multiple key/value pairs. Also, the > comment in the function you've added looks

Re: [HACKERS] Does "verbose" Need to be Reserved?

On Dec 16, 2009, at 2:29 PM, Tom Lane wrote: >> Looking at it more closely, this is likely to be fallout from the >> plpgsql lexer/parser changes; it probably worked before only because >> plpgsql was doing its own thing rather than using the main lexer. > > Hmm .. yeah, words that are reserved a

Re: [HACKERS] determine snapshot after obtaining locks for first statement

"Kevin Grittner" writes: > The Cahill thesis mentions an interesting optimization -- they defer > determination of the snapshot until after any locks required for the > first statement have been acquired. Where the first statement was, > for example, an UPDATE, this reduced re-reads or rollbacks

Re: [HACKERS] PATCH: Add hstore_to_json()

On Wed, Dec 16, 2009 at 2:28 PM, David E. Wheeler wrote: > I just realized that this was easy to do, and despite my complete lack of C > skillz was able to throw this together in a couple of hours. It might be > handy to some, though the possible downsides are: > > * No json_to_hstore(). > * Lea

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 14:29 +0100, to...@tuxteam.de wrote: > This alone would practically preclude discrete -- int and float would > behave quite differently (float's "granules" growing towards the edges > or having to choose a bigger granule for float than for int in the first > place). It may be

Re: [HACKERS] Does "verbose" Need to be Reserved?

Andrew Gierth writes: > Looking at it more closely, this is likely to be fallout from the > plpgsql lexer/parser changes; it probably worked before only because > plpgsql was doing its own thing rather than using the main lexer. Hmm .. yeah, words that are reserved according to the main grammar c

Re: [HACKERS] Largeobject Access Controls (r2460)

On Thu, Dec 10, 2009 at 10:41 PM, Takahiro Itagaki wrote: > > KaiGai Kohei wrote: > >> What's your opinion about: >>   long desc: When turned on, privilege checks on large objects perform with >>              backward compatibility as 8.4.x or earlier releases. > > I updated the description as yo

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote: > For example, if you're trying to do classroom scheduling, it might be > useful to constrain the periods to start and end on hour boundaries > --- but the next thing you'll want is to have it know that the "next" > slot after 5pm Friday is 8am Mon

Re: [HACKERS] Largeobject Access Controls and pg_migrator

Takahiro Itagaki wrote: > > KaiGai Kohei wrote: > > > Can SELECT lo_create(16385); help this situation? > > SELECT lo_create(loid) FROM (SELECT DISTINCT loid FROM pg_largeobject) AS t > > would work for pg_migrator. > > > I'm not clear whether we also check pg_largeobejct has chunks with same

[HACKERS] determine snapshot after obtaining locks for first statement

The Cahill thesis mentions an interesting optimization -- they defer determination of the snapshot until after any locks required for the first statement have been acquired. Where the first statement was, for example, an UPDATE, this reduced re-reads or rollbacks in the face of concurrent modifica

Re: [HACKERS] Range types

Tom Lane wrote: Martijn van Oosterhout writes: However, it does seem reasonable to allow people to restrict, either by typmod or a check constraint the kinds of values that can be stored in a particular column. Then an application can decide which way they want their intervals to work and have

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 15:57 -0500, Tom Lane wrote: > Making it explicit doesn't fix the fact that you can't rely on the > arithmetic to be exact. Can't rely on what arithmetic to be exact? Int64 timestamps should clearly work for granules of 1 second. If the administrator can choose a timestamp f

Re: [HACKERS] Range types

Martijn van Oosterhout writes: > However, it does seem reasonable to allow people to restrict, either by > typmod or a check constraint the kinds of values that can be stored in > a particular column. Then an application can decide which way they want > their intervals to work and have the databas

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 15:46 -0500, Tom Lane wrote: > > Huh? We're miscommunicating somewhere. > > Yeah, apparently. By open-ended I meant -infinity left bound, or null > left bound if you prefer. Not sure if there's a better term. But my proposal allowed both of those things with various flag s

Re: [HACKERS] Update on true serializable techniques in MVCC

Robert, Please forgive a couple editorial inserts to your statement -- I hope it clarifies. If I've distorted your meaning, feel free to straighten me out. :-) Robert Haas wrote: > This thread veered off into a discussion of the traditional > [predicate locking] technique, rather than the [

Re: [HACKERS] Range types

On Wed, Dec 16, 2009 at 03:57:44PM -0500, Tom Lane wrote: > Jeff Davis writes: > > I still have not seen an answer to the problem of changing the > > representation of a continuous range. If you have the continuous range > > [5, 10], you're pretty much stuck with that representation, even if the >

Re: [HACKERS] Range types

Jeff Davis writes: > On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote: >> The argument for having >> granularity wired into the datatype seems to boil down to just space >> savings. I don't find that compelling enough to justify code >> contortions and user-visible restrictions on functionality.

Re: [HACKERS] Range types

Jeff Davis writes: > On Wed, 2009-12-16 at 12:50 -0500, Tom Lane wrote: >> I'm still not exactly clear on what the use-case is for discrete >> timestamp ranges, and I wonder how many people are going to be happy >> with a representation that can't handle a range that's open-ended >> on the left.

Re: [HACKERS] Range types

Martijn van Oosterhout writes: > But a period type will take just one or two more bytes if you don't > require alignment. Alignment on a varlena type seems silly anyway, > since you'll be aligning the header byte rather than the content. You might still end up paying the alignment overhead after

Re: [HACKERS] Range types

Tom Lane wrote: > Alvaro Herrera writes: > > In short, I think that while it is possible to define ranges of strings, > > it is not as useful as one would like. > > Note it is not the *range* that is the problem, it is the assumption > that there's a unique "next" string. There's no unique next

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 13:59 -0500, Tom Lane wrote: > The argument for having > granularity wired into the datatype seems to boil down to just space > savings. I don't find that compelling enough to justify code > contortions and user-visible restrictions on functionality. The argument (at least f

Re: [HACKERS] Does "verbose" Need to be Reserved?

"David E. Wheeler" writes: > I asked on IRC, and Andrew “RhodiumToad” Gierth pointed out that > it became a reserved word at some point. "Some point" would have been around the time VACUUM VERBOSE got invented, ie January 1997 according to the CVS logs. We can't unreserve it until you're ready t

Re: [HACKERS] Update on true serializable techniques in MVCC

On Wed, Dec 16, 2009 at 1:30 PM, Kevin Grittner wrote: > Alvaro Herrera wrote: > >> So you'd have to disable HOT updates when true serializability was >> active? > > I wouldn't think so; but someone familiar with HOT logic could > probably determine whether the unmodified algorithm could be used

Re: [HACKERS] Range types

Alvaro Herrera writes: > In short, I think that while it is possible to define ranges of strings, > it is not as useful as one would like. Note it is not the *range* that is the problem, it is the assumption that there's a unique "next" string. There's no unique next in the reals or rationals ei

Re: [HACKERS] Update on true serializable techniques in MVCC

On Wed, Dec 16, 2009 at 1:29 PM, Boszormenyi Zoltan wrote: > Robert Haas írta: >> On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote: >> >>> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera >>> wrote: >>> Robert Haas escribió: > On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund

Re: [HACKERS] Range types

On Wed, Dec 16, 2009 at 10:57:19AM -0800, Scott Bailey wrote: > Ok, silly question here. But how do you determine the length of a > continuous range? By definition length of [a, b) and (a, b] = b-a. But > what about (a,b) and [a,b]? Are we saying that because they are > continuous, the differ

Re: [HACKERS] Does "verbose" Need to be Reserved?

> "David" == "David E Wheeler" writes: David> Hey All, David> I was just getting a new version of pgTAP ready for release, and while testing it on HEAD, I got this error: David> + psql:pgtap.sql:5789: ERROR: syntax error at end of input David> + LINE 28: IF verbose THEN

Re: [HACKERS] Range types

On Tue, Dec 15, 2009 at 04:29:26PM -0800, Jeff Davis wrote: > On Tue, 2009-12-15 at 18:06 -0600, decibel wrote: > > Now that varlena's don't have an enormous fixed overhead, perhaps it's > > worth looking at using them. Obviously some operations would be > > slower, but for your stated examples of

[HACKERS] Does "verbose" Need to be Reserved?

Hey All, I was just getting a new version of pgTAP ready for release, and while testing it on HEAD, I got this error: + psql:pgtap.sql:5789: ERROR: syntax error at end of input + LINE 28: IF verbose THEN RETURN NEXT diag(tests[i] ||... +^ I a

Re: [HACKERS] Range types

to...@tuxteam.de wrote: > (and as Andrew Dunstan pointed out off-list: I was wrong with my bold > assertion that one can squeeze infinitely many (arbitrary length) > strings between two given. This is not always the case). Of course you can do that if you assume lexicographical order, or any othe

Re: [HACKERS] PATCH: Spurious "22" in hstore.sgml

On Wed, Dec 16, 2009 at 20:34, David E. Wheeler wrote: > *** a/doc/src/sgml/hstore.sgml > --- b/doc/src/sgml/hstore.sgml Heh, interesting. That clearly shouldn't be there. Applied. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hacke

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On ons, 2009-12-16 at 10:49 -0500, Tom Lane wrote: > Marko Kreen writes: > > So the plain-C89 compilers would be downgraded to "second-class" > > targets, not worth getting max performance out of them. > > Hm? Failing to inline is already a performance hit, which is why > Kurt got interested in

[HACKERS] PATCH: Spurious "22" in hstore.sgml

*** a/doc/src/sgml/hstore.sgml --- b/doc/src/sgml/hstore.sgml *** *** 278,284 get hstore's keys as a set skeys('a=>1,b=>2') ! 22 a b --- 278,284 get hstore's keys as a set skeys('a=>1,b=>2') ! a b -- Sent via

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 12:50 -0500, Tom Lane wrote: > I'm still not exactly clear on what the use-case is for discrete > timestamp ranges, and I wonder how many people are going to be happy > with a representation that can't handle a range that's open-ended > on the left. Huh? We're miscommunicatin

[HACKERS] pinging Dano

Hi, who is the main editor named "Dano" of the wiki page about Parallel Query Execution (http://wiki.postgresql.org/wiki/Parallel_Query_Execution), please speak up. Is there any code or patch available ATM? What "discussion with Tom and Simon" is that page referring to? Regards Markus Wan

[HACKERS] PATCH: Add hstore_to_json()

I just realized that this was easy to do, and despite my complete lack of C skillz was able to throw this together in a couple of hours. It might be handy to some, though the possible downsides are: * No json_to_hstore(). * Leads to requests for hstore_to_yaml(), hstore_to_xml(), etc. * Andrew G

Re: [HACKERS] Range types

On Wed, 2009-12-16 at 12:42 -0500, Robert Haas wrote: > On Wed, Dec 16, 2009 at 12:31 PM, Jeff Davis wrote: > > There's one problem, and that's for timestamptz ranges with intervals > > that include days and months. Timezone adjustments are just not > > well-defined for that kind of granule (nor w

Re: [HACKERS] XLogInsert

On Wednesday 16 December 2009 20:07:07 Gurjeet Singh wrote: > 2009/12/15 Greg Smith > > > Jaime Casanova wrote: > >> So in this extreme case avg tps is just 6 transactions better > > > > Great job trying to find the spot where the code worked better. I'm not > > so sure I trust pgbench results w

Re: [HACKERS] XLogInsert

2009/12/15 Greg Smith > Jaime Casanova wrote: > >> So in this extreme case avg tps is just 6 transactions better >> >> > Great job trying to find the spot where the code worked better. I'm not so > sure I trust pgbench results where the TPS was so low though. Which leads > us right back to exac

Re: [HACKERS] Range types

Scott Bailey writes: > As I pointed out off-list, I think the granularity for timestamp range > should be limited to hours and smaller. Anything larger is asking for > trouble. And quite honestly if they wanted day granularity, they should > use date range. I'm still not real clear on what the

Re: [HACKERS] Range types

Ok, silly question here. But how do you determine the length of a continuous range? By definition length of [a, b) and (a, b] = b-a. But what about (a,b) and [a,b]? Are we saying that because they are continuous, the difference between values included in the range and those excluded are so infi

Re: [HACKERS] Update on true serializable techniques in MVCC

Alvaro Herrera wrote: > So you'd have to disable HOT updates when true serializability was > active? I wouldn't think so; but someone familiar with HOT logic could probably determine whether the unmodified algorithm could be used by reviewing the "simplifying assumptions" near the bottom of pa

Re: [HACKERS] Update on true serializable techniques in MVCC

Robert Haas írta: > On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote: > >> On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera >> wrote: >> >>> Robert Haas escribió: >>> On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote: > On Wednesday 16 December 2009 16:

Re: [HACKERS] Update on true serializable techniques in MVCC

On Wed, Dec 16, 2009 at 1:25 PM, Robert Haas wrote: > On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera > wrote: >> Robert Haas escribió: >>> On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote: >>> > On Wednesday 16 December 2009 16:24:42 Robert Haas wrote: >>> >> >   Inserts and deletes follow

Re: [HACKERS] Update on true serializable techniques in MVCC

On Wed, Dec 16, 2009 at 1:14 PM, Alvaro Herrera wrote: > Robert Haas escribió: >> On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote: >> > On Wednesday 16 December 2009 16:24:42 Robert Haas wrote: >> >> >   Inserts and deletes follow the same protocol, obtaining an exclusive >> >> >   lock on

Re: [HACKERS] Range types

Tom Lane wrote: Jeff Davis writes: [ hacky special-case representation for discrete timestamp ranges ] I'm still not exactly clear on what the use-case is for discrete timestamp ranges, and I wonder how many people are going to be happy with a representation that can't handle a range that's o

Re: [HACKERS] Update on true serializable techniques in MVCC

Robert Haas escribió: > On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote: > > On Wednesday 16 December 2009 16:24:42 Robert Haas wrote: > >> >   Inserts and deletes follow the same protocol, obtaining an exclusive > >> >   lock on the row after the one being inserted or deleted. The result >

Re: [HACKERS] Range types

Jeff Davis wrote: On Sun, 2009-12-13 at 23:49 -0800, Scott Bailey wrote: So basically I have an anyrange pseudo type with the functions prev, next, last, etc defined. So instead of hard coding range types, we would allow the user to define their own range types. Basically if we are able to det

Re: [HACKERS] Range types

Jeff Davis writes: > [ hacky special-case representation for discrete timestamp ranges ] I'm still not exactly clear on what the use-case is for discrete timestamp ranges, and I wonder how many people are going to be happy with a representation that can't handle a range that's open-ended on the l

Re: [HACKERS] Range types

On Wed, Dec 16, 2009 at 12:31 PM, Jeff Davis wrote: > There's one problem, and that's for timestamptz ranges with intervals > that include days and months. Timezone adjustments are just not > well-defined for that kind of granule (nor would it be particularly > useful even if it magically worked),

Re: [HACKERS] Range types

On Sun, 2009-12-13 at 23:49 -0800, Scott Bailey wrote: > So basically I have an anyrange pseudo type with the functions prev, > next, last, etc defined. So instead of hard coding range types, we would > allow the user to define their own range types. Basically if we are able > to determine the p

Re: [HACKERS] PostgreSQL project policy compendium

Kurt Harriman wrote: On 12/16/2009 7:10 AM, Tom Lane wrote: the project policy is to not require any compiler features not found > in C89. Is there somewhere a compendium of such policies which fledgling hackers should consult to avoid embarrassment? The list of suggestions at http://wiki.po

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Alvaro Herrera writes: > Tom Lane escribió: >> I think you're way overthinking this. Where we started was just >> a proposal to try to expand the set of inline-ing compilers beyond >> "gcc only". I don't see why we need to do anything but that. The >> code is fine as-is except for the control #

Re: [HACKERS] [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash

Peter Eisentraut writes: > Here is a set of patches to address this issue. > The first one is a small refactoring of the signal setting portability > business. OK > The second one fixes the SIGQUIT handler inadvertently unblocking > SIGQUIT within itself. OK > The third one installs an alarm s

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On 12/16/09, Tom Lane wrote: > Marko Kreen writes: > > > So the plain-C89 compilers would be downgraded to "second-class" > > targets, not worth getting max performance out of them. > > > Hm? Failing to inline is already a performance hit, which is why > Kurt got interested in this in the fir

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Marko Kreen writes: > On 12/15/09, Kurt Harriman wrote: >> Attached is a revised patch, offered for the 2010-01 commitfest. >> It's also available in my git repository in the "submitted" branch: >> >> http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/heads/submitted

Re: [HACKERS] idea - new aggregates median, listagg

Thom Brown wrote: 2009/12/15 Pavel Stehule > Hello I am looking on new feature - ORDER clause in aggregate, and I thing, so we are able to effectively implement some non standard, but well known aggregates. a) function median - it is relative

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Tom Lane escribió: > I think you're way overthinking this. Where we started was just > a proposal to try to expand the set of inline-ing compilers beyond > "gcc only". I don't see why we need to do anything but that. The > code is fine as-is except for the control #ifdefs. IIRC Kurt was also o

Re: [HACKERS] PostgreSQL project policy compendium

Robert Haas writes: > On Wed, Dec 16, 2009 at 10:44 AM, Kurt Harriman wrote: >> Is there somewhere a compendium of such policies which >> fledgling hackers should consult to avoid embarrassment? > I do think your basic point is well-taken, though. There are a lot of > details about how we do th

Re: [HACKERS] [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash

Peter Eisentraut escribió: > Here is a set of patches to address this issue. > > The first one is a small refactoring of the signal setting portability > business. This one looks like should be applied immediately to get some buildfarm coverage (and alpha3) -- Alvaro Herrera

Re: [HACKERS] PostgreSQL project policy compendium

On Wed, Dec 16, 2009 at 10:44 AM, Kurt Harriman wrote: > On 12/16/2009 7:10 AM, Tom Lane wrote: >> >> the project policy is to not require any compiler features not found > >> in C89. > > Is there somewhere a compendium of such policies which > fledgling hackers should consult to avoid embarrassme

Re: [HACKERS] PostgreSQL project policy compendium

On ons, 2009-12-16 at 07:44 -0800, Kurt Harriman wrote: > On 12/16/2009 7:10 AM, Tom Lane wrote: > > the project policy is to not require any compiler features not found > > in C89. > > Is there somewhere a compendium of such policies which > fledgling hackers should consult to avoid embarrassme

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Marko Kreen writes: > So the plain-C89 compilers would be downgraded to "second-class" > targets, not worth getting max performance out of them. Hm? Failing to inline is already a performance hit, which is why Kurt got interested in this in the first place. I think you're way overthinking this.

Re: [HACKERS] [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash

Here is a set of patches to address this issue. The first one is a small refactoring of the signal setting portability business. The second one fixes the SIGQUIT handler inadvertently unblocking SIGQUIT within itself. The third one installs an alarm so that if the ereport() call in quickdie() do

[HACKERS] PostgreSQL project policy compendium

On 12/16/2009 7:10 AM, Tom Lane wrote: the project policy is to not require any compiler features not found > in C89. Is there somewhere a compendium of such policies which fledgling hackers should consult to avoid embarrassment? Regards, ... kurt -- Sent via pgsql-hackers mailing list (pgsq

Re: [HACKERS] Fast or immediate shutdown

On Wed, 2009-12-16 at 17:04 +0200, Peter Eisentraut wrote: > On tis, 2009-12-15 at 17:19 +, Simon Riggs wrote: > > running with log_checkpoints = on > > > > pg_ctl -D foo -m fast stop > > > > log says > > > > LOG: received fast shutdown request > > LOG: aborting any active transactions > >

Re: [HACKERS] idea - new aggregates median, listagg

2009/12/16 Thom Brown : > 2009/12/15 Pavel Stehule >> >> Hello >> >> I am looking on new feature - ORDER clause in aggregate, and I thing, >> so we are able to effectively implement some non standard, but well >> known aggregates. >> >> a) function median - it is relative frequent request - with u

Re: [HACKERS] Update on true serializable techniques in MVCC

Nicolas Barbier wrote: > I am not sure whether the serialization failures that it may cause > are dependent on the plan used. They are. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsq

Re: [HACKERS] Update on true serializable techniques in MVCC

"Albe Laurenz" wrote: > Although it may have seemed that I was out to shoot the idea down, > I am interested in the topic. I guess my way of understanding > something is trying to find holes in it... No problem. That's how ideas are explored and improved. The brick wall was that there seemed

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On 12/16/09, Tom Lane wrote: > Marko Kreen writes: > > Hypothetical old, crappy compilers would still work, only AC_C_INLINE > > would turn "static inline" into plain "static", so hypothetically > > they would get some warnings about unused functions. > > > As this is all hypothetical, I don'

Re: [HACKERS] Update on true serializable techniques in MVCC

On Wed, Dec 16, 2009 at 10:29 AM, Andres Freund wrote: > On Wednesday 16 December 2009 16:24:42 Robert Haas wrote: >> >   Inserts and deletes follow the same protocol, obtaining an exclusive >> >   lock on the row after the one being inserted or deleted. The result >> >   of this locking protocol

Re: [HACKERS] Update on true serializable techniques in MVCC

Moin, On Wednesday 16 December 2009 16:24:42 Robert Haas wrote: > > Inserts and deletes follow the same protocol, obtaining an exclusive > > lock on the row after the one being inserted or deleted. The result > > of this locking protocol is that a range scan prevents concurrent > > inserts

Re: [HACKERS] idea - new aggregates median, listagg

2009/12/15 Pavel Stehule > Hello > > I am looking on new feature - ORDER clause in aggregate, and I thing, > so we are able to effectively implement some non standard, but well > known aggregates. > > a) function median - it is relative frequent request - with usually > slow implementation > > b)

Re: [HACKERS] Update on true serializable techniques in MVCC

On Wed, Dec 16, 2009 at 4:52 AM, Albe Laurenz wrote: > Kevin Grittner wrote: >> Just to make those who care aware of it, here is Michael Cahill's >> Doctoral Thesis based on implementing Serializable Snapshot >> Isolation in InnoDB using a refined version of the techniques >> previously used in th

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On 12/16/09, Tom Lane wrote: > Marko Kreen writes: > > On 12/16/09, Kurt Harriman wrote: > > >> For gcc, I think the __attribute__ has to come after the function's > >> parameter list, rather than before the return type. > > > No. > > > [ squint... ] That's nowhere documented that I can find

Re: [HACKERS] idea - new aggregates median, listagg

Pavel Stehule wrote: > 2009/12/15 David Fetter : >> http://www.simple-talk.com/sql/t-sql-programming/median-workbench/ > > In this article the are two medians - statistical and financial. I > am for both. But only one can be named "median". Well, since the statistical median requires that you

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Marko Kreen writes: > Hypothetical old, crappy compilers would still work, only AC_C_INLINE > would turn "static inline" into plain "static", so hypothetically > they would get some warnings about unused functions. > As this is all hypothetical, I don't see why that should stop us > cleaning our

Re: [HACKERS] Fast or immediate shutdown

On tis, 2009-12-15 at 17:19 +, Simon Riggs wrote: > running with log_checkpoints = on > > pg_ctl -D foo -m fast stop > > log says > > LOG: received fast shutdown request > LOG: aborting any active transactions > LOG: shutting down > LOG: restartpoint starting: shutdown immediate > > Som

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On Wed, Dec 16, 2009 at 9:30 AM, Marko Kreen wrote: > On 12/16/09, Robert Haas wrote: >> On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote: >>  >> Your worry ii) can be ignored, managing to compile on such >>  >> compilers is already overachievement. >>  > >>  > I think so too.  With your op

Re: [HACKERS] Range types

Dimitri Fontaine writes: > Tom Lane writes: >> foreach p2_member in unnest(p2) loop >> p1 := array(select period_except(p1_member, p2_member) >> from unnest(p1) p1_member); >> end loop; >> >> But maybe it can be done in a single SQL command. > Yea

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

Marko Kreen writes: > On 12/16/09, Kurt Harriman wrote: >> For gcc, I think the __attribute__ has to come after the function's >> parameter list, rather than before the return type. > No. [ squint... ] That's nowhere documented that I can find: all the examples in the gcc docs show __attribute

Re: [HACKERS] idea - new aggregates median, listagg

On Wed, Dec 16, 2009 at 1:36 AM, Pavel Stehule wrote: >>> b) function listagg (it is analogy of group_concat from MySQL) - it >>> should simplify report generating and some other >> >> This is redundant, as it's equivalent to array_to_string(array_agg()). > > when I implement it in orafce - the al

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On 12/16/09, Robert Haas wrote: > On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote: > >> Your worry ii) can be ignored, managing to compile on such > >> compilers is already overachievement. > > > > I think so too. With your opinion added to mine, do we constitute a > > consensus of th

Re: [HACKERS] Patch: Remove gcc dependency in definition of inline functions

On 12/16/09, Kurt Harriman wrote: > [Please ignore the previous incomplete version of this reply, which I > sent by mistake. Sorry for the list noise.] > > On 12/15/2009 2:09 PM, Marko Kreen wrote: > > > > Oh. Ok then. Force-inline seems better fix as we may want to use > > it for other re

Re: [HACKERS] An example of bugs for Hot Standby

On Wed, 2009-12-16 at 10:33 +, Simon Riggs wrote: > On Tue, 2009-12-15 at 20:25 +0900, Hiroyuki Yamada wrote: > > Hot Standby node can freeze when startup process calls > > LockBufferForCleanup(). > > This bug can be reproduced by the following procedure. > > Interesting. Looks like this can

Re: [HACKERS] Range types

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 15, 2009 at 11:49:19AM -0800, David Fetter wrote: > On Tue, Dec 15, 2009 at 11:31:05AM -0800, Scott Bailey wrote: > > Jeff Davis wrote: > > >On Tue, 2009-12-15 at 10:19 -0500, Tom Lane wrote: > > > > Would it be OK if we handled float time

  1   2   >