Re: [HACKERS] PL/pgSQL, RAISE and error context

2015-01-26 Thread Pavel Stehule
2015-01-26 13:02 GMT+01:00 Marko Tiikkaja : > On 1/22/15 6:03 PM, Pavel Stehule wrote: > >> 2015-01-22 12:37 GMT+01:00 Marko Tiikkaja : >> >>> Or is that a stupid idea? I just think hacking libpq for something like >>> this is a huge overkill. >>> >>> >> I don't think so only plpgsql solution is

Re: [HACKERS] PL/pgSQL, RAISE and error context

2015-01-26 Thread Marko Tiikkaja
On 1/22/15 6:03 PM, Pavel Stehule wrote: 2015-01-22 12:37 GMT+01:00 Marko Tiikkaja : Or is that a stupid idea? I just think hacking libpq for something like this is a huge overkill. I don't think so only plpgsql solution is satisfactory idea. There are some mix plpgsql / plperl ... applicat

Re: [HACKERS] longjmp clobber warnings are utterly broken in modern gcc

2015-01-26 Thread Andres Freund
On 2015-01-25 15:40:10 -0500, Tom Lane wrote: > Greg Stark writes: > > Perhaps Clang has a more useful warning? > > Clang, at least the version on my Mac, doesn't warn either with the > settings we normally use, and it doesn't have -Wclobber at all. > I tried turning on -Weverything, and it still

Re: [HACKERS] longjmp clobber warnings are utterly broken in modern gcc

2015-01-26 Thread Andres Freund
Hi, On 2015-01-25 14:02:47 -0500, Tom Lane wrote: > I've been looking for other instances of the problem Mark Wilding > pointed out, about missing "volatile" markers on variables that > are modified in PG_TRY blocks and then used in the PG_CATCH stanzas. > There definitely are some. Current gcc v

Re: [HACKERS] Unsafe coding in ReorderBufferCommit()

2015-01-26 Thread Andres Freund
Hi Tom, On 2015-01-23 16:47:30 -0500, Tom Lane wrote: > There are at least two bugs in reorderbuffer.c's ReorderBufferCommit(): Thanks for fixing these! Unfortunately there's more - we'll currently do bad things if transaction commit fails. At the very least the (sub-)transaction begin commands

Re: [HACKERS] basebackups during ALTER DATABASE ... SET TABLESPACE ... not safe?

2015-01-26 Thread Andres Freund
On 2015-01-22 22:58:17 +0100, Andres Freund wrote: > Because the way it currently works is a major crock. It's more luck than > anything that it actually somewhat works. We normally rely on WAL to > bring us into a consistent state. But around CREATE/MOVE/DROP DATABASE > we've ignored that. Hah: T

Re: [HACKERS] SSL renegotiation and other related woes

2015-01-26 Thread Andres Freund
On 2015-01-26 11:14:05 +0100, Andres Freund wrote: > My testcase for this is just to setup a server with a low > ssl_renegotiation_limit, generate lots of WAL (wal.sql attached) and > receive data via pg_receivexlog -n. Usually it'll error out quickly. ... Greetings, Andres Freund -- Andres F

[HACKERS] SSL renegotiation and other related woes

2015-01-26 Thread Andres Freund
Hi, When working on getting rid of ImmediateInterruptOK I wanted to verify that ssl still works correctly. Turned out it didn't. But neither did it in master. Turns out there's two major things we do wrong: 1) We ignore the rule that once called and returning SSL_ERROR_WANTS_(READ|WRITE) SSL_

[HACKERS] pg_dump with both --serializable-deferrable and -j

2015-01-26 Thread Alexander Korotkov
Hackers, when pg_dump is run with both --serializable-deferrable and -j options to pg_dump, it returns errors: pg_dump: [archiver (db)] query failed: ERROR: a snapshot-importing transaction must not be READ ONLY DEFERRABLE pg_dump: [archiver (db)] query failed: ERROR: a snapshot-importing trans

<    1   2