On Fri, Oct 26, 2018 at 1:12 PM Amit Langote
wrote:
>
> On 2018/10/25 19:54, Dilip Kumar wrote:
> > On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote:
> >> Amit Langote writes:
> >>> But maybe for the case under question, that's irrelevant, because
> >>> we're only interested in access to
On Sat, Oct 27, 2018 at 10:03 AM Thomas Munro
wrote:
> space-vs-collision trade-off. If I have my maths right[1], with 0.75
> you expect to have 75 entries in ~53 buckets, but with 1.0 you expect
> to have 100 entries in ~64 buckets. It'd be a fair criticism that
Forgot to add: assuming 100
On Sat, Oct 27, 2018 at 12:30 AM Antonin Houska wrote:
> 1. The return type of resize() function is void, so I propose part of the
> header comment to be removed:
>
> diff --git a/src/backend/lib/dshash.c b/src/backend/lib/dshash.c
> index b46f7c4cfd..b2b8fe60e1 100644
> ---
On Tue, Oct 23, 2018 at 10:51 AM Andres Freund wrote:
> On 2018-10-23 13:54:31 +0200, Fabien COELHO wrote:
> >
> > Hello Tom & Amit,
> >
> > > > > Both animals use gcc experimental versions, which may rather
> underline a
> > > > > new bug in gcc head rather than an existing issue in pg. Or not.
Michael Paquier writes:
> On Fri, Oct 26, 2018 at 09:08:13PM +0900, Michael Paquier wrote:
>> I didn't think that this was much of a big deal as the deprecated
>> grammar is still supported on v11, but as both of you think in this
>> sense I am fine to patch REL_11_STABLE as well. Please just
Good morning,
First of all thanks for helping me ,
We have postgres running in 8.4.22, We have back up from 8.3.7
When I try to restore, All the tables are not restored, almost 60% of the
tables not exist, Failed with the following errors.
Any help on this much appreciated.
I am using the
On Fri, Oct 26, 2018 at 13:44:07 +0100,
Tom Lane wrote:
Bruno Wolff III writes:
As a short term work around, could I create the index first and use
insert statements, each in their own transaction, to get the table loaded
with the index?
Yes; it might also be that you don't even need to
On Fri, Oct 26, 2018 at 09:08:13PM +0900, Michael Paquier wrote:
> I didn't think that this was much of a big deal as the deprecated
> grammar is still supported on v11, but as both of you think in this
> sense I am fine to patch REL_11_STABLE as well. Please just wait a
> bit...
Done for the
Alvaro Herrera writes:
> On 2018-Oct-26, Tom Lane wrote:
>> After a quick look around, I think that making systable_begin/endscan
>> do this is a nonstarter; there are just too many call sites that would
>> be affected. Now, you could imagine specifying that indexes on system
>> catalogs (in
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> A related issue is whether we should change pg_get_triggerdef() to emit
> the new syntax as well (in HEAD only, since it would break things that
> parse the output).
No, because pg_get_triggerdef() does not know what its
On 2018-Oct-26, Tom Lane wrote:
> After a quick look around, I think that making systable_begin/endscan
> do this is a nonstarter; there are just too many call sites that would
> be affected. Now, you could imagine specifying that indexes on system
> catalogs (in practice, only btree) have to
Hello,
This is a follow-up to another patch I posted about libpq confusing
documentation & psql resulting behavior under host/hostaddr settings.
Although the first mostly documentation patch did not gather much
enthousiasm, I still think both issues deserve a fix.
About updating psql's
Dear hackers,
This is my first try to post on that list to propose a workaround on an
issue I noticed while using pg_waldump. Each time an object is referenced
by "oids" following output template :
tablespace oid/database oid/relfilenodeid
That template seems to be used for each operation but
Tom Lane writes:
> Michael Paquier writes:
>> On Fri, Oct 26, 2018 at 09:31:48AM +0900, Michael Paquier wrote:
>>> Committed 0001 now which adds tab completion for CREATE TRIGGER.
>
>> And 0002 is committed as well. Thanks for the patches!
>
> The committed patches look sane to me, but should
On 2018-Oct-26, David Rowley wrote:
> For a long time, we documented our table size, max columns, max column
> width limits, etc. in https://www.postgresql.org/about/ , but that
> information seems to have now been removed. The last version I can
> find with the information present is back in
Bruno Wolff III writes:
> Tom Lane wrote:
>> Hmm, in my hands this produces the same size leak (~28GB) in either v10
>> or v11. In HEAD, somebody's made it even worse (~43GB). So this is
>> certainly pretty broken, but I'm not sure why it seems worse to you in
>> v11 than before.
> As a
On Fri, Oct 26, 2018 at 11:15:19AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Tom Lane writes:
>> The committed patches look sane to me, but should we back-patch into 11?
>> This isn't quite a bug fix maybe, but it's inconsistent if v11 server &
>> docs recommend this syntax while v11 psql doesn't
1. The return type of resize() function is void, so I propose part of the
header comment to be removed:
diff --git a/src/backend/lib/dshash.c b/src/backend/lib/dshash.c
index b46f7c4cfd..b2b8fe60e1 100644
--- a/src/backend/lib/dshash.c
+++ b/src/backend/lib/dshash.c
@@ -672,9 +672,7 @@
On Fri, Oct 26, 2018 at 10:16:09 +0100,
Tom Lane wrote:
Bruno Wolff III writes:
I have something that seems to produce it on rhel7. Fedora isn't working
well either, but the difference may be due to postgresql.conf being
different or some difference in the Fedora build.
Hmm, in my hands
On Tue, Oct 23, 2018 at 6:11 PM Haribabu Kommi
wrote:
>
> On Tue, Oct 23, 2018 at 5:49 PM Haribabu Kommi
> wrote:
>
>> I am able to generate the simple test and found the problem. The issue
>> with the following
>> SQL.
>>
>> SELECT *
>>INTO TABLE xacttest
>>FROM aggtest;
>>
>> During
Hi,
On Fri, Oct 26, 2018 at 6:40 AM David Rowley
wrote:
>
> On 26 October 2018 at 16:52, Amit Langote
> wrote:
> > I recall Ronan Dunklau and Julien Rouhaud had proposed a patch for this
> > last year, but the partitioning-related planning code hadn't advanced then
> > as much as it has today,
On Fri, Oct 26, 2018 at 9:09 AM 임명규 wrote:
> Hello,
>
> I want test this patch, but can't apply it.
>
> (master)$ git apply copy_from_when_con_v1.patch
>
i use patch and it work
try (master)$ patch -p1 < copy_from_when_con_v1.patch
regards
Surafel
hello ,
The WITH TIES keyword is sql standard that specifies any peers of retained
rows
to retained in the result set too .which means according to ordering key
the result set can includes additional rows which have ties on the last
position, if there are any and It work with ORDER BY query
The
Amit Langote writes:
> On 2018/10/26 18:59, Tom Lane wrote:
>> After a quick look around, I think that making systable_begin/endscan
>> do this is a nonstarter; there are just too many call sites that would
>> be affected. Now, you could imagine specifying that indexes on system
>> catalogs (in
Tom Lane writes:
> Michael Paquier writes:
>> On Fri, Oct 26, 2018 at 09:31:48AM +0900, Michael Paquier wrote:
>>> Committed 0001 now which adds tab completion for CREATE TRIGGER.
>
>> And 0002 is committed as well. Thanks for the patches!
Thanks for reviewing and committing!
> The
On 2018/10/26 18:59, Tom Lane wrote:
> Amit Langote writes:
>> On 2018/10/26 18:16, Tom Lane wrote:
>>> A quick review of the other index AM endscan methods seems to indicate
>>> that they all try to clean up their mess. So maybe we should just make
>>> spgendscan do likewise. Alternatively, we
Michael Paquier writes:
> On Fri, Oct 26, 2018 at 09:31:48AM +0900, Michael Paquier wrote:
>> Committed 0001 now which adds tab completion for CREATE TRIGGER.
> And 0002 is committed as well. Thanks for the patches!
The committed patches look sane to me, but should we back-patch into 11?
This
Amit Langote writes:
> On 2018/10/26 18:16, Tom Lane wrote:
>> A quick review of the other index AM endscan methods seems to indicate
>> that they all try to clean up their mess. So maybe we should just make
>> spgendscan do likewise. Alternatively, we could decide that requiring
>> endscan
On 2018/10/26 18:16, Tom Lane wrote:
> The core of the problem I see is that check_exclusion_or_unique_constraint
> does index_beginscan/index_rescan/index_endscan in a long-lived context,
> while spgendscan seems to have employed dice while deciding which of
> spgbeginscan's allocations it would
Bruno Wolff III writes:
> I have something that seems to produce it on rhel7. Fedora isn't working
> well either, but the difference may be due to postgresql.conf being
> different or some difference in the Fedora build.
Hmm, in my hands this produces the same size leak (~28GB) in either v10
On 2018/10/25 19:54, Dilip Kumar wrote:
> On Mon, Oct 22, 2018 at 7:47 PM Tom Lane wrote:
>> Amit Langote writes:
>>> But maybe for the case under question, that's irrelevant, because
>>> we're only interested in access to inherited columns as those are the
>>> only ones that can be accessed in
Hello Robert,
[...] that's a self-inflicted injury.
Sure. I'm trying to be more user friendly.
It's not that I am opposed to helping people avoid self-inflicted
injuries, but this one doesn't seem either likely or serious.
If I'm trying to improve something, I tend to be thorough about
On 26.10.2018 10:33, Kyotaro HORIGUCHI wrote:
Hello.
At Tue, 23 Oct 2018 10:25:27 +0500, Andrey Lepikhov wrote
in <2553f2b0-0e39-eb0e-d382-6c0ed08ca...@postgrespro.ru>
On 23.10.2018 0:53, Heikki Linnakangas wrote:
I'd expect the decompression to read from the on-disk buffer, and
unpack
Hello,
I want test this patch, but can't apply it.
(master)$ git apply copy_from_when_con_v1.patch
error: patch failed: src/backend/commands/copy.c:849
error: src/backend/commands/copy.c: patch does not apply
fix or another way, let me know.
Best regards,
Myungkyu, Lim
34 matches
Mail list logo
