Re: [HACKERS] PATCH: Implement value_to_json for single-datum conversion

2012-08-13 Thread Tom Lane
Craig Ringer ring...@ringerc.id.au writes: As for the value_to_json crashing, works for me: postgres=# SELECT value_to_json(42); value_to_json --- 42 (1 row) Oh, right, because there actually is support for anyelement in the underlying C function. There is not in the

Re: [HACKERS] PATCH: Implement value_to_json for single-datum conversion

2012-08-13 Thread Craig Ringer
On 08/13/2012 01:55 PM, Tom Lane wrote: Actually, given the above, what did you need value_to_json(text) for at all? Wouldn't value_to_json(anyelement) have covered it? Usability. Without the version accepting text an explicit cast to text is required to disambiguate a literal argument like

Re: [HACKERS] default_isolation_level='serializable' crashes on Windows

2012-08-13 Thread Heikki Linnakangas
On 12.08.2012 17:39, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: The problem is that when a postmaster subprocess is launched, it calls read_nondefault_variables() very early, before shmem initialization, to read the non-default config options from the file

Re: [HACKERS] default_isolation_level='serializable' crashes on Windows

2012-08-13 Thread Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: On 12.08.2012 17:39, Tom Lane wrote: A larger point is that I think it's broken for any GUC assignment function to be calling something as transient as RecoveryInProgress to start with. Hmm, it seems like the logical place to

Re: [HACKERS] default_isolation_level='serializable' crashes on Windows

2012-08-13 Thread Amit Kapila
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki Linnakangas Sent: Monday, August 13, 2012 12:14 PM On 12.08.2012 17:39, Tom Lane wrote: Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes: The problem is that when a postmaster

Re: [HACKERS] default_isolation_level='serializable' crashes on Windows

2012-08-13 Thread Amit Kapila
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila Sent: Monday, August 13, 2012 12:47 PM From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Heikki Linnakangas Sent: Monday, August 13, 2012

Re: [HACKERS] Proof of concept: auto updatable views

2012-08-13 Thread Dean Rasheed
I've been looking at this further and I have made some improvements, but also found a problem. On 1 July 2012 23:35, Dean Rasheed dean.a.rash...@gmail.com wrote: I'm also aware that my new function ChangeVarAttnos() is almost identical to the function map_variable_attnos() that Tom recently

Re: [HACKERS] Yet another failure mode in pg_upgrade

2012-08-13 Thread Magnus Hagander
On Mon, Aug 13, 2012 at 4:34 AM, Tom Lane t...@sss.pgh.pa.us wrote: I've been experimenting with moving the Unix socket directory to /var/run/postgresql for the Fedora distribution (don't ask :-(). It's mostly working, but I found out yet another way that pg_upgrade can crash and burn: it

Re: [HACKERS] Bug in libpq implentation and omission in documentation?

2012-08-13 Thread Heikki Linnakangas
On 08.08.2012 17:35, Tom Lane wrote: A runtime check for too many parameters seems appropriate. Assuming that the error message it throws is well written, I don't think we need to adjust the documentation. There are many limitations that are not spelled out in the docs, and adding every one of

[HACKERS] sharing variables between client and server again

2012-08-13 Thread Pavel Stehule
Hello this is VIP patch that implements shared - status variables to PostgreSQL. A motivation for this features is possibility to take client parameters inside inlined PL blocks. This design is based on Magnus's ideas. Content is synchronized between server and client. This doesn't need a

[HACKERS] SIGFPE handler is naive

2012-08-13 Thread Robert Haas
A member of our technical team brought it to my attention that if you have a recalcitrant backend that doesn't die when you send it a SIGTERM, and you don't want to cause a crash-and-restart cycle by sending it SIGQUIT, you can have your cake and eat it too by sending it SIGFPE, which will

Re: [HACKERS] default_isolation_level='serializable' crashes on Windows

2012-08-13 Thread Kevin Grittner
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: While playing around, I bumped into another related bug, and after googling around I found out that it was already reported by Robert Haas earlier, but still not fixed:

[HACKERS] Upcoming back-branch releases

2012-08-13 Thread Tom Lane
We are going to prepare back-branch update releases to take care of a couple of minor security issues that have been waiting much too long already. The schedule will be a bit unusual though: wrap tarballs this Tuesday evening (that's tomorrow) for public announcement Friday the 17th. This is not

[HACKERS] 9.2 Cascading replication after slave promotion

2012-08-13 Thread Mark Kirkwood
Looking at the docs (section 25.2.6 paragraph 6) leads one to believe that downstream standbys can continue to receive and process wal merely by reconnecting after the cascading standby is promoted - but this does not seem to be the case (indeed the same paragraph notes that timelines now no

Re: [HACKERS] 9.2 Cascading replication after slave promotion

2012-08-13 Thread Josh Berkus
Mark, Looking at the docs (section 25.2.6 paragraph 6) leads one to believe that downstream standbys can continue to receive and process wal merely by reconnecting after the cascading standby is promoted - but this does not seem to be the case (indeed the same paragraph notes that timelines

Re: [HACKERS] 9.2 Cascading replication after slave promotion

2012-08-13 Thread Mark Kirkwood
On 14/08/12 12:32, Josh Berkus wrote: Mark, Looking at the docs (section 25.2.6 paragraph 6) leads one to believe that downstream standbys can continue to receive and process wal merely by reconnecting after the cascading standby is promoted - but this does not seem to be the case (indeed the

Re: [HACKERS] 9.2 Cascading replication after slave promotion

2012-08-13 Thread Daniel Farina
On Mon, Aug 13, 2012 at 5:32 PM, Josh Berkus j...@agliodbs.com wrote: To date, I seem to be the only one convinced that this is an actual deficiency ... It is an actual deficiency, and I am convinced. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] SIGFPE handler is naive

2012-08-13 Thread Noah Misch
On Mon, Aug 13, 2012 at 01:04:58PM -0400, Robert Haas wrote: A member of our technical team brought it to my attention that if you have a recalcitrant backend that doesn't die when you send it a SIGTERM, and you don't want to cause a crash-and-restart cycle by sending it SIGQUIT, you can have

Re: [HACKERS] 9.2 Cascading replication after slave promotion

2012-08-13 Thread Stephen Frost
* Daniel Farina (dan...@heroku.com) wrote: On Mon, Aug 13, 2012 at 5:32 PM, Josh Berkus j...@agliodbs.com wrote: To date, I seem to be the only one convinced that this is an actual deficiency ... It is an actual deficiency, and I am convinced. Yeah, I think there's more people that agree

Re: [HACKERS] SIGFPE handler is naive

2012-08-13 Thread Robert Haas
On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch n...@leadboat.com wrote: If this use of SIGFPE is handy, we should expose it under a better name. What hazards make it unsafe? Well, the most obvious problem is that a backend might receive it while holding a spinlock. Overall, though, I think it

Re: [HACKERS] SIGFPE handler is naive

2012-08-13 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch n...@leadboat.com wrote: Overall, though, I think it best to plug this. We could set a flag before each operation, like evaluation of SQL arithmetic, for which SIGFPE is normal. Yeah, that's what I

Re: [HACKERS] canceling autovacuum task woes

2012-08-13 Thread Peter Eisentraut
On Tue, 2012-07-24 at 16:14 -0400, Robert Haas wrote: On Tue, Jul 24, 2012 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Yeah, you're right. So you do get the table name. But you don't get the cause, which is what you really need to understand

Re: [HACKERS] default_isolation_level='serializable' crashes on Windows

2012-08-13 Thread Kevin Grittner
Heikki Linnakangas wrote: While playing around, I bumped into another related bug, and after googling around I found out that it was already reported by Robert Haas earlier, but still not fixed: Kevin, the last message on that thread says you'll write a patch for that. Ping? OK,

Re: [HACKERS] default_isolation_level='serializable' crashes on Windows

2012-08-13 Thread Kevin Grittner
Kevin Grittner wrote: OK, attached [sigh] This time for sure! -Kevin hotstandby-serializable.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers