While looking at some of the recent churn in DSA I noticed that
dsa_size_class_map should probably be declared const.
diff --git a/src/backend/utils/mmgr/dsa.c b/src/backend/utils/mmgr/dsa.c
index 33ab8d05d3..70ce7ce7da 100644
--- a/src/backend/utils/mmgr/dsa.c
+++ b/src/backend/utils/mmgr/dsa.c
@@
Hi, hackers!
Here's the patch with amcheck functionality for GiST.
It basically checks two invariants:
1. Every internal tuple need no adjustment by tuples of referenced page
2. Internal page reference or only leaf pages or only internal pages
We actually cannot check all balanced tree invariant
Hi,
Attached is a patch that fixes a bug
for miscounting total number of curly braces in output string in array_out.
Example1
{{1,2,3},{4,5,6}} -> dims[0] = 2, dims[1]= 3
- Without the patch
8
- After
3
Example2
N size one-dimensional array -> dim
On Wed, Sep 19, 2018 at 1:16 PM Stephen Frost wrote:
> * Thomas Munro (thomas.mu...@enterprisedb.com) wrote:
> > On Wed, Sep 19, 2018 at 10:09 AM Stephen Frost wrote:
> > > * Douglas Doole (dougdo...@gmail.com) wrote:
> > > > > The CHECK constraint doesn't need to directly track that information-
Andres Freund writes:
> Have there been discussions about the security effects of this change?
> Previously the server admin could control the timeout, which could
> affect things like syncrep, after this it's not possible anymore. I
> *think* that's ok, but it should be discussed.
Hm. An evil
On 09/22/2018 12:46 PM, Andrew Dunstan wrote:
In the interest of advancing $subject, I recently started a little
skunkworks project to get old postgres running on modern systems so we
could test if we'd broken backwards compatibility somehow. This was
given a fillip a few days ago when my
On Fri, Aug 24, 2018 at 5:50 AM Andres Freund wrote:
> I've pushed a current version of that to my git tree to the
> pluggable-storage branch. It's not really a version that I think makese
> sense to review or such, but it's probably more useful if you work based
> on that. There's also the plugg
Andrew Gierth writes:
> Normally I'd push hard to try and get some solution that's sufficiently
> generic to allow user-defined functions to make use of the feature. But
> I think the SQL spec people have managed to make that literally
> impossible in this case, what with the FROM keyword appearin
Mark G writes:
> While looking at some of the recent churn in DSA I noticed that
> dsa_size_class_map should probably be declared const.
+1 ... also, given the contents of the array, "char" seems like
rather a misnomer. I'd be happier if it were declared as uint8, say.
r
On Tue, Sep 18, 2018 at 7:57 AM Douglas Doole wrote:
> On Mon, Sep 17, 2018 at 12:32 PM Greg Stark wrote:
>> This seems like a terrible idea in the open source world. Surely collation
>> versioning means new ICU libraries can still provide the old collation rules
>> so even if you update the li
On 09/03/2018 04:08 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 08/17/2018 11:23 PM, Tom Lane wrote:
>>> Yeah, we've definitely hit such problems before. The geometric logic
>>> seems particularly prone to it because it's doing more and subtler
>>> float arithmetic than the rest of the syste
> "Tom" == Tom Lane writes:
Tom> The FROM FIRST/LAST bit seems particularly badly thought through,
Tom> because AFAICS it is flat out ambiguous with a normal FROM clause
Tom> immediately following the window function call. The only way to
Tom> make it not so would be to make FIRST and LAS
On Mon, Jul 2, 2018 at 12:39 PM Thomas Munro
wrote:
> On Sat, Mar 3, 2018 at 2:11 AM, Adam Brusselback
> wrote:
> > Thanks Thomas, appreciate the rebase and the work you've done on this.
> > I should have some time to test this out over the weekend.
>
> Rebased.
Rebased.
--
Thomas Munro
http:/
On Sun, Sep 23, 2018 at 10:47:44AM -0400, Tom Lane wrote:
> Andres Freund writes:
>> Have there been discussions about the security effects of this change?
>> Previously the server admin could control the timeout, which could
>> affect things like syncrep, after this it's not possible anymore. I
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The FROM FIRST/LAST bit seems particularly badly thought through,
> Tom> because AFAICS it is flat out ambiguous with a normal FROM clause
> Tom> immediately following the window function call. The only way to
> Tom> make it not so woul
On Thu, Sep 20, 2018 at 09:51:34PM +0900, Masahiko Sawada wrote:
> I agreed with your all review comments. Attached the updated patch.
Wouldn't it be better to incorporate the new test as part of
004_restart.pl? This way, we avoid initializing a full instance, which
is always a good thing as that
> "Tom" == Tom Lane writes:
Tom> If you just think of recognizing FROM FIRST/LAST, you get nowhere
Tom> because that's still legal in other contexts. But if you were to
Tom> look for FROM followed by FIRST/LAST followed by
Tom> IGNORE/RESPECT/OVER, I think that could only validly happen i
On Fri, Sep 21, 2018 at 12:35:46PM +0200, Chris Travers wrote:
> I understand how lock levels don't fit a simple hierarchy but at least
> when it comes to what is going to be aborted on a signal, I am having
> trouble understanding the problem here.
It may be possible to come with a clear hierarch
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> If you just think of recognizing FROM FIRST/LAST, you get nowhere
> Tom> because that's still legal in other contexts. But if you were to
> Tom> look for FROM followed by FIRST/LAST followed by
> Tom> IGNORE/RESPECT/OVER, I think that c
> "Tom" == Tom Lane writes:
>> select nth_value(x) from first ignore;
Tom> No, because once IGNORE is a keyword, even unreserved, it's not
Tom> legal as an AS-less alias.
That rule only applies in the select-list, not in the FROM clause; table
aliases in FROM are just ColId, so they can
On Mon, Sep 24, 2018 at 9:32 AM Tom Lane wrote:
> Mark G writes:
> > While looking at some of the recent churn in DSA I noticed that
> > dsa_size_class_map should probably be declared const.
>
> +1 ... also, given the contents of the array, "char" seems like
> rather a misnomer. I'd be happier i
[spawning a new thread]
In commit 25fff40798 the execute permission of pg_stat_statements_reset()
is provided to pg_read_all_stats role in [1].
The execute permissions grant to pg_read_all_stats concern is raised in [2]
during the discussion of supporting different methods of reset the stats,
ins
On Sat, Sep 22, 2018 at 11:23 PM Amit Kapila
wrote:
> On Mon, Jul 9, 2018 at 11:28 AM Haribabu Kommi
> wrote:
> >
> > On Mon, Jul 9, 2018 at 3:39 PM Haribabu Kommi
> wrote:
> >>
> >>
> >> On Mon, Jul 9, 2018 at 12:24 PM Michael Paquier
> wrote:
> >>>
> >>> On Fri, Jul 06, 2018 at 05:10:18PM -0
On Mon, Sep 24, 2018 at 11:13 AM Haribabu Kommi
wrote:
> On Sat, Sep 22, 2018 at 11:23 PM Amit Kapila
> wrote:
>
>> On Mon, Jul 9, 2018 at 11:28 AM Haribabu Kommi
>> wrote:
>> >
>> > On Mon, Jul 9, 2018 at 3:39 PM Haribabu Kommi
>> wrote:
>> >>
>> >>
>> >> On Mon, Jul 9, 2018 at 12:24 PM Micha
On Sun, Sep 23, 2018 at 10:15 PM Andrey Borodin wrote:
> Here's the patch with amcheck functionality for GiST.
Hi Andrey,
Windows doesn't like it[1]:
contrib/amcheck/verify_gist.c(163): error C2121: '#' : invalid
character : possibly the result of a macro expansion
[C:\projects\postgresql\amche
On 2018-09-24 15:29:38 +1200, Thomas Munro wrote:
> On Sun, Sep 23, 2018 at 10:15 PM Andrey Borodin wrote:
> > Here's the patch with amcheck functionality for GiST.
>
> Hi Andrey,
>
> Windows doesn't like it[1]:
>
> contrib/amcheck/verify_gist.c(163): error C2121: '#' : invalid
> character : po
On Mon, Sep 24, 2018 at 5:02 AM Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Aug 24, 2018 at 5:50 AM Andres Freund wrote:
> > I've pushed a current version of that to my git tree to the
> > pluggable-storage branch. It's not really a version that I think makese
> > sense to re
Hi!
> 24 сент. 2018 г., в 8:29, Thomas Munro
> написал(а):
>
> On Sun, Sep 23, 2018 at 10:15 PM Andrey Borodin wrote:
>> Here's the patch with amcheck functionality for GiST.
>
> Hi Andrey,
>
> Windows doesn't like it[1]:
Thanks, Thomas! Yes, I've missed that version-dependent macro. Surely
On Wed, Sep 19, 2018 at 01:03:44PM +0900, Kyotaro HORIGUCHI wrote:
> Thank you for finding and fixing this.
>
> At Sat, 15 Sep 2018 18:21:52 -0400, Tom Lane wrote in
> <1.1537050...@sss.pgh.pa.us>
> > Noah Misch writes:
> > > Usually, the first srandom() call happens early in PostmasterMain
29 matches
Mail list logo