Noah Misch writes:
> On Tue, Apr 02, 2019 at 10:09:00AM -0400, Tom Lane wrote:
>> I worry that your proposed fix is unstable, in particular this assumption
>> seems shaky:
>>> + * ... The idea is that, if the allocator handed out
>>> + * REGION1 pages before REGION2 pages at one occasion, it will
On Tue, Apr 02, 2019 at 10:09:00AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I can reproduce the 4 MiB allocations described
> > in https://postgr.es/m/29823.1525132...@sss.pgh.pa.us; a few times per
> > "vcregress check", they emerge in the middle of PGSharedMemoryReAttach().
> > The 4 MiB
Hi,
Please find the proposed patch for review. I will attach it to commitfest
as well
Regards,
Ram.
windows_service_bug_fix_v2.patch
Description: Binary data
On Sat, Apr 06, 2019 at 05:56:24PM -0400, Tom Lane wrote:
> This patch had bit-rotted due to somebody else fooling with the
> volatile-qualifiers situation. I fixed it up, tweaked a couple of
> things, and pushed it.
Thanks, Tom!
--
Michael
signature.asc
Description: PGP signature
On Sat, Apr 6, 2019 at 3:18 AM Michael Paquier wrote:
>
> On Fri, Apr 05, 2019 at 09:10:31AM -0400, Andrew Dunstan wrote:
> > Well, that would be a bit sad. ISTM if we conclude that the current
> > behaviour is a bug we could commit the current patch and backpatch a
> > fix to honor a lower
On Sun, Apr 7, 2019 at 2:37 AM Tom Lane wrote:
> Alexander Korotkov writes:
> > Thus, contents of unused function makes test fail or pass. So far, it
> > looks like a compiler bug. Any thoughts?
>
> Yeah :-(. The fact that we've not seen a similar failure on any other
> machines points in
Alexander Korotkov writes:
> Thus, contents of unused function makes test fail or pass. So far, it
> looks like a compiler bug. Any thoughts?
Yeah :-(. The fact that we've not seen a similar failure on any other
machines points in that direction, too. Maybe it's some other aspect
of the
Hi Surafel,
I've been looking at the patch with the intent to commit it, but once
again I ran into stuff that seems suspicious to me but am not familiar
with enough to say if it's OK. I'm sorry about that :-(
First, a couple of tweaks in the attached v9 of the patch:
1) I've removed the
Michael Paquier writes:
> On Wed, Mar 06, 2019 at 11:04:23AM +0900, Michael Paquier wrote:
>> Another thing is that you cannot just return within a try block with
>> what is added in PLyObject_FromJsonbContainer, or the error stack is
>> not reset properly. So they should be replaced by breaks.
On 4/6/19 3:18 AM, Andres Freund wrote:
Given nothing happened since then I think we ought to mark this as
returned with feedback? Will do so tomorrow.
Agreed, marked as Returned with Feedback.
Regards,
--
-David
da...@pgmasters.net
On 2019-02-28 11:05:33 +0200, David Steele wrote:
The 2019-03 CF is almost upon us. The CF will officially start at 00:00 AoE
(12:00 UTC) on Friday, March 1st.
I'd like to move all the CF entries targeting v13 at this time. We might
get a patch or five more committed in the next two days, but
This test script works fine in HEAD:
drop table if exists parttbl cascade;
CREATE TABLE parttbl (a int, b int) PARTITION BY LIST (a);
CREATE TABLE parttbl_1 PARTITION OF parttbl FOR VALUES IN (NULL,500,501,502);
UPDATE parttbl SET a = NULL, b = NULL WHERE a = 1600 AND b = 999;
In v11, it suffers
Hadi Moshayedi writes:
> [ fix-foreign-key-check.patch ]
Pushed with some adjustments, as discussed over at
https://postgr.es/m/19030.1554574...@sss.pgh.pa.us
> This patch also changed the output of some of tests, i.e. previously
> foreign key constraint failures errored on the partitioned
so 6. 4. 2019 v 6:36 odesílatel Alvaro Herrera
napsal:
> On 2019-Apr-05, Alvaro Herrera wrote:
>
> > Looking at the current proposal, I think I like \dPn+ very much -- it
> > shows the aggregated size of all partitioned tables. But I think \dP
> > (without the +) is almost completely useless.
Andres Freund writes:
> On 2019-04-06 14:34:34 -0400, Tom Lane wrote:
>> These are good questions. Just eyeing RI_FKey_check(), I think
>> that it might not have any significant leaks because most of the work
>> is done in an SPI context, but obviously that's pretty fragile.
> Yea. And
Andres Freund writes:
> On 2019-04-06 14:34:34 -0400, Tom Lane wrote:
>> Why should this code need to free anything? That'd be the responsibility
>> of the slot code, no?
> Well, not really. If a slot doesn't hold heap tuples internally,
> ExecFetchSlotHeapTuple() will return a fresh heap tuple
Hi,
On 2019-04-06 14:34:34 -0400, Tom Lane wrote:
> Andres Freund writes:
> > The relevant thread is:
> > https://www.postgresql.org/message-id/20190325180405.jytoehuzkeozggxx%40alap3.anarazel.de
>
> Yeah, I just found that --- would have seen it sooner if David had
> not elected to make it a
Andres Freund writes:
> The relevant thread is:
> https://www.postgresql.org/message-id/20190325180405.jytoehuzkeozggxx%40alap3.anarazel.de
Yeah, I just found that --- would have seen it sooner if David had
not elected to make it a new thread.
> Wonder if you have an opinion on:
>> I've also
Hi,
On 2019-04-06 14:13:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On April 6, 2019 11:07:55 AM PDT, Tom Lane wrote:
> >> I plan to go ahead and commit Hadi's fix with that change included
> >> (as below), but I wonder whether anything else needs to be revisited.
>
> > I posted
Andres Freund writes:
> On April 6, 2019 11:07:55 AM PDT, Tom Lane wrote:
>> I plan to go ahead and commit Hadi's fix with that change included
>> (as below), but I wonder whether anything else needs to be revisited.
> I posted pretty much that patch nearby, with some other questions. Was
>
Hi,
On April 6, 2019 11:07:55 AM PDT, Tom Lane wrote:
>It seems that the fire-the-triggers code path in
>validateForeignKeyConstraint isn't being exercised; at least, that's
>what coverage.postgresql.org says right now, and I'm afraid that may
>have been true for quite some time. The attached
It seems that the fire-the-triggers code path in
validateForeignKeyConstraint isn't being exercised; at least, that's
what coverage.postgresql.org says right now, and I'm afraid that may
have been true for quite some time. The attached regression-test
addition causes it to be exercised, and guess
Jose Luis Tallon writes:
> While working on an application, the need arose to be able
> efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
> others)
> ... so please find attached a trivial patch which adds the
> functionality.
No particular objection...
> I'm
Hello devs,
the attached patch adds some more control on the initialization phase.
In particular, ( and ) allow to begin/commit explicitely, and G generates
the data server-side instead of client side, which might be a good idea
depending on the available bandwidth.
Together with the
Hello devs,
The attached patch adds minimal stats during the initialization phase.
Such a feature was already submitted by Doug Rady two years ago,
https://commitfest.postgresql.org/15/1308/
but it needed to be adapted to the -I custom initialization approach
developed in the same
=?UTF-8?Q?Filip_Rembia=C5=82kowski?= writes:
> Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
> I see it's not backward-compatible, but in my understanding that's
> what is documented. Previous behavior was inconsistent with
> documentation (where single asterisk
On Fri, Apr 5, 2019 at 3:28 PM Robert Haas wrote:
>
> On Fri, Apr 5, 2019 at 2:11 PM Julien Rouhaud wrote:
> > > My preference is for "truncate" over "shrink".
> >
> > I don't really like "shrink" either, but users already have problems
> > to get the difference between VACUUM and VACUUM FULL,
Robert Haas wrote:
> On Fri, Apr 5, 2019 at 11:22 AM Antonin Houska wrote:
> > > Wouldn't Tom's proposal to use a stream cipher fix all this?
> >
> > Yes it would make the extra alignment unnecessary, but our solution tries to
> > meet specific requirements of disk encryption. Stream cipher
Tom Lane wrote:
> > PFA a new version adding the clause for only 12 and up, since the
> > previous versions are not concerned, and as you mention, really old
> > versions would fail otherwise.
>
> Pushed with some fiddling with the comments, and changing the collation
> names to be
Hackers,
While working on an application, the need arose to be able
efficiently differentiate v4/v5 UUIDs (for use in partial indexes, among
others)
... so please find attached a trivial patch which adds the
functionality. The "uuid_version_bits()" function (from the test suite?)
seems
Hi
When using a functional index on a table, we realized that the permission
check done in pg_stats was incorrect and thus preventing valid access to the
statistics from users.
How to reproduce:
create table tbl1 (a integer, b integer);
insert into tbl1 select x, x % 50 from
В письме от воскресенье, 24 февраля 2019 г. 14:31:55 MSK пользователь Dmitry
Belyavsky написал:
Hi! Am back here again.
I've been thinking about this patch a while... Come to some conclusions and
wrote some examples...
First I came to idea that the best way to simplify the code is change the
Hi Andres,
I’m just about to board a plane for the rest of the day. I can do that when I
get home tonight or anyone else is welcome to do so. If I can get internet on
the flight I’ll do it myself but I have not had much luck with that recently.
Regards,
--
- David
> On Apr 6, 2019, at
On Sat, Apr 6, 2019 at 2:45 AM David Rowley
wrote:
>
> On Sat, 6 Apr 2019 at 12:26, Tom Lane wrote:
> > Pushed with some hacking, mostly trying to improve the comments.
>
> Great! Many thanks for improving those and pushing it.
>
> Many thanks to Julien, Antonin for their detailed reviews on
>
> The invoking autovacuum on table based on inserts, not only deletes
> and updates, seems good idea to me. But in this case, I think that we
> can not only freeze tuples but also update visibility map even when
> setting all-visible. Roughly speaking I think vacuum does the
> following
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
I have read disable-vacuum-truncation_v6.patch.
I like it the way it is.
Yes, it is a different project, and we cannot run it on top of PostgreSQL
directly.
Maybe we can learn from it by:
1. Study its benchmark. The benchmark used is YCSB [1], and maybe we can
generate data and run queries in a similar way as YCSB in our project. YCSB
already discussed the order to
On Fri, Apr 05, 2019 at 09:10:31AM -0400, Andrew Dunstan wrote:
> Well, that would be a bit sad. ISTM if we conclude that the current
> behaviour is a bug we could commit the current patch and backpatch a
> fix to honor a lower toast_tuple_threshold. But yes, time is tight.
48 hours remain, which
On Sat, Apr 06, 2019 at 11:31:31AM +0900, Masahiko Sawada wrote:
> Yes, but Fujii-san pointed out that this option doesn't support toast
> tables and I think there is not specific reason why not supporting
> them. So it might be good to add toast.vacuum_index_cleanup. Attached
> patch.
Being able
On Fri, Apr 05, 2019 at 07:34:48AM +, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:mich...@paquier.xyz]
>> The first letter should be upper-case.
>
> Thank you for taking care of this patch, and sorry to cause you
> trouble to fix that...
I have just committed the GUC and
40 matches
Mail list logo
