A customer reported that when you set
default_isolation_level='serializable' in postgresql.conf on Windows,
and try to start up the database, it crashes immediately. And sure
enough, it does, on REL9_1_STABLE as well as on master.
Stack trace:
postgres!RecoveryInProgress+0x3a
[c:\postgresql\
Heikki Linnakangas 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 that postmaster wrote.
> When check_XactIsoLevel() calls RecoveryInPr
On Thu, Aug 9, 2012 at 12:44 AM, Alexander Korotkov wrote:
> My conclusion is so, that current errors are probably ok for selectivity
> estimation. But taking into attention that generated datasets ideally fits
> assumptions of estimation, there could be room for improvement. Especially,
> it's un
On Sat, 2012-08-11 at 14:05 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > What is the intended way to handle errors in the new logging hook?
>
> I'm not sure there is anything very useful you can do to "handle" them,
> if by "handle" you mean "report somewhere".
Yes, they ought to be wri
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 doesn't consider the possibility that the
old or new postmaster is compiled w
Hi all
Whenever I try to work with the new json types I trip over the lack of a
function to escape text to json. The attached patch against master
provides one by exposing the existing datum_to_json function to SQL.
I've used the name value_to_json, but I'm not sure it's necessarily the
right
Whoops. It actually looks like the posted patch muffed up opr_sanity
checks. I'm totally new to pg_proc.h wrangling so I'm not sure why yet,
looking.
Sorry, not sure how I missed that. I'll follow up shortly.
--
Craig Ringer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
It appears that a recent Perl version (I have 5.14.2) has eliminated
OP_SETSTATE, which causes the current PostgreSQL build to fail:
plperl.c: In function ‘_PG_init’:
plperl.c:442:5645: error: ‘OP_SETSTATE’ undeclared (first use in this function)
plperl.c:442:5645: note: each undeclared identifier
OK, opr_sanity was failing because I added the value_to_json(text) alias
to ensure that:
value_to_json('some_literal')
worked, following the same approach as quote_literal(anyelement) and
quote_literal(text). That should be reasonable, right? The comments on
the affected check in opr_sanity
Craig Ringer writes:
> OK, opr_sanity was failing because I added the value_to_json(text) alias
> to ensure that:
>value_to_json('some_literal')
> worked, following the same approach as quote_literal(anyelement) and
> quote_literal(text). That should be reasonable, right?
No, it isn't. W
Craig Ringer writes:
> Whenever I try to work with the new json types I trip over the lack of a
> function to escape text to json. The attached patch against master
> provides one by exposing the existing datum_to_json function to SQL.
> ...
> This feels basic enough that I'm wondering if there'
On 08/13/2012 12:48 PM, Tom Lane wrote:
There actually was a previous thread about this:
http://archives.postgresql.org/pgsql-hackers/2012-05/msg1.php
Note in particular Andrew's comment:
Second, RFC 4627 is absolutely clear: a valid JSON value can
only be an object or an arr
Craig Ringer 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 quote_literal case.
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
On 12.08.2012 17:39, Tom Lane wrote:
Heikki Linnakangas 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 that postmaster wrote.
When check_Xact
15 matches
Mail list logo
