Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

2013-01-12 06:51 keltezéssel, Amit kapila írta: On Friday, January 11, 2013 10:03 PM Boszormenyi Zoltan wrote: Hi, 2013-01-09 10:08 keltezéssel, Amit kapila írta: On Sunday, January 06, 2013 10:26 AM Boszormenyi Zoltan wrote: On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote: 201

[HACKERS] Validation in to_date()

to_date() doesn't check the date range, which results in unreadable data like this. foo=# create table t as select to_date('-12-10 BC', '-MM-DD BC')::timestamp; SELECT 1 foo=# table t; ERROR: timestamp out of range Attached is to add IS_VALID_JULIAN() as we do like in date_in(). I think

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

On Friday, January 11, 2013 10:03 PM Boszormenyi Zoltan wrote: > Hi, 2013-01-09 10:08 keltezéssel, Amit kapila írta: > On Sunday, January 06, 2013 10:26 AM Boszormenyi Zoltan wrote: > On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote: > 2013-01-05 05:58 keltezéssel, Amit kapila írta

[HACKERS] Wide area replication postgres 9.1.6 slon 2.1.2 large table failure.

So I started this thread on the slon forum, and they mentioned that I/we should ask here. Postgres 9.1.4 slon 2.1.1 -and- Postgres 9.1.6 slon 2.1.2 Scenario: Node 1, is on gig circut and is the master (West Coast) Node 2, is also on a gig circuit and is the slave (Georgia) Symptoms, slon imme

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Saturday, January 12, 2013 12:23 AM Simon Riggs wrote: On 11 January 2013 18:11, Amit kapila wrote: >>> Can we identify which columns have changed? i.e. 1st, 3rd and 12th columns? >> As per current algorithm, we can't as it is based on offsets. >> What I mean to say is that the basic idea

Re: [HACKERS] AIX buildfarm member

> I'm really surprised IBM doesn't have some program to support a worthy > project like this. They probably do. The problem is that we don't know who to contact. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] AIX buildfarm member

On 1/11/2013 6:56 AM, Steve Singer wrote: If someone else in the community is running PostgreSQL on AIX then it would be good if they setup a buildfarm member, perhaps with a more recent version of AIX. I am and I'd love to, however, sigh, its deep behind corporate firewalls and any attempt

Re: [HACKERS] Porting to Haiku

"Mark Hellegers" writes: >> You might want to look into whether you can get the buildfarm script >> to run before you go too far. > I will check that this weekend. Thanks. > Does this buildfarm member need to run continuously? Once a day is sufficient if that's all you can manage, though several

Re: [HACKERS] Porting to Haiku

> "Mark Hellegers" writes: > > - Assuming all patches are applied to get Postgresql running, what > > does > > it require to keep it in there? I noticed you removed the BeOS > > port, > > because no one was maintaining it. What does it take to maintain a > > port? > > These days, the expecta

Re: [HACKERS] Database object names and libpq in UTF-8 locale on Windows

On 11/21/2012 12:07 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/21/2012 11:11 AM, Tom Lane wrote: I'm not sure that's the only place we're doing this ... Oh, Hmm, darn. Where else do you think we might? Dunno, but grepping for isupper and/or tolower should find any such places.

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > On 2013-01-11 16:28:13 -0500, Tom Lane wrote: >> I'm not very satisfied with that answer. Right now, Peter's >> patch has added a class of bugs that never existed before 9.3, and yours >> would add more. It might well be that those classes are empty ... but >> *we can't k

[HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-11 16:28:13 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2013-01-11 16:16:58 -0500, Tom Lane wrote: > >> Uh ... because it's *not* unreachable if elevel < ERROR. Otherwise we'd > >> just mark errfinish as __attribute((noreturn)) and be done. Of course, > >> that's a gcc-ism t

Re: [HACKERS] Porting to Haiku

"Mark Hellegers" writes: > - Assuming all patches are applied to get Postgresql running, what does > it require to keep it in there? I noticed you removed the BeOS port, > because no one was maintaining it. What does it take to maintain a > port? These days, the expectation is that somebody ru

Re: [HACKERS] Porting to Haiku

On 01/11/2013 04:36 PM, Mark Hellegers wrote: Hello, I have read the developers FAQ which directed me to this mailing list. I am still using Postgresql on Zeta (descendant of BeOS), but it is becoming time to upgrade, so I installed Haiku (open source reimplementation of BeOS) on another machin

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > On 2013-01-11 16:16:58 -0500, Tom Lane wrote: >> Uh ... because it's *not* unreachable if elevel < ERROR. Otherwise we'd >> just mark errfinish as __attribute((noreturn)) and be done. Of course, >> that's a gcc-ism too. > Well, I mean with the double evaluation risk. Oh

[HACKERS] Porting to Haiku

Hello, I have read the developers FAQ which directed me to this mailing list. I am still using Postgresql on Zeta (descendant of BeOS), but it is becoming time to upgrade, so I installed Haiku (open source reimplementation of BeOS) on another machine and downloaded the 9.2.1 source of Postgresq

[HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-11 16:16:58 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2013-01-11 15:52:19 -0500, Tom Lane wrote: > >> I agree the scenario doesn't seem all that probable, but what scares me > >> here is that if we use "__builtin_constant_p(elevel) && (elevel) >= ERROR" > >> in some builds,

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > On 2013-01-11 15:52:19 -0500, Tom Lane wrote: >> I agree the scenario doesn't seem all that probable, but what scares me >> here is that if we use "__builtin_constant_p(elevel) && (elevel) >= ERROR" >> in some builds, and just "(elevel) >= ERROR" in others, then if there is

Re: [HACKERS] LLVM / CLang / PostgreSQL

On 1/11/13 4:03 PM, Joshua D. Drake wrote: > Has anyone played with this? Seen any results? It looks like most > testing is being done on Mac OSX (via buildfarm). Works fine. We also have non-OSX tests on the buildfarm for it. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

[HACKERS] LLVM / CLang / PostgreSQL

Hello, Has anyone played with this? Seen any results? It looks like most testing is being done on Mac OSX (via buildfarm). JD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postg

[HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-11 15:52:19 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2013-01-11 15:05:54 -0500, Tom Lane wrote: > >> And another thing: what if the elevel argument isn't safe for multiple > >> evaluation? No such hazard ever existed before these patches, so I'm > >> not very comfortable w

Re: [HACKERS] [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > On 2013-01-11 15:05:54 -0500, Tom Lane wrote: >> And another thing: what if the elevel argument isn't safe for multiple >> evaluation? No such hazard ever existed before these patches, so I'm >> not very comfortable with adding one. (Even if all our own code is >> safe, t

Re: [HACKERS] ToDo: log plans of cancelled queries

On 11 January 2013 16:52, Simon Riggs wrote: > We already overload the signals, so its just a new type for the signal > handler to cope with. > > See procsignal_sigusr1_handler() I roughed up something to help you here... this is like 50% of a patch. pg_explain_backend() calls a SIGUSR1 variant

[HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-11 15:05:54 -0500, Tom Lane wrote: > Andres Freund writes: > > [ patch to mark elog() as non-returning if elevel >= ERROR ] > > It strikes me that both in this patch, and in Peter's previous patch to > do this for ereport(), there is an opportunity for improvement. Namely, > that the a

Re: [HACKERS] PL/perl should fail on configure, not make

On Fri, 11 Jan 2013, Tom Lane wrote: > pgbuildf...@jdrake.com writes: > Well, that's darn interesting in itself, because the error message looks > like it should be purely a linker issue. (And I note that your other > buildfarm animal mongoose uses icc but is working anyway, so that's > definitel

Re: [HACKERS] PL/perl should fail on configure, not make

On Thu, 10 Jan 2013, Andrew Dunstan wrote: > > On 01/10/2013 11:32 AM, Tom Lane wrote: > > Andrew Dunstan writes: > > > cc -o interp interp.c `perl -MExtUtils::Embed -e ccopts -e ldopts` > > Hm. It would be interesting to see what ccopts expands to, but if you > > compare the command confi

[HACKERS] GIN over array of ENUMs

I wish to create this data structure but GIN does not currently support an array of ENUM. Is intarray() a good place to look into adding ENUM support or is there already an operator class for working supports enums that I simply don't see at the moment. This is being done as an alternative to a ve

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > [ patch to mark elog() as non-returning if elevel >= ERROR ] It strikes me that both in this patch, and in Peter's previous patch to do this for ereport(), there is an opportunity for improvement. Namely, that the added code only has any use if elevel is a constant, which

Re: [HACKERS] [Pgbuildfarm-members] Version 4.10 of buildfarm client released.

On 01/11/2013 01:39 PM, Tom Lane wrote: Heikki Linnakangas writes: There was a stray postgres instance running on the box, which I killed: FWIW, we've seen an awful lot of persistent buildfarm failures that seemed to be due to port conflicts with leftover postmasters. I think the buildfarm s

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-11 14:01:40 -0500, Tom Lane wrote: > Andres Freund writes: > > The attached patch: > > > * adds configure checks for __VA_ARGS__ and __builtin_unreachable > > support > > * provides a pg_unreachable() macro that expands to > > __builtin_unreachable() or abort() > > * changes #define

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

Andres Freund writes: > The attached patch: > * adds configure checks for __VA_ARGS__ and __builtin_unreachable > support > * provides a pg_unreachable() macro that expands to > __builtin_unreachable() or abort() > * changes #define elog ... into #define elog(elevel, ...) if varargs are > a

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 11 January 2013 18:11, Amit kapila wrote: >> Can we identify which columns have changed? i.e. 1st, 3rd and 12th columns? > As per current algorithm, we can't as it is based on offsets. > What I mean to say is that the basic idea to reconstruct tuple during > recovery > is copy data from

Re: [HACKERS] [Pgbuildfarm-members] Version 4.10 of buildfarm client released.

Heikki Linnakangas writes: > There was a stray postgres instance running on the box, which I killed: FWIW, we've seen an awful lot of persistent buildfarm failures that seemed to be due to port conflicts with leftover postmasters. I think the buildfarm script needs to try harder to ensure that i

Re: [HACKERS] I s this a bug of spgist index in a heavy write condition?

=?gb2312?B?wO66o8H6?= writes: > This time I will give you the contents of the table route_raw, the download > link is https://www.box.com/s/yxa4yxo6rcb3dzeaefmz or > http://dl.dropbox.com/u/203288/route_raw_spgist.sql.tar.gz . Thanks for the data, but I still can't reproduce the problem :-(.

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Friday, January 11, 2013 11:12 PM Simon Riggs wrote: On 11 January 2013 17:30, Amit kapila wrote: > On Friday, January 11, 2013 7:59 PM Alvaro Herrera wrote: > Simon Riggs wrote: >> On 28 December 2012 10:21, Simon Riggs wrote: >> > >>> I was also worried about the high variance in the result

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Friday, January 11, 2013 11:09 PM Simon Riggs wrote: On 11 January 2013 17:08, Amit kapila wrote: >>> Just reviewing the patch now, making more sense with comments added. > >>>In heap_delta_encode() do we store which columns have changed? > >> Not the attribute bumberwise, but offsetwise it i

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 11 January 2013 17:30, Amit kapila wrote: > On Friday, January 11, 2013 7:59 PM Alvaro Herrera wrote: > Simon Riggs wrote: >> On 28 December 2012 10:21, Simon Riggs wrote: >> > >> I was also worried about the high variance in the results. Those >> averages look rather meaningless. Which woul

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 11 January 2013 17:08, Amit kapila wrote: >> Just reviewing the patch now, making more sense with comments added. > >>In heap_delta_encode() do we store which columns have changed? > > Not the attribute bumberwise, but offsetwise it is stored. (Does that mean "numberwise"??) Can we identify

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Friday, January 11, 2013 7:59 PM Alvaro Herrera wrote: Simon Riggs wrote: > On 28 December 2012 10:21, Simon Riggs wrote: > > I was also worried about the high variance in the results. Those > averages look rather meaningless. Which would be okay, I think, because > it'd mean that performanc

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Friday, January 11, 2013 9:27 PM Simon Riggs wrote: On 11 January 2013 14:24, Amit Kapila wrote: >> http://archives.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C3828 >> 52DE51@szxeml509-mbs > >> 1. However Heikki has pointed, it has some problems similar to for HOT >> implementatio

Re: [HACKERS] [Pgbuildfarm-members] Version 4.10 of buildfarm client released.

On 11.01.2013 18:38, Andrew Dunstan wrote: The main feature of this release is that it does better logging of pg_upgrade failures (which is why I hope Heikki applies it to chipmunk right away ;-) ) Heh, ok :-) I've upgraded it, and launched a new buildfarm run, so we'll now more in a moment.

Re: [HACKERS] ToDo: log plans of cancelled queries

On 11 January 2013 16:31, Pavel Stehule wrote: > 2013/1/11 Stephen Frost : >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> Simon Riggs writes: >>> > An even better feature would be to be able to send a signal to a >>> > running query to log its currently executing plan. That way you can >>> > ask "

Re: [HACKERS] ToDo: log plans of cancelled queries

* Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2013/1/11 Stephen Frost : > > We can send a 'cancel query', how about a 'report on query' which > > returns the plan and perhaps whatever other stats are easily available? > > there is only one question - that POSIX signal we can use? This would

[HACKERS] Version 4.10 of buildfarm client released.

Version 4.10 of the buildfarm client has been released. Following GitHub's abandonment of their download feature, releases will now be published on the buildfarm server. The latest release will always be available at This particular rele

Re: [HACKERS] psql \l to accept patterns

* Robert Haas (robertmh...@gmail.com) wrote: > On Tue, Jan 8, 2013 at 11:36 PM, Peter Eisentraut wrote: > > Good point. What about the other suggestion about only displaying > > databases by default that you can connect to? > > I would tend not to adopt that suggestion, on the grounds that it ha

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/11 Pavel Stehule : > 2013/1/11 Stephen Frost : >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> Simon Riggs writes: >>> > An even better feature would be to be able to send a signal to a >>> > running query to log its currently executing plan. That way you can >>> > ask "Why so slow?" before d

Re: [HACKERS] Proposal for Allow postgresql.conf values to be changed via SQL [review]

Hi, 2013-01-09 10:08 keltezéssel, Amit kapila írta: On Sunday, January 06, 2013 10:26 AM Boszormenyi Zoltan wrote: On Saturday, January 05, 2013 12:35 PM Boszormenyi Zoltan wrote: 2013-01-05 05:58 keltezéssel, Amit kapila írta: On Friday, January 04, 2013 10:57 PM Boszormenyi Zoltan wrote: Hi,

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/11 Stephen Frost : > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Simon Riggs writes: >> > An even better feature would be to be able to send a signal to a >> > running query to log its currently executing plan. That way you can >> > ask "Why so slow?" before deciding to kill it. >> >> That co

Re: [HACKERS] foreign key locks

On 2013-01-11 13:10:49 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > > No, I was thinking about an update without triggers present. > > > > T0: CREATE TABLE tbl(id serial pk, name text unique, data text); > > T1: BEGIN; -- read committed > > T1: UPDATE tbl SET name = 'foo' WHERE name = 'b

Re: [HACKERS] psql \l to accept patterns

On Tue, Jan 8, 2013 at 11:36 PM, Peter Eisentraut wrote: > On Mon, 2013-01-07 at 17:37 -0500, Robert Haas wrote: >> If we make the postgres database undroppable, unrenamable, and >> strictly read-only, I will happily support a proposal to consider it a >> system object. Until then, it's no more a

Re: [HACKERS] ToDo: log plans of cancelled queries

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Simon Riggs writes: > > An even better feature would be to be able to send a signal to a > > running query to log its currently executing plan. That way you can > > ask "Why so slow?" before deciding to kill it. > > That could conceivably work. At least i

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/11 Stephen Frost : > * Pavel Stehule (pavel.steh...@gmail.com) wrote: >> 2013/1/11 Stephen Frost : >> > Why not an option to auto_explain (or whatever) to log an execution plan >> > right before actually executing it? If that was something which could >> > be set with a GUC or similar, you

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/11 Stephen Frost : > * Pavel Stehule (pavel.steh...@gmail.com) wrote: >> 2013/1/11 Stephen Frost : >> > Why not an option to auto_explain (or whatever) to log an execution plan >> > right before actually executing it? If that was something which could >> > be set with a GUC or similar, you

Re: [HACKERS] ToDo: log plans of cancelled queries

Simon Riggs writes: > An even better feature would be to be able to send a signal to a > running query to log its currently executing plan. That way you can > ask "Why so slow?" before deciding to kill it. That could conceivably work. At least it wouldn't require running EXPLAIN in a failed tran

Re: [HACKERS] ToDo: log plans of cancelled queries

* Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2013/1/11 Stephen Frost : > > Why not an option to auto_explain (or whatever) to log an execution plan > > right before actually executing it? If that was something which could > > be set with a GUC or similar, you could just do that before runnin

Re: [HACKERS] ToDo: log plans of cancelled queries

Alvaro Herrera writes: > Tom Lane escribió: >> However, auto_explain is even worse on the other problem. You flat out >> cannot do catalog lookups in a failed transaction, but there's no way to >> print a decompiled plan without such lookups. So it won't work. (It >> would also be appropriate t

Re: [HACKERS] foreign key locks

Andres Freund wrote: > No, I was thinking about an update without triggers present. > > T0: CREATE TABLE tbl(id serial pk, name text unique, data text); > T1: BEGIN; -- read committed > T1: UPDATE tbl SET name = 'foo' WHERE name = 'blarg'; /* key update of row id > = 1 */ > T2: BEGIN; -- read co

Re: [HACKERS] ToDo: log plans of cancelled queries

On 11 January 2013 15:54, Alvaro Herrera wrote: > Tom Lane escribió: >> Pavel Stehule writes: >> > My propose is proposed for different dimensions and purpose - for >> > example - we have a limit 20 minutes for almost all queries, and after >> > this limit we killing queries. But we have to know

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/11 Tom Lane : > Pavel Stehule writes: >> My propose is proposed for different dimensions and purpose - for >> example - we have a limit 20 minutes for almost all queries, and after >> this limit we killing queries. But we have to know little bit more >> about these bad queries - and we hope

Re: [HACKERS] Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)

On 2013-01-10 10:55:20 +0100, Andres Freund wrote: > On 2013-01-10 10:31:04 +0100, Andres Freund wrote: > > On 2013-01-10 00:05:07 +0100, Andres Freund wrote: > > > On 2013-01-09 17:28:35 -0500, Tom Lane wrote: > > > > (We know this doesn't > > > > matter, but gcc doesn't; this version of gcc appar

Re: [HACKERS] json generation enhancements

On 01/11/2013 11:00 AM, Andrew Dunstan wrote: I have not had anyone follow up on this, so I have added docs and will add this to the commitfest. Recap: This adds the following: json_agg(anyrecord) -> json to_json(any) -> json hstore_to_json(hstore) -> json (also used as a cast)

[HACKERS] json generation enhancements

I have not had anyone follow up on this, so I have added docs and will add this to the commitfest. Recap: This adds the following: json_agg(anyrecord) -> json to_json(any) -> json hstore_to_json(hstore) -> json (also used as a cast) hstore_to_json_loose(hstore) -> json Also,

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 11 January 2013 14:24, Amit Kapila wrote: > http://archives.postgresql.org/message-id/6C0B27F7206C9E4CA54AE035729E9C3828 > 52DE51@szxeml509-mbs > > 1. However Heikki has pointed, it has some problems similar to for HOT > implementation and that is the reason we have done memcmp for HOT. > 2. A

Re: [HACKERS] ToDo: log plans of cancelled queries

Tom Lane escribió: > Pavel Stehule writes: > > My propose is proposed for different dimensions and purpose - for > > example - we have a limit 20 minutes for almost all queries, and after > > this limit we killing queries. But we have to know little bit more > > about these bad queries - and we ho

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/11 Stephen Frost : > * Pavel Stehule (pavel.steh...@gmail.com) wrote: >> My propose is proposed for different dimensions and purpose - for >> example - we have a limit 20 minutes for almost all queries, and after >> this limit we killing queries. But we have to know little bit more >> about

Re: [HACKERS] ToDo: log plans of cancelled queries

Pavel Stehule writes: > My propose is proposed for different dimensions and purpose - for > example - we have a limit 20 minutes for almost all queries, and after > this limit we killing queries. But we have to know little bit more > about these bad queries - and we hope, so execution plan can giv

Re: [HACKERS] ToDo: log plans of cancelled queries

* Pavel Stehule (pavel.steh...@gmail.com) wrote: > My propose is proposed for different dimensions and purpose - for > example - we have a limit 20 minutes for almost all queries, and after > this limit we killing queries. But we have to know little bit more > about these bad queries - and we hope,

Re: [HACKERS] ToDo: log plans of cancelled queries

2013/1/11 Tom Lane : > Pavel Stehule writes: >> What do you thinking about this feature? > > The idea of expecting an add-on module to execute operations in an > already-failed transaction seems pretty dubious to me. I also think > it's not a great idea to add partial executions into a query's st

Re: [HACKERS] Print b-tree tuples

Am 04.01.13 21:26, schrieb Tom Lane: Samuel Vogel writes: I'm trying to print out the tuples in the b-tree nodes for analysis, but when iterate over more than the first entry of the tuples (scanKey++), I strangely get the error below on query execution: ERROR: relation "simpletest" does not ex

Re: [HACKERS] ToDo: log plans of cancelled queries

Pavel Stehule writes: > What do you thinking about this feature? The idea of expecting an add-on module to execute operations in an already-failed transaction seems pretty dubious to me. I also think it's not a great idea to add partial executions into a query's stats. For instance, suppose quer

Re: [HACKERS] allowing privileges on untrusted languages

Peter Eisentraut writes: > It turned out that actually getting rid of lanpltrusted would be too > invasive, especially because some language handlers use it to determine > their own behavior. > So instead the lanpltrusted attribute now just determined what the > default privileges of the language

Re: [HACKERS] foreign key locks

On 2013-01-11 12:11:47 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote: > > > Here's version 28 of this patch. The only substantive change here from > > > v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive > > > or Lo

Re: [HACKERS] foreign key locks

Andres Freund wrote: > On 2013-01-10 18:00:40 -0300, Alvaro Herrera wrote: > > Here's version 28 of this patch. The only substantive change here from > > v26 is that I've made GetTupleForTrigger() use either LockTupleExclusive > > or LockTupleNoKeyExclusive, depending on whether the key columns ar

[HACKERS] AIX buildfarm member

The only animal in the buildfarm running AIX is grebe (http://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=grebe&br=HEAD) It is likely that the server running this animal will go away sometime this year and the machine replacing it isn't running AIX. If someone else in the community is

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 11 January 2013 14:29, Alvaro Herrera wrote: > But that doesn't include columns changed by triggers, AFAIR, so you > could only use that if there weren't any triggers. True, well spotted -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Tra

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

Simon Riggs wrote: > On 28 December 2012 10:21, Simon Riggs wrote: > > > * There is a fixed 75% heuristic in the patch. > > I'm concerned that we're doing extra work while holding the buffer > locked, which will exacerbate any block contention that exists. > > We have a list of the columns that

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Friday, January 11, 2013 6:45 PM Simon Riggs wrote: > On 28 December 2012 10:21, Simon Riggs wrote: > > > * There is a fixed 75% heuristic in the patch. > > I'm concerned that we're doing extra work while holding the buffer > locked, which will exacerbate any block contention that exists. >

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Friday, January 11, 2013 6:18 PM Simon Riggs wrote: > On 11 January 2013 12:30, Amit Kapila wrote: > > >> Is this just one run? Can we see 3 runs please? > > > > This average of 3 runs. > > The results are so variable its almost impossible to draw any > conclusions at all. I think if we did

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 28 December 2012 10:21, Simon Riggs wrote: > * There is a fixed 75% heuristic in the patch. I'm concerned that we're doing extra work while holding the buffer locked, which will exacerbate any block contention that exists. We have a list of the columns that the UPDATE is touching since we us

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 11 January 2013 12:30, Amit Kapila wrote: >> Is this just one run? Can we see 3 runs please? > > This average of 3 runs. The results are so variable its almost impossible to draw any conclusions at all. I think if we did harder stats on those we'd get nothing. Can you do something to bring

[HACKERS] ToDo: log plans of cancelled queries

Hello We use successfully use auto_explain. We miss support cancelled queries - we need same info for queries, that we cancel after x minutes. Subtask of this feature can be dumping currently executed query with plan and with complete query string to log after receiving some signal - maybe SIGTRA

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Friday, January 11, 2013 4:28 PM Simon Riggs wrote: > On 11 January 2013 10:40, Amit Kapila wrote: > > > Test results with original pgbench (synccommit off) on the latest > patch: > > > > > > -Patch- -tps@-c1- -WAL@-c1- -tps@-c2- - > WAL@-c2- > > Head1

[HACKERS] allowing privileges on untrusted languages

Here is a proposed patch for the issue discussed in : I'd propose getting rid of lanplistrusted, at least for access checking. Instead, just don't install USAGE privileges by default for those languages.

[HACKERS] bugfix: --echo-hidden is not supported by \sf statements

Hello this is very simple patch - it enables hidden_queries for commands \sf and \ef to be consistent with other describing commands. bash-4.1$ ./psql postgres -E psql (9.3devel) Type "help" for help. postgres=# \sf+ foo * QUERY ** SELECT pg_catalog.pg_get_functiondef(16385) **

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On 11 January 2013 10:40, Amit Kapila wrote: > Test results with original pgbench (synccommit off) on the latest patch: > > > -Patch- -tps@-c1- -WAL@-c1- -tps@-c2- -WAL@-c2- > Head1459 1.40 GB2491 1.70 GB > WAL modification1

Re: [HACKERS] Performance Improvement by reducing WAL for Update Operation

On Wednesday, January 09, 2013 4:57 PM Simon Riggs wrote: > On 9 January 2013 08:05, Amit kapila wrote: > > > Update patch contains handling of below Comments > > Thanks > > > > Test results with modified pgbench (1800 record size) on the latest > patch: > > > > -Patch- -tps@-c1-

[HACKERS] Get current query in a trigger function

Is there any simple way of getting a query for which a trigger was executed? debug_query_string and ActivePortal->sourceText return the top query when there are nested triggers. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://w

Re: [HACKERS] Possible PANIC in PostPrepare_Locks

On 11.01.2013 04:16, Tom Lane wrote: [explanation of a race condition] Good catch. Also, it looks like we'll need two code paths in PostPrepare_Locks to deal with the possibility that a conflicting entry already exists? I'm not sure this is possible, but I'm not sure it's not, either. If I