Hi KaiGai-san,
On 2015/06/27 21:09, Kouhei Kaigai wrote:
BTW, if you try newer version of postgres_fdw foreign join patch,
please provide me to reproduce the problem/
OK
Did you forget to attach the patch, or v17 is in use?
Sorry, I made a mistake. The problem was produced using v16 [1]
On Mon, Jun 29, 2015 at 3:53 PM, Vladimir Borodin wrote:
> 28 июня 2015 г., в 21:46, Heikki Linnakangas wrote:
>> I've committed the additional option to the functions in genfile.c (I
>> renamed it to "missing_ok", for clarity), and the pg_rewind changes to use
>> that option.
>
> And since it ch
On Mon, Jun 29, 2015 at 4:20 AM, Josh Berkus wrote:
> On 06/28/2015 04:36 AM, Sawada Masahiko wrote:
>> On Sat, Jun 27, 2015 at 3:53 AM, Josh Berkus wrote:
>>> On 06/26/2015 11:32 AM, Robert Haas wrote:
I think your proposal is worth considering, but you would need to fill
in a lot more
On 06/29/2015 01:12 AM, Jeff Janes wrote:
Now I'm getting a different error, with or without checksums.
ERROR: invalid page in block 0 of relation base/16384/16420
CONTEXT: automatic vacuum of table "jjanes.public.foo"
16420 is the gin index. I can't even get the page with pageinspect:
jjan
On 2015-06-25 AM 09:51, Amit Langote wrote:
>
> Peter,
>
> On 2015-06-25 AM 02:35, Peter Geoghegan wrote:
>>
>> Inheritance with triggers is a leaky abstraction, so this kind of
>> thing is always awkward. Still, UPSERT has full support for
>> *inheritance* -- that just doesn't help in this case.
On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
> #define S_UNLOCK(lock)\
> do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
barrier? Shouldn't this be a _Asm_mf()?
> which immediately raises the question of wh
On Mon, Jun 22, 2015 at 7:24 AM, Andres Freund wrote:
> It'd be very welcome to see some wider testing and review on this.
I started looking at this and doing some testing. Here is some
initial feedback:
Perhaps vac_truncate_clog needs a new name now that it does more,
maybe vac_truncate_transa
On 2015-06-29 23:54:40 +1200, Thomas Munro wrote:
> On Mon, Jun 22, 2015 at 7:24 AM, Andres Freund wrote:
> > It'd be very welcome to see some wider testing and review on this.
>
> I started looking at this and doing some testing. Here is some
> initial feedback:
>
> Perhaps vac_truncate_clog n
On Sat, Jun 27, 2015 at 5:17 PM, Jeff Janes wrote:
> This patch implements version 1.2 of contrib module pg_trgm.
>
> This supports the triconsistent function, introduced in version 9.4 of the
> server, to make it faster to implement indexed queries where some keys are
> common and some are rare.
On Sun, Jun 28, 2015 at 1:59 AM, Fabien COELHO wrote:
>
\if_ver_eq 9.2
>>>
>>>
>>> What do you thinking about it?
>>>
>>> Couldn't this kind of thing be done directly with PL/pgSQL?
>>
>>
>> you can use PL/pgSQL - but there are some limits
>>
>> * maintenance large plpgsql functions
>
>
> I
On 2015-06-29 12:11:08 +0200, Andres Freund wrote:
> On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
> > #define S_UNLOCK(lock) \
> > do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
>
> Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
> barrier? Shouldn't this be
On Wed, Mar 18, 2015 at 1:59 PM, Michael Paquier
wrote:
> Feedback is of course welcome, but note that I am not seriously
> expecting any until we get into 9.6 development cycle and I am adding
> this patch to the next CF.
I have moved this patch to CF 2015-09, as I have enough patches to
take ca
On 28 June 2015 at 17:17, Tom Lane wrote:
> Simon Riggs writes:
> > On 27 June 2015 at 15:10, Tom Lane wrote:
> >> I don't like this too much because it will fail badly if the caller
> >> is wrong about the maximum possible page number for the table, which
> >> seems not exactly far-fetched. (
Sawada Masahiko writes:
> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane wrote:
>> So let me make a radical proposal that both gets rid of the portability
>> problem and, arguably, makes the view more useful than it is today.
>> I think we should define the view as showing, not what was in the config
I have been working on to analyze different ways to reduce
the contention around ProcArrayLock. I have evaluated mainly
2 ideas, first one is to partition the ProcArrayLock (the basic idea
is to allow multiple clients (equal to number of ProcArrayLock partitions)
to perform ProcArrayEndTransaction
F.Y.I. here is the results I did on my laptop (Ubuntu 14, i7-4600U,
16GB mem, 512GB SSD). Unlike Josh, I used Unix domain sockets. In
summary:
9.4.3: 943.439840
9.4.4: 429.953953
9.4 stable as of June 30: 929.804491
So comparing with 9.4.3, 9.4.4 is 54% slow, and 9.4-stable is 1.4% slow.
I think
On 29 June 2015 at 16:27, Amit Kapila wrote:
> Thanks to Robert Haas for having discussion (offlist) about the idea
> and suggestions to improve it and also Andres Freund for having
> discussion and sharing thoughts about this idea at PGCon.
>
Weird. This patch is implemented exactly the way I
On June 29, 2015 7:02:10 PM GMT+02:00, Simon Riggs
wrote:
>On 29 June 2015 at 16:27, Amit Kapila wrote:
>
>
>> Thanks to Robert Haas for having discussion (offlist) about the idea
>> and suggestions to improve it and also Andres Freund for having
>> discussion and sharing thoughts about this ide
On 29 June 2015 at 18:11, Andres Freund wrote:
> On June 29, 2015 7:02:10 PM GMT+02:00, Simon Riggs
> wrote:
> >On 29 June 2015 at 16:27, Amit Kapila wrote:
> >
> >
> >> Thanks to Robert Haas for having discussion (offlist) about the idea
> >> and suggestions to improve it and also Andres Freun
On 06/29/2015 01:01 AM, Michael Paquier wrote:
> On Mon, Jun 29, 2015 at 4:20 AM, Josh Berkus wrote:
>> Right. Well, another reason we should be using a system catalog and not
>> a single GUC ...
>
> I assume that this takes into account the fact that you will still
> need a SIGHUP to reload pr
On Mon, Jun 29, 2015 at 7:23 AM, Merlin Moncure wrote:
> On Sat, Jun 27, 2015 at 5:17 PM, Jeff Janes wrote:
>> V1.1: Time: 1743.691 ms --- after repeated execution to warm the cache
>>
>> V1.2: Time: 2.839 ms --- after repeated execution to warm the cache
>
> Wow! I'm going to test this.
Hi,
On 2015-06-11 00:15:21 -0400, Bruce Momjian wrote:
> I have committed the first draft of the 9.5 release notes.
I'm working on integrating the suggestions I made last week to the
release notes. Would anybody mind if I start to add commit ids in
comments, similar to what Tom has done for minor
All,
Joyent confirms that the bug is fixed on SmartOS:
This is what I see:
SunOS pkgsrc-pbulk-2014Q4-1.local 5.11 joyent_20141030T081701Z i86pc
i386 i86pc
locale "is_IS.ISO8859-1": strxfrm returned 212; last modified byte at
58 (0x0)
locale "is_IS.ISO8859-1": strxfrm returned 212; last mod
Andres Freund writes:
> I'm working on integrating the suggestions I made last week to the
> release notes. Would anybody mind if I start to add commit ids in
> comments, similar to what Tom has done for minor releases, to news
> items?
+1. Helps confirm which items are meant to correspond to wh
Josh Berkus writes:
> Joyent confirms that the bug is fixed on SmartOS:
The more interesting bit of information would be *when* it was fixed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On 06/29/2015 07:20 PM, Jeff Janes wrote:
On Mon, Jun 29, 2015 at 1:37 AM, Heikki Linnakangas wrote:
Another piece of info here that might be relevant. Almost all
UPDATE_META_PAGE xlog records other than the last one have two backup
blocks. The last UPDATE_META_PAGE record only has one backup
On 6/26/15 6:09 PM, Joel Jacobson wrote:
Can't we just use the infrastructure of PostgreSQL to handle the few
megabytes of data we are talking about here? Why not just store the data
in a regular table? Why bother with special files and special data
structures? If it's just a table we want to pro
On 2015-06-29 17:05:59 -0400, Tom Lane wrote:
> +1. Helps confirm which items are meant to correspond to which commits.
That's what made me think of it.
> In case you didn't realize it already, the stuff I put into the minor
> release notes is from src/tools/git_changelog. Dunno whether we need
Andres Freund writes:
> Haven't yet thought much about the format, maybe in the style of
> git log --pretty='format:[%h] %aN [%ci]: %s' upstream/master
> I'd personally like to see the hash and the time, the rest isn't
> particularly important to me.
[ ... plays with that ... ] Hm. To keep down
On 2015-06-29 17:30:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Haven't yet thought much about the format, maybe in the style of
> > git log --pretty='format:[%h] %aN [%ci]: %s' upstream/master
> > I'd personally like to see the hash and the time, the rest isn't
> > particularly importan
Andres Freund writes:
> How about:
> git log --pretty='format:%cd [%h] %cN: %s' --date=short upstream/master
Ah yes, didn't see that option. That's definitely better. I'd still vote
for restricting it to fit in an 80-column window though.
regards, tom lane
--
Sent vi
On 2015-06-29 17:44:06 -0400, Tom Lane wrote:
> Andres Freund writes:
> > How about:
> > git log --pretty='format:%cd [%h] %cN: %s' --date=short upstream/master
>
> Ah yes, didn't see that option. That's definitely better. I'd still vote
> for restricting it to fit in an 80-column window though
Andres Freund writes:
> On 2015-06-29 17:44:06 -0400, Tom Lane wrote:
>> Ah yes, didn't see that option. That's definitely better. I'd still vote
>> for restricting it to fit in an 80-column window though.
> I don't see the benefit of truncating away the end of the commit message
> - that'll ju
On 06/29/2015 02:08 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Joyent confirms that the bug is fixed on SmartOS:
>
> The more interesting bit of information would be *when* it was fixed.
Answer: "not certain, but fixed at least 2 years ago".
--
Josh Berkus
PostgreSQL Experts Inc.
http://pge
On 2015-06-29 17:58:54 -0400, Tom Lane wrote:
> Yeah we are. The only places you'll find where we aren't formatting to 77
> or 78 columns or so are where it would require breaking SGML tags in weird
> places.
Which isn't exactly infrequent...
Anyway, how about:
format:%cd [%h] %<(8,trunc)%cN: %<
[Jumping in without catching up on entire thread. Please let me know
if these questions have already been covered.]
1. Can you change the name to something like ParallelHeapScan?
Parallel Sequential is a contradiction. (I know this is bikeshedding
and I won't protest further if you keep the name.)
On Mon, Jun 29, 2015 at 11:42 PM, Tom Lane wrote:
> Sawada Masahiko writes:
>> On Mon, Jun 29, 2015 at 12:20 AM, Tom Lane wrote:
>>> So let me make a radical proposal that both gets rid of the portability
>>> problem and, arguably, makes the view more useful than it is today.
>>> I think we shou
On Mon, Jun 29, 2015 at 2:08 PM, Heikki Linnakangas wrote:
>
> Now kill -9 postmaster, and restart. Voila, the page headers are all zeros:
>
> postgres=# select * from page_header(get_raw_page('i_foo', 0));
> lsn| checksum | flags | lower | upper | special | pagesize |
> version |
> prun
Commits b181a919 and arguably c79b6413 added bugs to
bttext_abbrev_convert() in the process of fixing some others. In the
master branch, bttext_abbrev_convert() can leak memory when the C
locale happens to be used and we must detoast, which is unacceptable
for about the same reason that it's unacce
I have a 9.5alpha1 cluster which is locked up. All the user back ends seem
to be waiting on semop, eventually on WALInsertLockAcquire.
Is there a way to use gdb to figure out who holds the lock they are waiting
for?
It is compiled with both debug and cassert.
I am hoping someone can give me rec
On Mon, Jun 29, 2015 at 5:37 PM, Jeff Janes wrote:
> Is there a way to use gdb to figure out who holds the lock they are waiting
> for?
Have you considered building with LWLOCK_STATS defined, and LOCK_DEBUG
defined? That might do it.
Otherwise, I suggest dereferencing the "l" argument to
LWLockA
On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
> On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
>> #define S_UNLOCK(lock)\
>> do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
>
> Robert, how did you choose that? Isn't _Asm_sched_fence just a compiler
> barrier? Shouldn't thi
On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
> > On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
> >> #define S_UNLOCK(lock)\
> >> do { _Asm_sched_fence(); (*(lock)) = 0; } while (0)
> >
> > Robert, how did you choose that? Is
I was going to rebase my HashAgg patch, and got some conflicts related
to the grouping sets patch. I could probably sort them out, but I think
that may be the tipping point where we want to break up nodeAgg.c into
nodeSortedAgg.c and nodeHashAgg.c, and probably a common file as well.
This would al
On Mon, Jun 29, 2015 at 1:22 PM, Simon Riggs wrote:
> Yes, I know. And we all had a long conversation about how to do it without
> waking up the other procs.
>
> Forming a list, like we use for sync rep and having just a single process
> walk the queue was the way I suggested then and previously.
On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund wrote:
> On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
>> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
>> > On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
>> >> #define S_UNLOCK(lock)\
>> >> do { _Asm_sched_fence(); (*(lock)
On 2015-06-29 22:45:49 -0400, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund wrote:
> > On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
> >> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
> >> > On 2015-06-29 00:42:53 -0400, Tom Lane wrote:
> >> >> #define S_UNLOCK(l
On Mon, Jun 29, 2015 at 6:07 PM, Josh Berkus wrote:
> On 06/29/2015 02:08 PM, Tom Lane wrote:
>> Josh Berkus writes:
>>> Joyent confirms that the bug is fixed on SmartOS:
>>
>> The more interesting bit of information would be *when* it was fixed.
>
> Answer: "not certain, but fixed at least 2 yea
On Mon, Jun 29, 2015 at 10:53 PM, Andres Freund wrote:
> On 2015-06-29 22:45:49 -0400, Robert Haas wrote:
>> On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund wrote:
>> > On 2015-06-29 22:11:33 -0400, Robert Haas wrote:
>> >> On Mon, Jun 29, 2015 at 6:11 AM, Andres Freund wrote:
>> >> > On 2015-06
Robert Haas writes:
> On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund wrote:
>> You removed a volatile at the same time, and volatile on IA64 has
>> acquire/release semantics.
> Can you explain what you mean by volatile having acquire/release
> semantics? I don't see how volatile can create a C
Jeff Davis writes:
> I was going to rebase my HashAgg patch, and got some conflicts related
> to the grouping sets patch. I could probably sort them out, but I think
> that may be the tipping point where we want to break up nodeAgg.c into
> nodeSortedAgg.c and nodeHashAgg.c, and probably a common
On Mon, Jun 29, 2015 at 10:58 PM, Tom Lane
wrote:So personally,
> I would be inclined to put back the volatile qualifier, independently of
> any fooling around with _Asm_double_magic_xyzzy calls. Or to put it
> differently: where is the evidence that removing the volatile qual is a
> good idea?
On Mon, Jun 29, 2015 at 10:52 PM, Simon Riggs wrote:
>
> On 29 June 2015 at 18:11, Andres Freund wrote:
>>
>> On June 29, 2015 7:02:10 PM GMT+02:00, Simon Riggs
wrote:
>> >On 29 June 2015 at 16:27, Amit Kapila wrote:
>> >
>> >
>> >> Thanks to Robert Haas for having discussion (offlist) about th
On Mon, Jun 29, 2015 at 7:47 PM, Peter Geoghegan wrote:
> Commits b181a919 and arguably c79b6413 added bugs to
> bttext_abbrev_convert() in the process of fixing some others. In the
> master branch, bttext_abbrev_convert() can leak memory when the C
> locale happens to be used and we must detoast,
On Mon, Jun 29, 2015 at 7:18 PM, Simon Riggs wrote:
>
> On 28 June 2015 at 17:17, Tom Lane wrote:
>>
>> I'm not sure what you consider "dire", but missing a dirty buffer
>> belonging to the to-be-destroyed table would result in the system being
>> permanently unable to checkpoint, because attempt
On Mon, Jun 29, 2015 at 5:41 AM, Amit Kapila
wrote:
>
> On Sun, Jun 28, 2015 at 9:05 PM, Tom Lane wrote:
> >
> > Amit Kapila writes:
> > > On Sat, Jun 27, 2015 at 7:40 PM, Tom Lane wrote:
> > >> I don't like this too much because it will fail badly if the caller
> > >> is wrong about the maximu
On Tue, Jun 30, 2015 at 6:25 AM, Peter Geoghegan wrote:
>
> On Mon, Jun 29, 2015 at 5:37 PM, Jeff Janes wrote:
> > Is there a way to use gdb to figure out who holds the lock they are
waiting
> > for?
>
> Have you considered building with LWLOCK_STATS defined, and LOCK_DEBUG
> defined? That might
On 30 June 2015 at 05:02, Amit Kapila wrote:
> On Mon, Jun 29, 2015 at 7:18 PM, Simon Riggs
> wrote:
> >
> > On 28 June 2015 at 17:17, Tom Lane wrote:
> >>
> >> I'm not sure what you consider "dire", but missing a dirty buffer
> >> belonging to the to-be-destroyed table would result in the syst
On Mon, Jun 29, 2015 at 11:52:26AM +1200, Thomas Munro wrote:
> On Mon, Jun 29, 2015 at 10:57 AM, Tom Lane wrote:
> > Thomas Munro writes:
> >> Just by the way, I wonder if this was that bug:
> >> https://illumos.org/issues/1594
> >
> > Oooh. Might or might not be *same* bug, but it sure looks l
On 30 June 2015 at 03:43, Robert Haas wrote:
> On Mon, Jun 29, 2015 at 1:22 PM, Simon Riggs
> wrote:
> > Yes, I know. And we all had a long conversation about how to do it
> without
> > waking up the other procs.
> >
> > Forming a list, like we use for sync rep and having just a single process
>
On Mon, Jun 29, 2015 at 11:14 PM, Simon Riggs wrote:
> What I find weird is that the discussion was so intense about
> LWLockAcquireOrWait that when someone presented a solution there were people
> that didn't notice. It makes me wonder whether large group discussions are
> worth it.
I didn't thi
On 30 June 2015 at 04:21, Amit Kapila wrote:
> Now, I would like to briefly explain how allow-one-waker idea has
> helped to improve the patch as not every body here was present
> in that Un-conference.
>
The same idea applies for marking commits in clog, for which I have been
sitting on a patc
On Mon, Jun 29, 2015 at 5:55 PM, Peter Geoghegan wrote:
> On Mon, Jun 29, 2015 at 5:37 PM, Jeff Janes wrote:
> > Is there a way to use gdb to figure out who holds the lock they are
> waiting
> > for?
>
> Have you considered building with LWLOCK_STATS defined, and LOCK_DEBUG
> defined? That might
On Tue, Jun 30, 2015 at 11:53 AM, Simon Riggs wrote:
>
> On 30 June 2015 at 04:21, Amit Kapila wrote:
>
>>
>> Now, I would like to briefly explain how allow-one-waker idea has
>> helped to improve the patch as not every body here was present
>> in that Un-conference.
>
>
> The same idea applies f
On Tue, Jun 30, 2015 at 11:00 AM, Simon Riggs wrote:
>
> On 30 June 2015 at 05:02, Amit Kapila wrote:
>>
>> On Mon, Jun 29, 2015 at 7:18 PM, Simon Riggs
wrote:
>> >
>> > On 28 June 2015 at 17:17, Tom Lane wrote:
>> >>
>> > If lseek fails badly then SeqScans would give *silent* data loss,
which
On 30 June 2015 at 07:30, Amit Kapila wrote:
> Sure and I think we might want to try something similar even
> for XLogFlush where we use LWLockAcquireOrWait for
> WALWriteLock, not sure how it will workout in that case as
> I/O is involved, but I think it is worth trying.
>
+1
--
Simon Riggs
On 30 June 2015 at 07:34, Amit Kapila wrote:
> On Tue, Jun 30, 2015 at 11:00 AM, Simon Riggs
> wrote:
> >
> > On 30 June 2015 at 05:02, Amit Kapila wrote:
> >>
> >> On Mon, Jun 29, 2015 at 7:18 PM, Simon Riggs
> wrote:
> >> >
> >> > On 28 June 2015 at 17:17, Tom Lane wrote:
> >> >>
> >> > If
67 matches
Mail list logo
