Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

On Thu, Jul 24, 2014 at 5:59 PM, Asif Naeem wrote: > Sorry for being late. Thank you for sharing updated patch, sgml changes > seems not working i.e. > >> postgres=# select max('192.168.1.5', '192.168.1.4'); >> ERROR: function max(unknown, unknown) does not exist >> LINE 1: select max('192.168.1.

Re: [HACKERS] [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

From: "Tom Lane" [ sinval catchup signal -> ProcessCatchupEvent -> WaitLatch -> deadlock ] I must add one thing. After some client processes closed the connection without any hang, their server processes were stuck with a stack trace like this (I'll look for and show the exact stack trace t

Re: [HACKERS] Use unique index for longer pathkeys.

On Sat, Jul 26, 2014 at 11:53 AM, Amit Kapila wrote: > On Fri, Jul 25, 2014 at 12:48 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > I think there is one more disadvantage in the way current patch is > > > done which is that you need to collect index path keys for all relatio

Re: [HACKERS] PL/PgSQL: RAISE and the number of parameters

Hi 2014-07-26 20:39 GMT+02:00 Marko Tiikkaja : > Me again, > > Here's a patch for making PL/PgSQL throw an error during compilation > (instead of runtime) if the number of parameters passed to RAISE don't > match the number of placeholders in error message. I'm sure people can see > the pros of

Re: [HACKERS] PL/PgSQL: EXIT USING ROLLBACK

Hello 2014-07-26 19:14 GMT+02:00 Marko Tiikkaja : > Hello, > > Today I'd like to present a way to get rid of code like this: > > $$ > BEGIN > > BEGIN > INSERT INTO foo VALUES (1); > -- run some tests/checks/whatever > RAISE EXCEPTION 'OK'; > EXCEPTION WHEN raise_exception THE

Re: [HACKERS] parametric block size?

On 26/07/14 21:05, Andres Freund wrote: More advanced features, but with much more impact on the code, would be to be able to change the size at database/table level. That'd be pretty horrible because the size of pages in shared_buffers wouldn't be uniform anymore. Possibly stopping at th

Re: [HACKERS] building pdfs

On 07/26/2014 06:44 PM, Tom Lane wrote: Andrew Dunstan writes: Yes, I did that and generated a PDF, but I got an enormous number of errors or warnings. See for example. If they're things like "overfull hbox" from the TeX step, they'r

Re: [HACKERS] building pdfs

Andrew Dunstan writes: > Yes, I did that and generated a PDF, but I got an enormous number of > errors or warnings. See > for example. If they're things like "overfull hbox" from the TeX step, they're expected.

Re: [HACKERS] building pdfs

On 07/26/2014 02:22 PM, Andres Freund wrote: On 2014-07-26 14:14:15 -0400, Tom Lane wrote: Andrew Dunstan writes: Is there any standard set of packages on any supported platform that will allow for building the doc PDFs? So far I have not found one on either Fedora 20 or Ubuntu 14.04, but may

Re: [HACKERS] PL/PgSQL: EXIT USING ROLLBACK

On 7/26/14, 8:39 PM, Tom Lane wrote: Marko Tiikkaja writes: I'm not sure which case you're envisioning. A label is required, and the label must be that of a BEGIN block with an EXCEPTION block if USING ROLLBACK is specified. If that doesn't answer your question, could try and explain (perhaps

Re: [HACKERS] PL/PgSQL: EXIT USING ROLLBACK

Marko Tiikkaja writes: > On 7/26/14, 8:22 PM, Tom Lane wrote: >> In particular, what happens if someone attaches USING ROLLBACK >> to an EXIT that does not lead from inside to outside a BEGIN/EXCEPTION >> block? > I'm not sure which case you're envisioning. A label is required, and > the label

[HACKERS] PL/PgSQL: RAISE and the number of parameters

Me again, Here's a patch for making PL/PgSQL throw an error during compilation (instead of runtime) if the number of parameters passed to RAISE don't match the number of placeholders in error message. I'm sure people can see the pros of doing it this way. .marko *** a/src/pl/plpgsql/src/pl

Re: [HACKERS] PL/PgSQL: EXIT USING ROLLBACK

On 7/26/14, 8:22 PM, Tom Lane wrote: In particular, what happens if someone attaches USING ROLLBACK to an EXIT that does not lead from inside to outside a BEGIN/EXCEPTION block? I'm not sure which case you're envisioning. A label is required, and the label must be that of a BEGIN block with a

Re: [HACKERS] PL/PgSQL: EXIT USING ROLLBACK

Marko Tiikkaja writes: > Hello, > Today I'd like to present a way to get rid of code like this: >$$ >BEGIN >BEGIN > INSERT INTO foo VALUES (1); > -- run some tests/checks/whatever > RAISE EXCEPTION 'OK'; >EXCEPTION WHEN raise_exception THEN > IF SQLERRM <> 'OK

Re: [HACKERS] building pdfs

On 2014-07-26 14:14:15 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > Is there any standard set of packages on any supported platform that > > will allow for building the doc PDFs? So far I have not found one on > > either Fedora 20 or Ubuntu 14.04, but maybe I'm missing something. > > On

Re: [HACKERS] [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

On 2014-07-26 13:58:38 -0400, Tom Lane wrote: > Andres Freund writes: > > That'd require either renegging on SA_RESTART or > > using WaitLatchOrSocket() and nonblocking send/recv. > > Yeah, I was wondering about using WaitLatchOrSocket for client I/O too. > We already have a hook that lets us do

Re: [HACKERS] building pdfs

Andrew Dunstan writes: > Is there any standard set of packages on any supported platform that > will allow for building the doc PDFs? So far I have not found one on > either Fedora 20 or Ubuntu 14.04, but maybe I'm missing something. On either Fedora or RHEL, installing the "authoring tools" pa

Re: [HACKERS] [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

Andres Freund writes: > Wouldn't it be better to move the catchup interrupt processing out of > the signal handler? For normal backends we only enable when reading from > the client and DoingCommandRead is set. How about setting a variable in > the signal handler and doing the actual catchup proce

Re: [HACKERS] parametric block size?

The basic claim that I'm making wrt to this benchmark is that there may be a significant impact on performance with changing the block size, thus this is worth investigating. I think this claim is quite safe, even if the benchmark is not the best possible. Well, you went straight to making i

Re: [HACKERS] parametric block size?

On 2014-07-26 19:06:58 +0200, Fabien COELHO wrote: > The basic claim that I'm making wrt to this benchmark is that there may be a > significant impact on performance with changing the block size, thus this is > worth investigating. I think this claim is quite safe, even if the benchmark > is not th

[HACKERS] PL/PgSQL: EXIT USING ROLLBACK

Hello, Today I'd like to present a way to get rid of code like this: $$ BEGIN BEGIN INSERT INTO foo VALUES (1); -- run some tests/checks/whatever RAISE EXCEPTION 'OK'; EXCEPTION WHEN raise_exception THEN IF SQLERRM <> 'OK' THEN RAISE; END IF; END; RETURN '

Re: [HACKERS] parametric block size?

The rationale, which may be proven false, is that with a SSD the latency penalty for reading and writing randomly vs sequentially is much lower than for HDD, so there is less insentive to group stuff in larger chunks on that account. A higher number of blocks has overhead unrelated to this t

[HACKERS] building pdfs

Is there any standard set of packages on any supported platform that will allow for building the doc PDFs? So far I have not found one on either Fedora 20 or Ubuntu 14.04, but maybe I'm missing something. I am looking at adding a buildfarm facility to build the docs, but I'm not prepared to m

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

On 26 July 2014 15:43, Tom Lane wrote: > Thomas Munro writes: >> I couldn't find an existing reasonable place to share a single wait >> policy enumeration between parser/planner/executor and the heap access >> module, and I get the feeling that it would be unacceptable to >> introduce one. > > Th

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

On Sat, Jul 26, 2014 at 4:37 AM, Andres Freund wrote: > On 2014-07-25 14:11:32 -0400, Robert Haas wrote: >> Attached is a contrib module that lets you launch arbitrary command in >> a background worker, and supporting infrastructure patches for core. > > Cool. > > I assume this 'fell out' of the w

Re: [HACKERS] [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

On 2014-07-26 11:32:24 -0400, Tom Lane wrote: > "MauMau" writes: > > [ sinval catchup signal -> ProcessCatchupEvent -> WaitLatch -> deadlock ] > > Ugh. > > One line of thought is that it's pretty unsafe to be doing anything > as complicated as transaction start/commit in a signal handler, even o

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

On Fri, Jul 25, 2014 at 4:16 PM, Alvaro Herrera wrote: > On Fri, Jul 25, 2014 at 02:11:32PM -0400, Robert Haas wrote: >> + pq_mq_busy = true; >> + >> + iov[0].data = &msgtype; >> + iov[0].len = 1; >> + iov[1].data = s; >> + iov[1].len = len; >> + >> + Assert(pq_mq_handle !=

Re: [HACKERS] parametric block size?

Hi, On 2014-07-26 12:50:30 +0200, Fabien COELHO wrote: > >>The default blocksize is currently 8k, which is not necessary optimal for > >>all setup, especially with SSDs where the latency is much lower than HDD. > > > >I don't think that really follows. > > The rationale, which may be proven false

Re: [HACKERS] [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

"MauMau" writes: > [ sinval catchup signal -> ProcessCatchupEvent -> WaitLatch -> deadlock ] Ugh. One line of thought is that it's pretty unsafe to be doing anything as complicated as transaction start/commit in a signal handler, even one that is sure it's not interrupting anything else. The on

Re: [HACKERS] BUG - broken "make check" if different options

As I was investing playing around with blocksize, I noticed that some test cases under "make check" vary depending on compilation parameters, as they: There has never been any expectation that the regression tests would pass exactly no matter what the environment. If we tried to make them d

[HACKERS] config.sgml referring to unix_socket_directories on older releases

Hi, While updating the french translation of the latest releases, I stumbled upon a small issue on the config.sgml file. It talks about unix_socket_directories whereas this parameter only appears with the 9.3 release. It should probably be replaced with unix_socket_directory for all releases wher

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

Thomas Munro writes: > I couldn't find an existing reasonable place to share a single wait > policy enumeration between parser/planner/executor and the heap access > module, and I get the feeling that it would be unacceptable to > introduce one. There is a precedent in the form of AclMode, which

Re: [HACKERS] get_loop_count() fails to ignore RELOPT_DEADREL rels

David Rowley writes: > In order to get my patch working with an Assert enabled build I've had to > apply the attached patch. That patch is entirely bogus. What you should be asking is why get_loop_count is being applied to a relation that's supposedly been removed from the query. It should only

Re: [HACKERS] BUG - broken "make check" if different options

Fabien COELHO writes: > As I was investing playing around with blocksize, I noticed that some test > cases under "make check" vary depending on compilation parameters, as > they: There has never been any expectation that the regression tests would pass exactly no matter what the environment. I

Re: [HACKERS] parametric block size?

Hello Andres, The default blocksize is currently 8k, which is not necessary optimal for all setup, especially with SSDs where the latency is much lower than HDD. I don't think that really follows. The rationale, which may be proven false, is that with a SSD the latency penalty for reading

Re: [HACKERS] [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

From: "Andres Freund" I think we should do what the first paragraph in http://archives.postgresql.org/message-id/20140707155113.GB1136%40alap3.anarazel.de outlined. As Tom says somewhere downthread that requires some code review, but other than that it should get rid of a fair amount of problems

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

On Sat, Jul 26, 2014 at 9:34 PM, Thomas Munro wrote: > I couldn't find an existing reasonable place to share a single wait > policy enumeration between parser/planner/executor and the heap access > module, and I get the feeling that it would be unacceptable to > introduce one. > > I guess the way

Re: [HACKERS] [RFC] Should smgrtruncate() avoid sending sinval message for temp relations

From: "Robert Haas" I think the problem here is that it actually is possible for one session to access the temporary objects of another session: Now, we could prohibit that specific thing. But at the very least, it has to be possible for one session to drop another session's temporary objects,

Re: [HACKERS] SKIP LOCKED DATA (work in progress)

On 24 July 2014 00:52, Thomas Munro wrote: > On 23 July 2014 13:15, David Rowley wrote: >> I'm also wondering about this block of code in general: >> >> if (erm->waitPolicy == RWP_WAIT) >> wait_policy = LockWaitBlock; >> else if (erm->waitPolicy == RWP_SKIP ) >> wait_policy = LockWaitSkip; >> els

Re: [HACKERS] get_loop_count() fails to ignore RELOPT_DEADREL rels

On Sat, Jul 26, 2014 at 9:11 PM, David Rowley wrote: > In order to get my patch working with an Assert enabled build I've had to > apply the attached patch. > Actually I meant to attach this patch instead. Regards David Rowley get_loop_count_ignore_dead_rels_v2.patch Description: Binary data

[HACKERS] get_loop_count() fails to ignore RELOPT_DEADREL rels

I've just been hacking away a bit more at the WIP patch that I posted a while back which allows join removals for SEMI and ANTI joins that could be proved useless due to the existence of a foreign key which matched the join condition (here http://www.postgresql.org/message-id/caaphdvq0nai8ceqtnndqg

Re: [HACKERS] parametric block size?

Hi, On 2014-07-22 10:22:53 +0200, Fabien wrote: > The default blocksize is currently 8k, which is not necessary optimal for > all setup, especially with SSDs where the latency is much lower than HDD. I don't think that really follows. > There is a case for different values with significant impac

[HACKERS] BUG - broken "make check" if different options

As I was investing playing around with blocksize, I noticed that some test cases under "make check" vary depending on compilation parameters, as they: - do not order the result of queries, thus are not deterministic [join, with] - output query plans which differ depending on some parame

Re: [HACKERS] pg_background (and more parallelism infrastructure patches)

Hi, On 2014-07-25 14:11:32 -0400, Robert Haas wrote: > Attached is a contrib module that lets you launch arbitrary command in > a background worker, and supporting infrastructure patches for core. Cool. I assume this 'fell out' of the work towards parallelism? Do you think all of the patches (ex