On Wed, Sep 2, 2020 at 7:35 AM Andres Freund wrote:
> Hi,
>
> on a regular basis I remember a builtin function's name, or can figure it
> out
> using \df etc, but can't remember the argument order. A typical example is
> regexp_*, where I never remember whether the pattern or the input string
> c
On Wed, Sep 2, 2020 at 9:13 AM Oleksandr Shulgin
wrote:
>
> On Wed, Sep 2, 2020 at 7:35 AM Andres Freund wrote:
>>
>> Hi,
>>
>> on a regular basis I remember a builtin function's name, or can figure it out
>> using \df etc, but can't remember the argument order. A typical example is
>> regexp_*,
On 02/09/2020 19:15, Julien Rouhaud wrote:
On Wed, Sep 2, 2020 at 9:13 AM Oleksandr Shulgin
wrote:
On Wed, Sep 2, 2020 at 7:35 AM Andres Freund wrote:
Hi,
on a regular basis I remember a builtin function's name, or can figure it out
using \df etc, but can't remember the argument order. A typ
Hi
On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost wrote:
> Greetings,
>
> * Dave Page (dp...@pgadmin.org) wrote:
> > Attached is a patch against 12.4 for the build system in case anyone
> wants
> > to play (I'll do it properly against the head branch later). I'm guessing
> > this will work for < 1
On Tue, Sep 01, 2020 at 10:27:31AM +, Georgios wrote:
> On Tuesday, 1 September 2020 07:41, Michael Paquier
> wrote:
>> Adding \dE as there are no foreign tables does not make much sense,
>> and also I wondered why \dt+ was not added.
>>
>> Does the attached look correct to you?
>
> You have
Not related to DETACH PARTITION, but I found a bug in ATTACH PARTITION.
Here are the steps to reproduce the issue:
create table tpart(i int, j int) partition by range(i);
create table tpart_1(like tpart);
create table tpart_2(like tpart);
create table tpart_default(like tpart);alter table tpart a
>
>
>
> On the other hand, it looks appealing to make index_set_state_flags()
> transactional. This would solve the consistency problem, and looking
> at the code scanning pg_index, I don't see a reason why we could not
> do that. What do you think?
>
TBH, I am not sure. I think it is a reasona
On Tue, Sep 01, 2020 at 03:44:06PM +0200, Daniel Gustafsson wrote:
> Well, I was thinking less technically accurate and more descriptive for end
> users, hiding the implementation details. "Rewrite" sounds to me more like
> changing data rather than amending pages with a checksum keeping data inta
On Tue, Sep 1, 2020 at 10:00 PM Mark Dilger
wrote:
>
> Some changes were made on another thread [1] for the deprecation notices,
> committed recently by Tom, and I think this patch set is compatible with what
> was done there. This patch set is intended for commit against master,
> targeted fo
On Wed, Sep 2, 2020 at 9:17 AM Tom Lane wrote:
>
> Amit Kapila writes:
> > Even if the relation is locked, background processes like checkpointer
> > can still touch the relation which might cause problems. Consider a
> > case where we extend the relation but didn't flush the newly added
> > page
+/* --
+ * Backend types
+ * --
You seem to forget to add "*/" into the above comment.
This issue could cause the following compiler warning.
../../src/include/pgstat.h:761:1: warning: '/*' within block comment
[-Wcomment]
Thanks for the comment. I fixed.
The contents of pg_s
On Tue, Sep 1, 2020 at 8:33 PM Amit Kapila wrote:
>
> On Tue, Sep 1, 2020 at 9:28 AM Amit Kapila wrote:
> >
> > On Mon, Aug 31, 2020 at 7:28 PM Dilip Kumar wrote:
> > >
> > > On Mon, Aug 31, 2020 at 1:24 PM Amit Kapila
> > > wrote:
> >
> > In functions cleanup_rel_sync_cache and
> > get_schema
On Wed, Sep 2, 2020 at 4:57 AM Mark Dilger wrote:
>
>
>
> > On Aug 13, 2020, at 4:48 AM, Dilip Kumar wrote:
> >
> > v1-0001: As suggested by Robert, it provides the syntax support for
> > setting the compression method for a column while creating a table and
> > adding columns. However, we don't
On Mon, Aug 31, 2020 at 10:45 AM Amit Khandekar wrote:
>
> On Thu, 13 Aug 2020 at 17:18, Dilip Kumar wrote:
> > I have rebased the patch on the latest head and currently, broken into 3
> > parts.
> >
> > v1-0001: As suggested by Robert, it provides the syntax support for
> > setting the compress
Hi all,
$subject has been mentioned a couple of times, including today:
https://www.postgresql.org/message-id/20200902010012.ge1...@paquier.xyz
We have a boolean argument in ReindexStmt to control a concurrent
run, and we also have in parallel of that a bitmask to control the
options of the state
On Wed, Sep 2, 2020 at 1:03 PM Michael Paquier wrote:
>
> Hi all,
>
> $subject has been mentioned a couple of times, including today:
> https://www.postgresql.org/message-id/20200902010012.ge1...@paquier.xyz
>
> We have a boolean argument in ReindexStmt to control a concurrent
> run, and we also h
> 31 авг. 2020 г., в 16:57, Pavel Borisov написал(а):
>
> I agree with all of your proposals and integrated them into v9.
I have a wild idea of renaming nextOffset in SpGistLeafTupleData.
Or at least documenting in comments that this field is more than just an offset.
This looks like assert
Greetings,
* Dave Page (dp...@pgadmin.org) wrote:
> On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost wrote:
> > * Dave Page (dp...@pgadmin.org) wrote:
> > > Attached is a patch against 12.4 for the build system in case anyone
> > wants
> > > to play (I'll do it properly against the head branch later)
On Wed, Sep 2, 2020 at 3:41 PM Dilip Kumar wrote:
>
> On Wed, Sep 2, 2020 at 10:55 AM Amit Kapila wrote:
> >
> > >
> >
> > We can combine the tests in 015_stream_simple.pl and
> > 020_stream_binary.pl as I can't see a good reason to keep them
> > separate. Then, I think we can keep only this part
On 2020-Sep-02, David Rowley wrote:
> v7 (Separate Result Cache node)
> Query 1:
> Execution Time: 894.003 ms
>
> Query 2:
> Execution Time: 854.950 ms
> v7 + hacks_V3 (caching done in Nested Loop)
> Query 1:
> Execution Time: 770.470 ms
>
> Query 2
> Execution Time: 779.181 ms
Wow, this is
On 01.09.2020 13:22, Michael Banck wrote:
Hi,
as a continuation of [1], I've split-off the zero page header case from
the last patch, as this one seems less contentious.
Michael
[1] https://commitfest.postgresql.org/28/2308/
I've looked through the previous discussion. As far as I got it, mo
On Wed, Sep 2, 2020 at 1:57 AM Peter Geoghegan wrote:
>
> On Wed, Aug 26, 2020 at 1:46 AM John Naylor
> wrote:
> > The fact that that logic extends by 20 * numwaiters to get optimal
> > performance is a red flag that resources aren't being allocated
> > efficiently.
>
> I agree that that's prett
On Wed, Sep 2, 2020 at 7:19 PM Amit Kapila wrote:
> On Wed, Sep 2, 2020 at 3:41 PM Dilip Kumar wrote:
> >
> > On Wed, Sep 2, 2020 at 10:55 AM Amit Kapila
> wrote:
> > >
> > > >
> > >
> > > We can combine the tests in 015_stream_simple.pl and
> > > 020_stream_binary.pl as I can't see a good reas
Thomas Munro writes:
> You don't need to call stat() just to find out if a dirent is a file
> or directory, most of the time. Please see attached.
Hm. If we do this, I can see wanting to apply the knowledge in more
places than walkdir(). Is it possible to extract out the nonstandard
bits into
vignesh C writes:
> Postgres's describe-config option prints reset_val for int & real
> configuration parameters which is not useful as it is not updated.
Uh, what?
> Printing boot_val is better in this case.
Please defend that claim. Otherwise this seems like a pretty
random change.
Oleksandr Shulgin writes:
> On Wed, Sep 2, 2020 at 7:35 AM Andres Freund wrote:
>> In the docs we already name the parameters using SQL like syntax, see [1].
>> How about we actually do so for at least the more common / complicated
>> functions?
> I find myself in the same situation a lot.
> I'v
>
> I have a wild idea of renaming nextOffset in SpGistLeafTupleData.
> Or at least documenting in comments that this field is more than just an
> offset.
>
Seems reasonable as previous changes localized mentions of nextOffset only
to leaf tuple definition and access macros. So I've done this renam
On Wed, Sep 2, 2020 at 4:35 PM Tom Lane wrote:
> Thomas Munro writes:
> > You don't need to call stat() just to find out if a dirent is a file
> > or directory, most of the time. Please see attached.
>
> Hm. If we do this, I can see wanting to apply the knowledge in more
> places than walkdir(
On Tue, Sep 01, 2020 at 03:09:14PM -0700, Peter Geoghegan wrote:
On Tue, Sep 1, 2020 at 2:09 PM Tomas Vondra
wrote:
>* Instead of changing the order directly, now patch creates another patch with
> modifier order of clauses. It does so for the normal sort as well as for
> incremental sort. Th
Hi
On Wed, Sep 2, 2020 at 9:05 AM Dave Page wrote:
>
>> Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
>> used under Windows.
>
>
Here's a patch to make it build successfully (against head). I believe the
changes to Solution.pm should be back patched all the way, and the
On Wed, Sep 2, 2020 at 2:47 PM Stephen Frost wrote:
> Greetings,
>
> * Dave Page (dp...@pgadmin.org) wrote:
> > On Tue, Sep 1, 2020 at 5:29 PM Stephen Frost wrote:
> > > * Dave Page (dp...@pgadmin.org) wrote:
> > > > Attached is a patch against 12.4 for the build system in case anyone
> > > want
On 2020-Sep-02, Tom Lane wrote:
> I don't think we should go overboard on this, but +1 for labeling all the
> cases where the usage isn't obvious.
+1
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Greetings,
* Dave Page (dp...@pgadmin.org) wrote:
> On Wed, Sep 2, 2020 at 9:05 AM Dave Page wrote:
> >> Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
> >> used under Windows.
>
> Here's a patch to make it build successfully (against head). I believe the
> changes to Solu
Hi,
First, on behalf of the PostgreSQL 13 RMT, thank you everyone for your
hard work not only building all of the features that are going into
PostgreSQL 13, but for the diligence and work in stabilizing the
release. We have now reached the point of the release cycle where we can
start making deci
Hi
On Wed, Sep 2, 2020 at 7:08 PM Stephen Frost wrote:
> Greetings,
>
> * Dave Page (dp...@pgadmin.org) wrote:
> > On Wed, Sep 2, 2020 at 9:05 AM Dave Page wrote:
> > >> Yes, that'd be in the GSSENC code, which I hadn't been expecting to be
> > >> used under Windows.
> >
> > Here's a patch to m
Fabien COELHO writes:
> [ pg-hba-cont-4.patch ]
I looked this over and I think it seems reasonable, but there's
something else we should do. If people are writing lines long
enough that they need to continue them, how long will it be
before they overrun the line length limit? Admittedly, there'
Hi Peter,
Yeah it's funny I got this immediately after upgrading to Big Sur (beta
5). I found commit 1c0cf52b39ca3 but couldn't quite find the mailing
list thread on it from 4 years ago (it lists Heikki and Thomas Munro as
reviewers). Was it prompted by a similar error you encountered?
On Tue, Au
On 2020-Sep-02, Jesse Zhang wrote:
> Hi Peter,
>
> Yeah it's funny I got this immediately after upgrading to Big Sur (beta
> 5). I found commit 1c0cf52b39ca3 but couldn't quite find the mailing
> list thread on it from 4 years ago (it lists Heikki and Thomas Munro as
> reviewers). Was it prompted
Wow thanks Alvaro! My search of "most obvious keywords" didn't turn this
up.
On Wed, Sep 2, 2020 at 2:18 PM Alvaro Herrera wrote:
>
> On 2020-Sep-02, Jesse Zhang wrote:
>
> > Hi Peter,
> >
> > Yeah it's funny I got this immediately after upgrading to Big Sur (beta
> > 5). I found commit 1c0cf52b39
Hi,
Is possible that BTreeTupleSetNAtts, leave everything tidy, so that
BTreeTupleGetHeapTID doesn't fail.
BTreeTupleGetHeapTID can return NULL.
But, as we can see:
1. Line 2085 (nbtutils.c):
if (BTreeTupleGetHeapTID(itup) != NULL && tupnatts != nkeyatts)
2. Line 803 (nbtsearch.c):
if (he
Also, in:
5. Line 2671 (nbtutils.c):
ItemPointerGetBlockNumber(BTreeTupleGetHeapTID(newtup)),
ItemPointerGetOffsetNumber(BTreeTupleGetHeapTID(newtup)),
itemptr.h:
/*
* ItemPointerGetBlockNumberNoCheck
* Returns the block number of a disk item pointer.
*/
#define ItemPointerGetBlockNumberNoC
On Wed, Sep 2, 2020 at 2:41 PM Ranier Vilela wrote:
> Maybe, better make sure, because:
> 3. Line 2285 (nbtutils.c):
> ItemPointerCopy(BTreeTupleGetMaxHeapTID(lastleft), pivotheaptid);
> 4. Line 2316 (nbtutils.c) :
> ItemPointerCopy(BTreeTupleGetHeapTID(firstright), pivotheaptid);
>
> Can
> Even if BTreeTupleGetHeapTID() did somehow return a NULL
> pointer, then the user would be getting off lightly by experiencing a
> hard crash instead of data corruption.
>
Oh, I'm sorry, I thought that "hard crash" was a bad thing.
Ranier Vilela
Pavel Stehule writes:
> [ string_to_table-20200825.patch ]
I reviewed this, whacked it around a little, and pushed it.
Possibly the most controversial thing I did was to move the existing
documentation entry for string_to_array() into the string-functions
table. I did not like it one bit that t
On Thu, Sep 03, 2020 at 12:00:17AM +0300, Alexey Kondratov wrote:
> On 2020-09-02 07:56, Justin Pryzby wrote:
> >
> > Done in the attached, which is also rebased on 1d6541666.
> >
> > And added RelationAssumeNewRelfilenode() as I mentioned - but I'm hoping
> > to
> > hear from Michael about any r
On Wed, Sep 2, 2020 at 3:16 PM Ranier Vilela wrote:
> Oh, I'm sorry, I thought that "hard crash" was a bad thing.
I think that you are being sarcastic here, but just in case I'm wrong
I'll clarify what I meant: a good sign that a static analysis tool has
produced a useless complaint is that it ap
On Wed, May 27, 2020 at 12:31 AM Craig Ringer wrote:
> On Tue, 12 May 2020, 08:42 Paul Guo, wrote:
>> 1. StartupXLOG() does fsync on the whole data directory early in the crash
>> recovery. I'm wondering if we could skip some directories (at least the
>> pg_log/, table directories) since wal, e
Hi,
>> I wonder if trying to list info about all stats from the statistics
>> object in a single line is necessary. Maybe we should split the info
>> into one line per statistics, so for example
>>
>> CREATE STATISTICS s (mcv, ndistinct, dependencies) ON ...
>>
On Tue, May 12, 2020 at 12:43 PM Paul Guo wrote:
> 2. CheckPointTwoPhase()
>
> This may be a small issue.
>
> See the code below,
>
> for (i = 0; i < TwoPhaseState->numPrepXacts; i++)
> RecreateTwoPhaseFile(gxact->xid, buf, len);
>
> RecreateTwoPhaseFile() writes a state file for a prepared t
On Sun, 2020-08-30 at 17:03 +0200, Tomas Vondra wrote:
> So I'm wondering if the hashagg is not ignoring similar non-I/O costs
> for the spilling case. In particular, the initial section computing
> startup_cost seems to ignore that we may need to so some of the stuff
> repeatedly - for example we'
On Wed, Sep 2, 2020 at 5:18 PM Jeff Davis wrote:
> create table text10m(t text collate "C.UTF-8", i int, n numeric);
> insert into text10m select s.g::text, s.g, s.g::numeric from (select
> (random()*10)::int as g from generate_series(1,1000)) s;
> explain analyze select distinct t fro
On Wed, Sep 2, 2020 at 8:06 PM Tom Lane wrote:
> Please defend that claim. Otherwise this seems like a pretty
> random change.
I had seen that there is discrepancy in postgres --describe-config & the
value displayed from pg_settings like in the below case:
postgres=# select name,min_val, max_va
On Thu, Sep 3, 2020 at 8:30 AM Tom Lane wrote:
> The proposed tests seemed mighty duplicative, and they even contained
> syntax errors, so I didn't believe that they were carefully considered.
Can you please share examples of what syntax errors were in those
previous tests?
Kind Regards,
Peter S
Peter Smith writes:
> On Thu, Sep 3, 2020 at 8:30 AM Tom Lane wrote:
>> The proposed tests seemed mighty duplicative, and they even contained
>> syntax errors, so I didn't believe that they were carefully considered.
> Can you please share examples of what syntax errors were in those
> previous
On Wed, Sep 02, 2020 at 01:17:32PM +0200, Julien Rouhaud wrote:
> Shouldn't options be an int? The rest of the patch looks good to me.
It should, thanks for looking at it. Let's wait a couple of days and
see if others have any comments. If there are no objections, I'll try
to commit this one.
-
čt 3. 9. 2020 v 0:30 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > [ string_to_table-20200825.patch ]
>
> I reviewed this, whacked it around a little, and pushed it.
>
> Possibly the most controversial thing I did was to move the existing
> documentation entry for string_to_array() int
On 2020-09-02 22:43, Jesse Zhang wrote:
| conftest.c:184:3: error: implicitly declaring library function
'exit' with type 'void (int) __attribute__((noreturn))'
[-Werror,-Wimplicit-function-declaration]
| exit(! does_int64_work());
| ^
| conftest.c:184:3: note: include the header or explicit
On Thu, Sep 3, 2020 at 3:52 AM Juan José Santamaría Flecha
wrote:
> On Wed, Sep 2, 2020 at 4:35 PM Tom Lane wrote:
>> Thomas Munro writes:
>> > You don't need to call stat() just to find out if a dirent is a file
>> > or directory, most of the time. Please see attached.
>>
>> Hm. If we do this
On 8/31/20 6:19 PM, Ashutosh Bapat wrote:
On Mon, Aug 31, 2020 at 3:36 PM Andrey V. Lepikhov
wrote:
Thanks for this helpful feedback.
I think the patch has some other problems like it works only for
regular tables on foreign server but a foreign table can be pointing
to any relation like a ma
On Tue, Sep 01, 2020 at 11:53:36AM +0200, Daniel Gustafsson wrote:
> On 14 Aug 2020, at 20:23, Alvaro Herrera wrote:
>
>> The logic to keep track number of used slots used is baroque, though -- that
>> could use a lot of simplification.
>
> What if slot_init was an integer which increments toget
Thomas Munro writes:
>> On Wed, Sep 2, 2020 at 4:35 PM Tom Lane wrote:
>>> Hm. If we do this, I can see wanting to apply the knowledge in more
>>> places than walkdir().
> Good idea. Here's a new version that defines a new function
> get_dirent_type() in src/common/file_utils_febe.c and uses i
Peter Eisentraut writes:
> On 2020-09-02 22:43, Jesse Zhang wrote:
>> | conftest.c:184:3: error: implicitly declaring library function
>> 'exit' with type 'void (int) __attribute__((noreturn))'
>> [-Werror,-Wimplicit-function-declaration]
> Where did the -Werror come from?
Peter wasn't entirely
On 2020-09-01 03:29, Pavel Stehule wrote:
Hi
po 31. 8. 2020 v 17:03 odesílatel Kasahara Tatsuhito
napsal:
Hi,
On Mon, Aug 31, 2020 at 8:22 PM torikoshia
wrote:
As discussed in the thread[1], it'll be useful to make it
possible to get the memory contexts of an arbitrary backend
process.
+1
On Thu, Sep 3, 2020 at 5:36 PM Tom Lane wrote:
> [request for better comments]
Ack.
> Both of these concerns would abate if we had get_dirent_type()
> just throw an error itself when stat() fails, thereby removing the
> PGFILETYPE_ERROR result code. I'm not 100% sold either way on
> that, but i
Thanks for reviewing!
I'm going to modify the patch according to your comments.
On 2020-09-01 10:54, Andres Freund wrote:
Hi,
On 2020-08-31 20:22:18 +0900, torikoshia wrote:
After commit 3e98c0bafb28de, we can display the usage of the
memory contexts using pg_backend_memory_contexts system
vi
>On Wed, Sep 2, 2020 at 3:40 PM vignesh C wrote:
> I have attached the scripts that I used for the test results I
> mentioned in my previous mail. create.sql file has the table that I
> used, insert_data_gen.txt has the insert data generation scripts. I
> varied the count in insert_data_gen to gen
66 matches
Mail list logo
