The following bug has been logged on the website:
Bug reference: 8210
Logged by: Martin Schaefer
Email address: martin.schae...@cadcorp.com
PostgreSQL version: 9.2.1
Operating system: Windows 8
Description:
The following code:
const wchar_t *strName = L"id_äß";
On Wednesday, June 05, 2013 5:34 AM Rafał Rzepecki wrote:
> On Tue, Jun 4, 2013 at 12:35 PM, Amit Kapila
> wrote:
> > On Saturday, June 01, 2013 9:37 PM
> >
> >> Row type literals constructed with ROW() cause an error when used in
> >> an IN clause (string literals casted appropriately are allowed
On Tue, Jun 4, 2013 at 12:35 PM, Amit Kapila wrote:
> On Saturday, June 01, 2013 9:37 PM
>
>> Row type literals constructed with ROW() cause an error when used in an
>> IN
>> clause (string literals casted appropriately are allowed). This is
>> especially problematic since many client libraries us
Tom, Stephen, Heikki and Andres,
You do FAST work!
Thanks for your prompt responses.
---
Naoya Anzai
NEC Soft,Ltd.
http://www.necsoft.com/eng/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm already working on back-patching the attached.
Works for me,
Thanks!
Stephen
signature.asc
Description: Digital signature
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I think the proposed fix is fine code-wise; the real problem here is
>> crummy commenting. GetRunningTransactionLocks isn't documented as
>> returning a palloc'd array, and why the heck do we have a long comment
>> about its implem
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Meh. I'm not impressed with permanently allocating an array large
> enough to hold all the locks GetRunningTransactionLocks
> might return --- that's potentially much larger than the other array,
> and in fact I don't think we have a hard limit on its size
* Andres Freund (and...@2ndquadrant.com) wrote:
> Seems more consistent with the rest of the code too. But anyway, I am
> fine with fixing it either way.
Patch attached which mirrors what GetRunningTransactionData() (the other
function called from LogStandbySnapshot) does, more-or-less- uses a
sta
Stephen Frost writes:
> * Andres Freund (and...@2ndquadrant.com) wrote:
>> Seems more consistent with the rest of the code too. But anyway, I am
>> fine with fixing it either way.
> And this is really the other point- having LogStandbySnapshot() need to
> clean up after GetRunningTransactionLocks
To respecting PIC
The version I used : postgresql-jdbc-9.1-901.jdbc4
When one of a Postgresql db table has array column which contains Strings.
And some of these Array slices contain ideographic space(U+3000 in
Unicode6.0).
In such a case returned result lacks this ideographic space.
My use case
The following bug has been logged on the website:
Bug reference: 8202
Logged by: mrenda delta pamungkas
Email address: mre...@sisdh.com
PostgreSQL version: 8.4.17
Operating system: windows 7 64 bit
Description:
http://img822.imageshack.us/img822/5497/postgresqld.png
On 04/06/13 16:29, Andres Freund wrote:
Hi,
On 2013-06-04 16:20:12 +0100, Federico Campoli wrote:
Well, if you check the output in that file you can see that 'apply' is
progressing, so it's not stuck in some specific area.
Is the startup process cpu bound during that time? If so, any chance to
Hi,
On 2013-06-04 16:20:12 +0100, Federico Campoli wrote:
> >Well, if you check the output in that file you can see that 'apply' is
> >progressing, so it's not stuck in some specific area.
> >Is the startup process cpu bound during that time? If so, any chance to
> >get a profile?
>
> Please find
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-06-04 16:23:00 +0300, Heikki Linnakangas wrote:
> > I can't get too excited about the overhead of a single palloc here. It's a
> > fairly heavy operation anyway, and only runs once per checkpoint. And we
> > haven't heard any actual complain
On 2013-06-04 16:23:00 +0300, Heikki Linnakangas wrote:
> On 04.06.2013 15:27, Stephen Frost wrote:
> >* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
> >>I've found a memory-leak bug in PostgreSQL 9.1.9's background
> >>writer process.
> >
> >This looks legit, but probably not the right appro
On 04.06.2013 15:27, Stephen Frost wrote:
* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
I've found a memory-leak bug in PostgreSQL 9.1.9's background
writer process.
This looks legit, but probably not the right approach to fixing it.
Looks like it'd be better to work out a way to use a
On 2013-06-04 13:57:58 +0100, Federico Campoli wrote:
> On 02/06/13 01:17, Jeff Janes wrote:
> >On Thursday, May 30, 2013, wrote:
> >
> >The following bug has been logged on the website:
> >
> >Bug reference: 8192
> >Logged by: Federico Campoli
> >Email address: feder.
On 02/06/13 01:17, Jeff Janes wrote:
On Thursday, May 30, 2013, wrote:
The following bug has been logged on the website:
Bug reference: 8192
Logged by: Federico Campoli
Email address: feder...@brandwatch.com
PostgreSQL version: 9.2.4
Operating system: De
* Naoya Anzai (anzai-na...@mxu.nes.nec.co.jp) wrote:
> I've found a memory-leak bug in PostgreSQL 9.1.9's background
> writer process.
This looks legit, but probably not the right approach to fixing it.
Looks like it'd be better to work out a way to use a static variable to
reuse the same memory,
On Saturday, June 01, 2013 9:37 PM
> Row type literals constructed with ROW() cause an error when used in an
> IN
> clause (string literals casted appropriately are allowed). This is
> especially problematic since many client libraries use these literals
> to
> pass values of row-type arguments,
Hi All.
I've found a memory-leak bug in PostgreSQL 9.1.9's background
writer process.
When following parameter is set, it occurs every time CHECKPOINT runs.
wal_level = hot_standby
I've also confirmed REL9_1_STABLE and it is not fixed yet.
In additional, it also occurs in 9.3.beta1's checkpo
21 matches
Mail list logo
