I test this patch, it seems to fix this problem. I think recovery and WAL write
control are very difficult... So I make debug log which is more helpful for like
this trouble.
Sorry, attached my patch had very easy problem... Please used this patch.
Best regards,
--
NTT Open Sorce Software Center
Thanks for creating patch !!
I test this patch, it seems to fix this problem. I think recovery and WAL write
control are very difficult... So I make debug log which is more helpful for like
this trouble.
Though I think you have already known, this problem has occurred in also master
database
Use correct length to convert json unicode escapes.
Bug reported on IRC - fix due to Andrew Gierth.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/5f8b4319b94476de715ffef9183227ac6f4925c0
Modified Files
--
src/backend/utils/adt/json.c |2 +-
1 files
Fix permission tests for views/tables proven empty by constraint exclusion.
A view defined as "select where false" had the curious property
that the system wouldn't check whether users had the privileges necessary
to select from it. More generally, permissions checks could be skipped
for tables
Fix permission tests for views/tables proven empty by constraint exclusion.
A view defined as "select where false" had the curious property
that the system wouldn't check whether users had the privileges necessary
to select from it. More generally, permissions checks could be skipped
for tables
I wrote:
> Of course the select from vv2 should fail as well, but it doesn't,
> because vv2 is nowhere to be seen in the rangetable passed to the
> executor. I think the planner is probably trashing the rangetable
> once it realizes that the query is completely dummy; but this is wrong
> because w
