On Sat, Nov 14, 2020 at 2:44 PM Jesse Zhang wrote:
> Hi,
>
> On Fri, Nov 13, 2020 at 10:04 PM Andy Fan wrote:
> >
> > Hi:
> >
> > Take the following example:
> >
> > insert into cte1 select i, i from generate_series(1, 100)i;
> > create index on cte1(a);
> >
> > explain
> > with cte1 as
On Sat, Nov 14, 2020 at 2:14 PM Tom Lane wrote:
> Andy Fan writes:
> > Take the following example:
>
> > insert into cte1 select i, i from generate_series(1, 100)i;
> > create index on cte1(a);
>
> > explain
> > with cte1 as (select * from cte1)
> > select * from c where a = 1;
>
> > It
Hi,
On Fri, Nov 13, 2020 at 10:04 PM Andy Fan wrote:
>
> Hi:
>
> Take the following example:
>
> insert into cte1 select i, i from generate_series(1, 100)i;
> create index on cte1(a);
>
> explain
> with cte1 as (select * from cte1)
> select * from c where a = 1;
>
ITYM:
EXPLAIN
WITH c AS
On Sat, Nov 14, 2020 at 2:04 PM Andy Fan wrote:
>
> Hi:
>
> Take the following example:
>
> insert into cte1 select i, i from generate_series(1, 100)i;
> create index on cte1(a);
>
> explain
> with cte1 as (select * from cte1)
> select * from c where a = 1;
>
> It needs to do seq scan on
Andy Fan writes:
> Take the following example:
> insert into cte1 select i, i from generate_series(1, 100)i;
> create index on cte1(a);
> explain
> with cte1 as (select * from cte1)
> select * from c where a = 1;
> It needs to do seq scan on the above format, however it is pretty
> quick
Hi:
Take the following example:
insert into cte1 select i, i from generate_series(1, 100)i;
create index on cte1(a);
explain
with cte1 as (select * from cte1)
select * from c where a = 1;
It needs to do seq scan on the above format, however it is pretty
quick if we change the query to
Hi!
On Fri, Nov 13, 2020 at 1:47 PM Georgios wrote:
> In short, I think v3 of the patch looks good to change to 'RFC' status.
> Given the possible costing concerns, I will refrain from changing the
> status just yet, to give the opportunity to more reviewers to chime in.
> If in the next few
Thomas Munro writes:
> My bug report got an automated-looking message telling me to retest in
> Big Sur beta 6 back in September, and I've just now upgraded an old
> x86 Mac to Big Sur 11.01 and I can no longer reproduce the problem, so
> it looks like it was fixed! Thanks, Apple.
Hah! I've
On Fri, Oct 18, 2019 at 2:26 PM Thomas Munro wrote:
> On Fri, Oct 18, 2019 at 1:21 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > On Tue, Oct 15, 2019 at 1:55 PM Tom Lane wrote:
> > >> and now prairiedog has shown it too:
> > >>
On Fri, Nov 13, 2020 at 12:43:41PM +0100, Daniel Gustafsson wrote:
> When spellchecking one of my patches for submission, a few other typos fell
> out
> as per the attached. The one change which isn't in a comment is the object
> address class description used for error messages:
>
> -
Here's a v25.
I made a few more changes to the docs per David's suggestions; I also
reordered the sections quite a bit. It's now like this:
* Batch Mode
* Using Batch Mode
* Issuing Queries
* Processing Results
* Error Handling
* Interleaving Result Processing and Query
On 11/13/20 8:07 PM, Jacob Champion wrote:
> On Nov 12, 2020, at 2:40 PM, Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Thanks for the updated patch. It's a quite massive amount of code - I I
>> don't think we had many 2MB patches in the past, so this is by no means
>> a full review.
>
> Thanks for
Alexander Lakhin writes:
> 13.11.2020 23:16, Tom Lane wrote:
>> That would soon lead us to changing every stat() caller in the system
>> to have Windows-specific looping logic. No thanks. If we need to do
>> this, let's put in a Windows wrapper layer comparable to pgwin32_open()
>> for open().
13.11.2020 23:16, Tom Lane wrote:
> Alexander Lakhin writes:
>> Shouldn't pg_ls_dir_files() retry stat() on ERROR_ACCESS_DENIED just
>> like the pgwin32_open() does to ignore files in "delete pending" state?
> That would soon lead us to changing every stat() caller in the system
> to have
Alexander Lakhin writes:
> Shouldn't pg_ls_dir_files() retry stat() on ERROR_ACCESS_DENIED just
> like the pgwin32_open() does to ignore files in "delete pending" state?
That would soon lead us to changing every stat() caller in the system
to have Windows-specific looping logic. No thanks. If
Hello hackers,
31.03.2020 19:41, Tom Lane wrote:
> Justin Pryzby writes:
>> I suggest to leave stat() alone in your patch for stable releases. I think
>> it's okay if we change behavior so that a broken symlink is skipped instead
>> of
>> erroring (as a side effect of skipping ENOENT with
Peter Eisentraut writes:
> Here is an updated patch with the type cache integration added.
> To your point, this now checks each fields hashability before
> considering a row type as hashable. It can still have run-time errors
> for untyped record datums, but that's not something we can do
On Nov 12, 2020, at 2:40 PM, Tomas Vondra wrote:
>
> Hi,
>
> Thanks for the updated patch. It's a quite massive amount of code - I I
> don't think we had many 2MB patches in the past, so this is by no means
> a full review.
Thanks for taking a look! You're not kidding about the patch size.
Jacob Champion writes:
> Patch looks good to me. Seems like a useful feature, and I agree that the
> two-pass implementation makes the change very easy to review.
LGTM too. I made a couple of cosmetic improvements and pushed it.
> Quick note on test coverage: gcov marks the "needle not found"
On Fri, Nov 13, 2020 at 01:39:31PM -0300, Alvaro Herrera wrote:
> On 2020-Nov-13, Justin Pryzby wrote:
>
> > I saw a bunch of these in my logs:
> >
> > log_time | 2020-10-25 22:59:45.619-07
> > database |
> > left | could not open relation with OID 292103095
> > left | processing work
Hello,
This patch introduces a set of changes to the table AM APIs, making them
accept a column projection list. That helps columnar table AMs, so that
they don't need to fetch all columns from disk, but only the ones
actually needed.
The set of changes in this patch is not exhaustive -
there
On Fri, Nov 13, 2020 at 01:27:34PM +0800, Craig Ringer wrote:
> On Fri, Nov 13, 2020 at 11:50 AM Bruce Momjian wrote:
>
>
> > So you are saying you don't think you are getting sufficient thought
> > into your proposal, and getting just a reflex? Just because we don't
> > agree
On 2020-Nov-13, Justin Pryzby wrote:
> I saw a bunch of these in my logs:
>
> log_time | 2020-10-25 22:59:45.619-07
> database |
> left | could not open relation with OID 292103095
> left | processing work entry for relation
> "ts.child.alarms_202010_alarm_clear_time_idx"
>
> Those
Heikki Linnakangas writes:
> On 13/11/2020 11:04, Pavel Borisov wrote:
>> For historical reasons, now we have two differently named but similar
>> ternary data types in TSearch and Gin text-related types. Before v13
>> there was also Gin's private TS_execute() version, from which we
>>
Kyotaro Horiguchi writes:
> At Tue, 10 Nov 2020 14:30:08 -0500, Tom Lane wrote in
>> For instance, {1,-1,0} is the line "x = y". We could argue about
>> whether it'd be sensible to return zero for the distance between that
>> and the point (inf,inf), but surely any point with one inf and one
Hi,
I got somewhat scared when my explain took a few seconds to complete and
used a few gigs of RAM.
To reproduce try the following:
discard temp;
create temp table a as select to_timestamp(generate_series(1, 7000)) i;
analyze a;
set work_mem to '3GB';
explain select distinct a1.i - a2.i from
I saw a bunch of these in my logs:
log_time | 2020-10-25 22:59:45.619-07
database |
left | could not open relation with OID 292103095
left | processing work entry for relation
"ts.child.alarms_202010_alarm_clear_time_idx"
Those happen following a REINDEX job on that index.
I think
Peter Eisentraut writes:
> On 2020-11-12 23:28, Tom Lane wrote:
>> I'm on board with pulling these now --- 8.2 to v14 is plenty of
>> deprecation notice. However, the patch seems incomplete in that
>> the code support for these is still there -- look for
>> RTOldContainedByStrategyNumber and
Greetings,
* Tomas Vondra (tomas.von...@enterprisedb.com) wrote:
> On 11/13/20 3:20 AM, Thomas Munro wrote:
> > I'm not really sure what to do about achive restore scripts that
> > block. That seems to be fundamentally incompatible with what I'm
> > doing here.
>
> IMHO we can't do much about
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Thu, Nov 12, 2020 at 11:28 PM Tom Lane wrote:
> > > The changes to the contrib modules appear to be incomplete in some ways.
> > > In cube, hstore, and seg, there are no changes to the extension
> > > scripts to remove the
On 2020/11/13 8:39, Euler Taveira wrote:
On Wed, 11 Nov 2020 at 22:40, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
On 2020/11/12 6:00, Euler Taveira wrote:
> The first patch adds a new message that prints the latest completed
checkpoint
> when the consistent
Amit Kapila wrote:
> On Thu, Nov 12, 2020 at 2:45 PM Antonin Houska wrote:
> >
> >
> > No background undo
> > --
> >
> > Reduced complexity of the patch seems to be the priority at the moment. Amit
> > suggested that cleanup of an orphaned relation file is simple enough to be
>
On Wed, Nov 11, 2020 at 4:30 PM Ajin Cherian wrote:
>
> Did some further tests on the problem I saw and I see that it does not
> have anything to do with this patch. I picked code from top of head.
> If I have enough changes in a transaction to initiate streaming, then
> it will also stream the
On Fri, Nov 13, 2020 at 9:44 PM Amit Kapila wrote:
>
> On Thu, Nov 12, 2020 at 2:28 PM Ajin Cherian wrote:
> Hmm, introducing an additional boolean variable for this doesn't seem
> like a good idea neither the other alternative suggested by you. How
> about if we change the comment to make it
On Tue, Nov 10, 2020 at 4:19 PM Ajin Cherian wrote:
>
> I was doing some testing, and I found some issues. Two issues. The
> first one, seems to be a behaviour that might be acceptable, the
> second one not so much.
> I was using test_decoding, not sure how this might behave with the
> pg_output
> 10 нояб. 2020 г., в 23:07, Tomas Vondra
> написал(а):
>
> On 11/10/20 7:16 AM, Andrey Borodin wrote:
>>
>>
>> but this picture was not stable.
>>
>
> Seems we haven't made much progress in reproducing the issue :-( I guess
> we'll need to know more about the machine where this happens.
>
> GIN is not just for full-text search, so using TSTernaryValue in
> GinScanKeyData is wrong. And it would break existing extensions.
>
> I didn't look much further than that, but I've got a feeling that
> combining those is a bad idea. TSTernaryValue is used in text-search
> code, even when
When spellchecking one of my patches for submission, a few other typos fell out
as per the attached. The one change which isn't in a comment is the object
address class description used for error messages:
- "extented statistics",
+ "extended statistics",
It's used
Thomas Munro wrote:
> On Thu, Nov 12, 2020 at 10:15 PM Antonin Houska wrote:
> I saw that -- great news! -- and have been meaning to write for a
> while. I think I am nearly ready to talk about it again.
I'm looking forward to it :-)
> 100% that it's worth trying to do something much
On Fri, 13 Nov 2020 at 00:50, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Simon Riggs
> > If a rogue user/process is suspected, this would allow you to identify
> > more easily the changes made by specific sessions/users.
>
> Isn't that kind of auditing a job of pgAudit or log_statement = mod?
On Thu, Nov 12, 2020 at 10:06 AM Fujii Masao
wrote:
>
> Thanks for the analysis! I pushed the patch.
>
Thanks! Since we are replacing custom SIGHUP and SIGTERM handlers with
standard ones, how about doing the same thing in worker_spi.c? I
posted a patch previously [1] in this mail thread. If it
On 12/11/2020 15:17, Daniel Gustafsson wrote:
On 5 Oct 2020, at 14:14, Heikki Linnakangas wrote:
I would expect the checksums worker to be automatically started at postmaster
startup. Can we make that happen?
A dynamic background worker has to be registered from a regular backend, so
it's
On Tue, Nov 10, 2020 at 3:47 PM Paul Guo wrote:
>
> Thanks for doing this. There might be another solution - use raw insert
> interfaces (i.e. raw_heap_insert()).
> Attached is the test (not formal) patch that verifies this idea.
> raw_heap_insert() writes the page into the
> table files
On 13/11/2020 11:04, Pavel Borisov wrote:
Hi, hackers!
For historical reasons, now we have two differently named but similar
ternary data types in TSearch and Gin text-related types. Before v13
there was also Gin's private TS_execute() version, from which we
eventually shifted to Tsearch's
‐‐‐ Original Message ‐‐‐
On Friday, November 13, 2020 10:50 AM, Julien Rouhaud
wrote:
> On Wed, Nov 11, 2020 at 8:34 PM Georgios Kokolatos
> gkokola...@protonmail.com wrote:
>
> > The following review has been posted through the commitfest application:
> > make installcheck-world:
On 11/13/20 3:20 AM, Thomas Munro wrote:
>
> ...
>
> I'm not really sure what to do about achive restore scripts that
> block. That seems to be fundamentally incompatible with what I'm
> doing here.
>
IMHO we can't do much about that, except for documenting it - if the
prefetch can't work
On Thu, Nov 12, 2020 at 2:28 PM Ajin Cherian wrote:
>
> On Wed, Nov 11, 2020 at 12:35 AM Amit Kapila wrote:
> I have rearranged the code in DecodeCommit/Abort/Prepare so
> > that it does only the required things (like in DecodeCommit was still
> > processing subtxns even when it has to just
Dear Li,
I read your patch, and I think the documentation is too simple to avoid all
problems.
(I think if some connection pooling is used, the same problem will occur.)
Could you add some explanations in the doc file? I made an example:
```
Note that this values should be set to zero if you
On Wed, Nov 11, 2020 at 8:34 PM Georgios Kokolatos
wrote:
>
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not
On Thu, Nov 12, 2020 at 3:10 PM Dilip Kumar wrote:
>
> On Tue, Nov 10, 2020 at 7:20 PM Amit Kapila wrote:
> >
> > On Tue, Nov 10, 2020 at 2:25 PM Dilip Kumar wrote:
>
> > 3. Can you please prepare a separate patch for test case changes so
> > that it would be easier to verify that it fails
If a file is modified and becomes larger in the source system while
pg_rewind is running, pg_rewind can leave behind a partial copy of file.
That's by design, and it's OK for relation files because they're
replayed from WAL. But it can cause trouble for configuration files.
I ran into this
On Thu, Nov 12, 2020 at 11:28 PM Tom Lane wrote:
>
> > The changes to the contrib modules appear to be incomplete in some ways.
> > In cube, hstore, and seg, there are no changes to the extension
> > scripts to remove the operators. All you're doing is changing the C
> > code to no longer
On Wed, Nov 4, 2020 at 2:18 PM Amit Kapila wrote:
>
> Or you might want to consider moving the check related to
> IsModifySupportedInParallelMode() inside
> PrepareParallelModeForModify(). That way the code might look a bit
> cleaner.
>
Posting an updated Parallel SELECT for "INSERT INTO ...
Hi, hackers!
For historical reasons, now we have two differently named but similar
ternary data types in TSearch and Gin text-related types. Before v13 there
was also Gin's private TS_execute() version, from which we eventually
shifted to Tsearch's TS_execute().
To make things more even and
On Wed, Nov 11, 2020 at 10:42 PM vignesh C wrote:
>
> On Tue, Nov 10, 2020 at 7:27 PM Amit Kapila wrote:
> >
> > On Tue, Nov 10, 2020 at 7:12 PM vignesh C wrote:
> > >
> > > On Tue, Nov 3, 2020 at 2:28 PM Amit Kapila
> > > wrote:
> > > >
> > >
> > > I have worked to provide a patch for the
>
> 1. The patch removes <^ and >^ from func.sgml, which is fine, but
shouldn't there be an addition for the new operators? (I think
>
I fully agree and added "point" as a possible input type for <<| and |>> in
manual. PFA v5
> undocumented. Maybe instead of removing, change the text to be
>
At Fri, 13 Nov 2020 07:15:41 +, "osumi.takami...@fujitsu.com"
wrote in
> Hello, Tsunakawa-San
>
Thanks for sharing it!
> > Do you know the reason why data copy was done before? And, it may be
> > odd for me to ask this, but I think I saw someone referred to the past
> > discussion that
On Nov 11, 2020, at 10:57 AM, Jacob Champion wrote:
>
> False alarm -- the stderr debugging I'd added in to track down the
> assertion tripped up the "no stderr" tests. Zero failing tests now.
I took a look at the OpenSSL interop problems you mentioned upthread. I
don't see a hang like you did,
58 matches
Mail list logo
