On 7 August 2014 19:49, Kevin Grittner wrote:
> Amit Khandekar wrote:
>> On 21 June 2014 23:36, Kevin Grittner wrote:
>>> Kevin Grittner wrote:
>>> I didn't change the tuplestores to TID because it seemed to me that
>>> it would preclude using transition relations with FDW triggers, and
>>> it
On Tue, Aug 12, 2014 at 01:58:17PM +0900, Michael Paquier wrote:
> On Tue, Aug 12, 2014 at 9:43 AM, Noah Misch wrote:
> >
> > Somehow or other, we must bring these parts into agreement.
>
>
> It is interesting to see that with MinGW-32b getaddrinfo is still set
> to no at configure phase. What i
On Mon, 2014-08-11 at 01:29 +0200, Tomas Vondra wrote:
> On 10.8.2014 23:26, Jeff Davis wrote:
> > This patch is requires the Memory Accounting patch, or something
> > similar to track memory usage.
>
> I think the patch you sent actually includes the accounting patch. Is
> that on purpose, or by
On Tue, Aug 12, 2014 at 9:43 AM, Noah Misch wrote:
>
> Somehow or other, we must bring these parts into agreement.
It is interesting to see that with MinGW-32b getaddrinfo is still set
to no at configure phase. What if we simply wrap "undef gai_strerror"
like in the patch attached? I just set up
On Tue, Aug 12, 2014 at 9:29 AM, Fujii Masao wrote:
> On Tue, Aug 12, 2014 at 2:34 AM, Robert Haas
wrote:
> >
> > If you have a user devoted to it, I suppose that's true. I still
> > think it shouldn't get munged together like that.
>
> Why do we need to treat only replication commands as specia
On Mon, Aug 11, 2014 at 11:08 PM, Fujii Masao wrote:
>
>
> While updating the patch, I found that the ConfigVariable which
> is removed from list has the fields that the memory has been already
> allocated but we forgot to free them. So I included the code to free
> them in the patch.
Yes, that i
On Tue, Aug 12, 2014 at 2:34 AM, Robert Haas wrote:
> On Fri, Aug 8, 2014 at 1:04 PM, Fujii Masao wrote:
>> On Sat, Aug 9, 2014 at 12:29 AM, Robert Haas wrote:
>>> On Fri, Aug 8, 2014 at 11:00 AM, Bruce Momjian wrote:
On Fri, Aug 8, 2014 at 08:51:13AM -0400, Robert Haas wrote:
> On Th
> >>
> >> Oh, just revived that code.
> >
> >
> > yes, It is looking well
>
> Ok, committed!
>
super
thank you very much
Regards
Pavel
>
> Regards,
>
> --
> Fujii Masao
>
On Tue, Aug 12, 2014 at 4:41 AM, Pavel Stehule wrote:
>
>
>
> 2014-08-11 14:59 GMT+02:00 Fujii Masao :
>
>> On Sat, Aug 9, 2014 at 4:16 AM, Pavel Stehule
>> wrote:
>> > Hi
>> >
>> >
>> > 2014-08-08 13:58 GMT+02:00 Fujii Masao :
>> >
>> >> On Fri, Aug 8, 2014 at 4:31 AM, Pavel Stehule
>> >> wrote
On Sun, Aug 10, 2014 at 9:31 PM, MauMau wrote:
> From: "Michael Paquier"
> LINK : fatal error LNK1104: ファイル
> '.\release\postgres\src_timezone_win32ver.obj' を開くことができません。
Oh yes, right. I don't really know how I missed this error when
testing v1. Adding an explicit call to
RemoveFile('src\timezon
On Mon, Aug 11, 2014 at 11:02:48AM -0700, Jeff Janes wrote:
> While trying to test more recent stuff against mingw, I kept running into a
> problem which bisected down to this (a16bac36eca8158cbf78987e953).
> This is the warning/error I get:
>
> auth.c: In function 'ClientAuthentication':
> auth.
On 12.8.2014 02:05, Tom Lane wrote:
>
> Evidently the OOM killer is at large on this machine.
Yes. It's a machine with only 8GB of RAM, and there are 3 VMs (LXC
containers), with 2GB of RAM each. That's not much, but while it's
mostly out of necessity, it's apparently a good way to catch leaks.
T
"Tomas Vondra" writes:
> So after 83 days, the regression tests on barnacle completed,
Hah, that's perseverance!
> and it
> smells like another memory leak in CacheMemoryContext, similar to those
> fixed in 078b2ed on May 18.
Ugh, will look.
> See this:
> http://pgbuildfarm.org/cgi-bin/show_lo
Robert Haas writes:
> On Fri, Aug 8, 2014 at 10:30 AM, MauMau wrote:
>> I've tracked down the real root cause. The fix is very simple. Please
>> check the attached one-liner patch.
> I'd support back-porting that commit to 9.1 and 9.2 as a fix for this
> problem. As the commit message says, i
On 11.8.2014 20:25, Robert Haas wrote:
> On Sat, Aug 9, 2014 at 9:13 AM, Tomas Vondra wrote:
>> Adding least-significant bit does not work, we need get back to adding
>> the most-significant one. Not sure what's the least complex way to do
>> that, though.
>>
>> I'm thinking about computing the nb
On 2014-08-11 17:22:27 -0400, Steve Singer wrote:
> On 07/14/2014 01:19 PM, Steve Singer wrote:
> >On 07/06/2014 10:11 AM, Andres Freund wrote:
> >>Hi Steve,
> >
> >>Right. I thought about this for a while, and I think we should change
> >>two things. For one, don't request replies here. It's simpl
On 07/14/2014 01:19 PM, Steve Singer wrote:
On 07/06/2014 10:11 AM, Andres Freund wrote:
Hi Steve,
Right. I thought about this for a while, and I think we should change
two things. For one, don't request replies here. It's simply not needed,
as this isn't dealing with timeouts. For another do
On Mon, Aug 11, 2014 at 1:01 PM, Stephen Frost wrote:
> We've got a clear example of someone, quite reasonably, expecting their
> JSONB object to be compressed using the normal TOAST mechanism, and
> we're failing to do that in cases where it's actually a win to do so.
> That's the focus of this d
* Peter Geoghegan (p...@heroku.com) wrote:
> If there is to be any effort to make jsonb a more effective target for
> compression, I imagine that that would have to target redundancy
> between JSON documents. With idiomatic usage, we can expect plenty of
> it.
While I certainly agree, that's a rat
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> What we could conceivably do now is (a) add a datatype OID argument to
>> toast_compress_datum, and (b) hard-wire the selection of a different
>> compression-parameters struct if it's JSONBOID. The actual fix would
>> then be to in
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > ... I think it would be a better idea to arrange some method by
> > which JSONB (and perhaps other data types) can provide compression
> > hints to pglz.
>
> I agree with that as a long-term goal, but not sure if it's sane to
> push
Robert Haas wrote:
> On Fri, Aug 8, 2014 at 9:44 PM, Peter Eisentraut wrote:
> > or perhaps make a note at the bottom
> >
> > The options -I, -n, -P, -t, -T, --section can be combined and
> > specified multiple times to select multiple objects.
> >
> > Other ideas?
>
> I like the
2014-08-11 14:59 GMT+02:00 Fujii Masao :
> On Sat, Aug 9, 2014 at 4:16 AM, Pavel Stehule
> wrote:
> > Hi
> >
> >
> > 2014-08-08 13:58 GMT+02:00 Fujii Masao :
> >
> >> On Fri, Aug 8, 2014 at 4:31 AM, Pavel Stehule
> >> wrote:
> >> >
> >> >
> >> >
> >> > 2014-08-07 7:10 GMT+02:00 Fujii Masao :
> >
On Mon, Aug 11, 2014 at 12:07 PM, Robert Haas wrote:
> I think that's a good point.
I think that there may be something to be said for the current layout.
Having adjacent keys and values could take better advantage of CPU
cache characteristics. I've heard of approaches to improving B-Tree
localit
Robert Haas writes:
> ... I think it would be a better idea to arrange some method by
> which JSONB (and perhaps other data types) can provide compression
> hints to pglz.
I agree with that as a long-term goal, but not sure if it's sane to
push into 9.4.
What we could conceivably do now is (a) a
On Sat, Aug 9, 2014 at 3:51 PM, Tom Lane wrote:
> Kevin Grittner writes:
>>> Stephen Frost writes:
Trying to move the header to the end just for the sake of this
doesn't strike me as a good solution as it'll make things quite
a bit more complicated.
>
>> Why is that? How much har
On Mon, Aug 11, 2014 at 1:52 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 8, 2014 at 9:34 PM, Peter Eisentraut wrote:
>>> What is the point of that change?
>
>> I think the output could justly be criticized for making it
>> insufficiently clear that the parenthesized text is, in fact
On Sat, Aug 9, 2014 at 9:13 AM, Tomas Vondra wrote:
> Adding least-significant bit does not work, we need get back to adding
> the most-significant one. Not sure what's the least complex way to do
> that, though.
>
> I'm thinking about computing the nbuckets limit (how many buckets may
> fit into
2014-08-11 19:52 GMT+02:00 Tom Lane :
> Robert Haas writes:
> > On Fri, Aug 8, 2014 at 9:34 PM, Peter Eisentraut
> wrote:
> >> What is the point of that change?
>
> > I think the output could justly be criticized for making it
> > insufficiently clear that the parenthesized text is, in fact, the
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Aug 8, 2014 at 1:04 PM, Fujii Masao wrote:
> > You can do that by executing
> > "ALTER ROLE SET log_statement TO 'all'".
> > If you don't use the replication user to execute SQL statements,
> > no SQL statements are logged in that setting.
>
On Tue, Jul 15, 2014 at 5:14 AM, Michael Paquier
wrote:
> On Tue, Jul 15, 2014 at 8:46 PM, Magnus Hagander
> wrote:
> > On Thu, Jun 19, 2014 at 4:13 PM, MauMau wrote:
> >> From: "Michael Paquier"
> >>
> >>> You are right, I only though about the MS scripts when working on this
> >>> patch. Upd
Robert Haas writes:
> On Fri, Aug 8, 2014 at 9:34 PM, Peter Eisentraut wrote:
>> What is the point of that change?
> I think the output could justly be criticized for making it
> insufficiently clear that the parenthesized text is, in fact, the name
> of the pset parameter.
Quite; that wasn't a
On Fri, Aug 8, 2014 at 9:44 PM, Peter Eisentraut wrote:
> This is a valuable feature change, but I think the help output is
> unhelpful. The left side has a singular placeholder, but the right side
> talks about objects in plural. How do I actually specify multiple
> indexes? Is is --index=foo,
On Fri, Aug 8, 2014 at 9:34 PM, Peter Eisentraut wrote:
> This is 9.3:
>
> peter=# \a
> Output format is unaligned.
> peter=# \a
> Output format is aligned.
> peter=# \x
> Expanded display is on.
> peter=# \x
> Expanded display is off.
>
> This is new in 9.4:
>
> peter=# \a
> Output format (format
On Sun, Aug 10, 2014 at 3:54 PM, Amit Kapila wrote:
> On Fri, Aug 8, 2014 at 11:41 AM, Fujii Masao wrote:
>>
>> Yep, right. ParseConfigFp() is not good place to pick up data_directory.
>> What about the attached patch which makes ProcessConfigFile() instead of
>> ParseConfigFp() pick up data_dire
On Fri, Aug 8, 2014 at 1:04 PM, Fujii Masao wrote:
> On Sat, Aug 9, 2014 at 12:29 AM, Robert Haas wrote:
>> On Fri, Aug 8, 2014 at 11:00 AM, Bruce Momjian wrote:
>>> On Fri, Aug 8, 2014 at 08:51:13AM -0400, Robert Haas wrote:
On Thu, Aug 7, 2014 at 12:07 PM, Abhijit Menon-Sen
wrote:
On Mon, Aug 11, 2014 at 12:27 PM, Robert Haas wrote:
>
>> As Marco says, that can be optimized using filesystem timestamps instead.
>
> The idea of using filesystem timestamps gives me the creeps. Those
> aren't always very granular, and I don't know that (for example) they
> are crash-safe. Doe
On Fri, Aug 8, 2014 at 10:30 AM, MauMau wrote:
> I've tracked down the real root cause. The fix is very simple. Please
> check the attached one-liner patch.
>
> I confirmed that the fix is already in 9.3 and 9.5devel, so I just copied
> the code fragment from 9.5devel to 9.2.9. The attached pat
Hi!
So after 83 days, the regression tests on barnacle completed, and it
smells like another memory leak in CacheMemoryContext, similar to those
fixed in 078b2ed on May 18.
Barnacle is one of those machines with -DCLOBBER_CACHE_RECURSIVELY, and
the tests were running with a snapshot from May 19,
On Sat, Aug 9, 2014 at 2:00 PM, Tom Lane wrote:
>> +1. I think the current behaviour is a seriously bad idea.
>
> I don't think it's anywhere near as black-and-white as you guys claim.
> What it comes down to is whether allowing existing transactions/sessions
> to finish is more important than all
On 2014-08-10 18:36:18 -0400, Noah Misch wrote:
> [Due for a new subject line?]
>
> On Sat, Aug 09, 2014 at 08:16:01PM +0200, Andres Freund wrote:
> > On 2014-08-09 14:09:36 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2014-08-09 14:00:49 -0400, Tom Lane wrote:
> > > >> I don't t
On Tue, Aug 5, 2014 at 8:04 PM, Simon Riggs wrote:
> To decide whether we need to re-copy the file, you read the file until
> we find a block with a later LSN. If we read the whole file without
> finding a later LSN then we don't need to re-copy. That means we read
> each file twice, which is slow
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> The issue that I specifically ran into is that by using
> apt.postgresql.org in its default configuration, I can't add certain
> extensions (without jumping through hoops). Simple:
>
> Assume a running 9.2.9 from apt.postgresql.org
> apt-get
På mandag 11. august 2014 kl. 11:17:56, skrev worthy7 mailto:worthy@gmail.com>>: Perhaps I'm missing something
Table has 2 columns, text and ftstext
text: "how are you"
ftstest: (nothing)
Because "how" and "are" and "you" are too common to be tsvectored. Which is
fine.
So if a user se
Stephen Frost wrote:
>> Our grace period for active backends after unclean exit of one
>> of their peers is low, milliseconds to seconds. Our grace
>> period for active backends after unclean exit of the postmaster
>> is unconstrained. At least one of those policies has to be
>> wrong. Like And
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
I try to catch a DropStmt and convert it to a Rename Stmt, like petere's
pg_trashcan, but i don't like to create new schema. I only like to
rename the table in case of a drop table query.
Is this possible with something like:
ProcessUtility (Nod
On Sat, Aug 9, 2014 at 4:16 AM, Pavel Stehule wrote:
> Hi
>
>
> 2014-08-08 13:58 GMT+02:00 Fujii Masao :
>
>> On Fri, Aug 8, 2014 at 4:31 AM, Pavel Stehule
>> wrote:
>> >
>> >
>> >
>> > 2014-08-07 7:10 GMT+02:00 Fujii Masao :
>> >
>> >> On Thu, Aug 7, 2014 at 6:26 AM, Pavel Stehule
>> >> wrote:
On Mon, Aug 11, 2014 at 4:46 PM, Andres Freund wrote:
> Hi,
>
> On 2011-10-04 20:52:59 +0900, Fujii Masao wrote:
>> *** a/src/backend/access/transam/xact.c
>> --- b/src/backend/access/transam/xact.c
>> ***
>> *** 1066,1071 RecordTransactionCommit(void)
>> --- 1066,1074
>>
>>
Perhaps I'm missing something
Table has 2 columns, text and ftstext
text: "how are you"
ftstest: (nothing)
Because "how" and "are" and "you" are too common to be tsvectored. Which is
fine.
So if a user searches for "how are you":
select * from tbl_lines WHERE
ftstext @@ plainto_tsquery('English
Hi,
On 2011-10-04 20:52:59 +0900, Fujii Masao wrote:
> *** a/src/backend/access/transam/xact.c
> --- b/src/backend/access/transam/xact.c
> ***
> *** 1066,1071 RecordTransactionCommit(void)
> --- 1066,1074
>
> (void) XLogInsert(RM_XACT_ID, XLOG_XACT_CO
On Mon, Aug 11, 2014 at 4:26 PM, Fujii Masao wrote:
> On Mon, Aug 11, 2014 at 2:10 PM, Michael Paquier
> wrote:
> Oh, that worked in my machine, too, this time... I did something wrong.
> Sorry for the noise.
No problem, thanks for spending time testing.
--
Michael
--
Sent via pgsql-hackers m
On 2014-08-11 16:20:41 +0900, Fujii Masao wrote:
> On Mon, Aug 11, 2014 at 3:54 PM, Andres Freund wrote:
> > On 2014-08-11 12:42:06 +0900, Fujii Masao wrote:
> >> On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii
> >> wrote:
> >> >> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii
> >> >> wrote:
> >
On Mon, Aug 11, 2014 at 2:10 PM, Michael Paquier
wrote:
>
>
> On Mon, Aug 11, 2014 at 1:26 PM, Fujii Masao wrote:
>> Thanks for updating the patch! Again I tested the feature and found
>> something
>> wrong. I set synchronous_standby_num to 2 and started three standbys. Two
>> of
>> them are incl
On Mon, Aug 11, 2014 at 3:54 PM, Andres Freund wrote:
> On 2014-08-11 12:42:06 +0900, Fujii Masao wrote:
>> On Mon, Aug 11, 2014 at 10:48 AM, Tatsuo Ishii wrote:
>> >> On Mon, Aug 11, 2014 at 9:23 AM, Tatsuo Ishii
>> >> wrote:
>> >>> We can know the LSN of last committed WAL record on primary b
On 08/11/2014 01:19 AM, worthy7 wrote:
http://www.postgresql.org/docs/9.1/static/gin-implementation.html
"""As of PostgreSQL 9.1, NULL key values can be included in the index. Also,
placeholder NULLs are included in the index for indexed items that are NULL
or contain no keys according to extrac
55 matches
Mail list logo
