> On 26-Aug-2020, at 11:10 PM, Fujii Masao wrote:
>
> I added the following comments based on the suggestion by Sawada-san
> upthread. Thought?
>
> + * Since this routine gets called every commit time, it's important to
> + * exit quickly if sync replication is not requested. So we c
Hi Julien and Pavel!
How about using \dX rather than \dz?
Thanks for your suggestion!
I'll replace it if I got consensus. :-D
How about using \dX rather than \dz?
Thanks for your suggestion!
I'll replace it if I got consensus. :-D
I re-read a help message of \d* commands and realized i
On Wed, 26 Aug 2020 at 22:47, Alvaro Herrera
wrote:
>
> What this is saying to me is that we'd need to make sure to run the
> final target partition's AFTER triggers, not the original target
> partition.
Agreed.
> But I'm not 100% about running the BEFORE triggers. Maybe
> one way to addre
On Wed, Aug 26, 2020 at 11:22 PM Jeff Janes wrote:
>
>
> On Tue, Aug 25, 2020 at 8:58 AM Amit Kapila wrote:
>
>>
>> I am planning
>> to push the first patch (v53-0001-Extend-the-BufFile-interface) in
>> this series tomorrow unless you have any comments on the same.
>
>
>
> I'm getting compiler w
Hello.
FYI - that patch has conflicts when applied.
Kind Regards
Peter Smith
Fujitsu Australia.
On Thu, Aug 27, 2020 at 3:11 PM vignesh C wrote:
>
> On Tue, Jul 14, 2020 at 12:17 PM vignesh C wrote:
> >
> > On Tue, Jul 14, 2020 at 11:13 AM David Rowley wrote:
> > >
> > > On Tue, 14 Jul 2020 a
Hi,
Per Clang UBSan
Clang 10 (64 bits)
Postgres 14 (latest)
2020-08-27 01:02:14.930 -03 client backend[42432] pg_regress/create_table
STATEMENT: create table defcheck_0 partition of defcheck for values in (0);
indexcmds.c:1162:22: runtime error: null pointer passed as argument 2,
which is declar
From: Amit Kapila
> Sure, but on a daily basis, one requires only incremental WAL to
> complete the backup but in this case, it would require the entire
> database back up unless we have some form of block-level incremental
> backup method.
Regarding the backup time, I think users can shorten it
On Thu, Aug 27, 2020 at 7:04 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Amit Kapila
> > So you want your users to shutdown and restart the server before Copy
> > because that would be required if you want to change the wal_level.
>
> Yes. They seem to be fine with it, as far as I heard from
Hi,
Is this something to worry about, or is it another problem with the
analysis tool, that nobody cares about?
clang 10 (64 bits)
postgres 14 (latest)
31422==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4560 byte(s) in 1 object(s) allocated from:
#0 0x50e33d in malloc
(/usr/sr
Hi all,
While digging into a different patch involving DROP INDEX CONCURRENTLY
and replica indexes, I have found that the handling of indisreplident
is inconsistent for invalid indexes:
https://www.postgresql.org/message-id/20200827022835.gm2...@paquier.xyz
In short, imagine the following sequenc
On Thu, Aug 27, 2020 at 8:04 AM Greg Nancarrow wrote:
>
> > I have attached new set of patches with the fixes.
> > Thoughts?
>
> Hi Vignesh,
>
> I don't really have any further comments on the code, but would like
> to share some results of some Parallel Copy performance tests I ran
> (attached).
> I have attached new set of patches with the fixes.
> Thoughts?
Hi Vignesh,
I don't really have any further comments on the code, but would like
to share some results of some Parallel Copy performance tests I ran
(attached).
The tests loaded a 5GB CSV data file into a 100 column table (of
diffe
On Wed, Aug 26, 2020 at 09:08:51PM +0900, Michael Paquier wrote:
> I'll go through this part again tomorrow, it is late here.
There is actually a huge gotcha here that exists since replica
identities exist: relation_mark_replica_identity() only considers
valid indexes! So, on HEAD, if DROP INDEX
On Wed, Aug 26, 2020 at 9:19 PM Robert Haas wrote:
>
> On Wed, Aug 26, 2020 at 7:36 AM Ashutosh Sharma wrote:
> > Removed this note from the documentation and added a note saying: "The
> > user needs to ensure that they do not operate pg_force_freeze function
> > on a deleted tuple because it may
On Thu, Aug 27, 2020 at 6:15 AM Alvaro Herrera wrote:
> > --4.90%--smgropen
> > |--2.86%--ReadBufferWithoutRelcache
>
> Looking at an earlier report of this problem I was thinking whether it'd
> make sense to replace SMgrRelationHash with a simplehash tabl
From: Amit Kapila
> So you want your users to shutdown and restart the server before Copy
> because that would be required if you want to change the wal_level.
Yes. They seem to be fine with it, as far as I heard from a person who is
involved in the system design.
> However, even if we do tha
On Thu, Aug 27, 2020 at 8:05 AM Tom Lane wrote:
> Andy Fan writes:
> > I do see the README says we support bushy plans and I also see bushy
> > plans in real life (for example tpc-h Q20) like below. However I don't
> know
> > how it is generated with the algorithm in join_search_one_lev since it
Andy Fan writes:
> I do see the README says we support bushy plans and I also see bushy
> plans in real life (for example tpc-h Q20) like below. However I don't know
> how it is generated with the algorithm in join_search_one_lev since it
> always
> make_rels_by_clause_join with joinrel[1] which i
On 2020-Aug-04, Robert Haas wrote:
> On Mon, Aug 3, 2020 at 7:49 PM Alvaro Herrera
> wrote:
> > Why two transactions? The reason is that in order for this to work, we
> > make a catalog change (mark it detached), and commit so that all
> > concurrent transactions can see the change. A second t
Robert Haas writes:
> While the new behavior seems fine -- and indeed convenient -- for GUCs
> that are numeric with a unit, it does not seem very nice at all for
> GUCs that are unitless integers.
I find that distinction to be entirely without merit; not least because
we also have unitless float
Greeting.
I do see the README says we support bushy plans and I also see bushy
plans in real life (for example tpc-h Q20) like below. However I don't know
how it is generated with the algorithm in join_search_one_lev since it
always
make_rels_by_clause_join with joinrel[1] which is initial_rels wh
On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian wrote in
> > > Because we think we need any named value for every alternatives
> > > including the default value?
> >
> > Well, not putting clientcert at all gives the default b
On Wed, Aug 26, 2020 at 4:47 PM Tom Lane wrote:
> regression=# create table itable (f1 int);
> CREATE TABLE
> regression=# insert into itable values (384.234);
> INSERT 0 1
> regression=# table itable;
> f1
> -
> 384
> (1 row)
>
> It's always worked like that, and nobody's complained about i
On Thu, Aug 27, 2020 at 2:14 AM Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> On 21.08.2020 19:43, Ibrar Ahmed wrote:
>
>
>
> On Wed, Aug 19, 2020 at 6:15 PM Anastasia Lubennikova <
> a.lubennik...@postgrespro.ru> wrote:
>
>> On 18.08.2020 02:54, Alvaro Herrera wrote:
>> > On 2020
On 24.08.2020 16:19, Pavel Borisov wrote:
I added some extra comments and mentions in manual to make all the
things clear (see v7 patch)
The patch implements the proposed functionality, passes tests, and in
general looks good to me.
I don't mind using a macro to differentiate tuples with and
Ashwin Agrawal writes:
> If action and qual reference same object in CREATE RULE, it results in
> creating duplicate entries in pg_depend for it. Doesn't pose any harm, just
> unnecessarily bloats pg_depend.
Yeah, we generally don't try that hard to prevent duplicate pg_depend
entries. It's rela
If action and qual reference same object in CREATE RULE, it results in
creating duplicate entries in pg_depend for it. Doesn't pose any harm, just
unnecessarily bloats pg_depend. Reference InsertRule(). I think should be
able to avoid adding duplicate entries.
Don't know if this behaviour was disc
On 21.08.2020 19:43, Ibrar Ahmed wrote:
On Wed, Aug 19, 2020 at 6:15 PM Anastasia Lubennikova
mailto:a.lubennik...@postgrespro.ru>>
wrote:
On 18.08.2020 02:54, Alvaro Herrera wrote:
> On 2020-Aug-14, Ibrar Ahmed wrote:
>
>> The table used for the test contains three columns
On 8/26/20, 12:16 PM, "Alvaro Herrera" wrote:
> On 2020-Aug-20, Jeremy Schneider wrote:
>> Alternatively, if we don't want to take this approach, then I'd argue
>> that we should update README.tuplock to explicitly state that
>> XMAX_LOCK_ONLY and XMAX_COMMITTED are incompatible (just as it alread
Robert Haas writes:
> I don't think any of these cases should be allowed. Surely if we
> allowed 384.234 to be inserted into an integer column, everyone would
> say that we'd lost our minds.
regression=# create table itable (f1 int);
CREATE TABLE
regression=# insert into itable values (384.234);
On Mon, Aug 24, 2020 at 5:32 AM Greg Nancarrow wrote:
> For example,
>
> log_file_mode = 384.234
> max_connections = 1.0067e2
> port = 5432.123
> CREATE TABLE ... WITH (fillfactor = 23.45);
> CREATE TABLE ... WITH (parallel_workers = 5.4);
I don't think any of these cases should be allowed. Surel
On 2020-Aug-20, Jeremy Schneider wrote:
> While working with Nathan Bossart on an extension, we came across an
> interesting quirk and possible inconsistency in the PostgreSQL code
> around infomask flags. I'd like to know if there's something I'm
> misunderstanding here or if this really is a co
On 2020-Aug-25, Jakub Wartak wrote:
> Turning on/off the defer SLRU patch and/or fsync doesn't seem to make
> any difference, so if anyone is curious the next sets of append-only
> bottlenecks is like below:
>
> 14.69% postgres postgres[.] hash_search_with_hash_value
>
On 2020-Aug-25, Andres Freund wrote:
> Hi,
>
> On 2020-08-26 15:58:14 +1200, Thomas Munro wrote:
> > > --12.51%--compactify_tuples
> > > PageRepairFragmentation
> > > heap2_redo
> > > StartupXLOG
> >
>
On Wed, Aug 26, 2020 at 11:57 AM Mark Dilger
wrote:
> I wonder if we can get more comments for or against this patch, at least in
> principle, in the very near future, to help determine whether the deprecation
> notices should go into v13?
Speaking of that, has somebody written a specific patch
On Tue, Aug 25, 2020 at 8:58 AM Amit Kapila wrote:
> I am planning
> to push the first patch (v53-0001-Extend-the-BufFile-interface) in
> this series tomorrow unless you have any comments on the same.
>
I'm getting compiler warnings now, src/backend/storage/file/sharedfileset.c
line 288 needs
On 2020/08/20 11:29, Kyotaro Horiguchi wrote:
At Wed, 19 Aug 2020 13:20:46 +, Asim Praveen wrote in
On 12-Aug-2020, at 12:02 PM, Masahiko Sawada
wrote:
On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote:
On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
I think this gets to the r
On 2020-Aug-21, Ashutosh Bapat wrote:
> On Fri, Aug 21, 2020 at 1:28 PM movead...@highgo.ca
> wrote:
> > In current BEFORE TRIGGER implementation, it reports an error once a
> > trigger result out of current partition, but I think it should check
> > it after finish all triggers call, and you c
On 2020-Aug-26, Robert Haas wrote:
> On Wed, Aug 26, 2020 at 7:47 AM Dagfinn Ilmari Mannsåker
> wrote:
> > Would it be possible to make the compat versions only available when
> > building extensions, but not to core code?
>
> I think that would be good if we can do it. We could even have it
> i
Bruce Momjian writes:
> I see a compiler warning on git master:
>sharedfileset.c:288:8: warning: variable ‘found’ set but not used
> [-Wunused-but-set-variable]
Could get rid of the variable entirely: change the "break" to "return"
and then the final Assert can be "Assert(false)".
I see a compiler warning on git master:
sharedfileset.c:288:8: warning: variable ‘found’ set but not used
[-Wunused-but-set-variable]
--
Bruce Momjian https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptin
On Wed, Aug 26, 2020 at 7:36 AM Ashutosh Sharma wrote:
> Removed this note from the documentation and added a note saying: "The
> user needs to ensure that they do not operate pg_force_freeze function
> on a deleted tuple because it may revive the deleted tuple."
I do not agree with that note, ei
On Wed, Aug 26, 2020 at 7:47 AM Dagfinn Ilmari Mannsåker
wrote:
> Would it be possible to make the compat versions only available when
> building extensions, but not to core code?
I think that would be good if we can do it. We could even have it
inside #ifdef LWLOCK_API_COMPAT, and extension auth
Hi
I simplified access to results of winfuncargs functions by proxy type
"typedvalue". This type can hold any Datum value, and allows fast cast to
basic buildin types or it can use (slower) generic cast functions. It is
used in cooperation with a plpgsql assign statement that can choose the
corre
On 2020-08-25 18:44, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-07-24 15:23, Tom Lane wrote:
Sounds good. Do we want to try Noah's idea of temporarily committing
the remaining changes, to see if the buildfarm is happy?
I think to get value out of this you'd have to compare the config
I have run some benchmarks for this patch. Overall it seems that there is a
good improvement with the patch on recovery times:
The VMs I used have 32GB RAM, pgbench is initialized with a scale factor
3000(so it doesn’t fit to memory, ~45GB).
In order to avoid checkpoints during benchmark, max_w
On Sat, Aug 24, 2019 at 2:03 PM Kohei KaiGai wrote:
>
> 2019年8月24日(土) 7:02 Thomas Munro :
> >
> > On Fri, Aug 23, 2019 at 4:05 AM Kohei KaiGai wrote:
> > > We can consider the table join ptable X t1 above is equivalent to:
> > > (ptable_p0 + ptable_p1 + ptable_p2) X t1
> > > = (ptable_p0 X t1)
On Wed, Aug 26, 2020 at 6:12 AM Mark Dilger
wrote:
>
> The construction colname AS colalias brings to mind the words "pseudonym" and
> "alias". The distinction we're trying to draw here is between implicit
> pseudoyms and explicit ones, but "alias" is shorter and simpler, so I like
> that bett
Peter Eisentraut writes:
> On 2020-08-25 18:59, Tom Lane wrote:
>> For some of these, there's an argument for keeping the unused parameter
>> for consistency with sibling functions that do use it. Not sure how
>> important that is, though.
> I had meant to exclude cases like this from this patch
> On 26 Aug 2020, at 09:56, Michael Paquier wrote:
> On Tue, Aug 25, 2020 at 03:52:14PM +0200, Daniel Gustafsson wrote:
>> The attached moves all invocations under the correct guards. RAND_poll() in
>> fork_process.c needs to happen for both OpenSSL and OpenSSL random, thus the
>> check for both
Kyotaro Horiguchi writes:
> At Tue, 25 Aug 2020 19:03:50 -0400, Bruce Momjian wrote in
>> I can confirm that this two-month old email report still produces
>> different results with indexes on/off in git master, which I don't think
>> is ever correct behavior.
> I agree to that the behavior is
On Tue, Aug 25, 2020 at 08:59:37PM +0530, Rahila wrote:
> Sorry, I didn't apply correctly. The tests pass for me. In addition, I
> tested with partitioned tables. It works as expected and makes the REPLICA
> IDENTITY 'n' for the partitions as well when an index on a partitioned
> table is dropped
Andres Freund writes:
> Hi,
>
> On 2020-08-25 13:59:35 -0400, Robert Haas wrote:
>
>> However, if we do it all in a backward-compatible way as you propose,
>> then we're likely to keep reintroducing code that does it the old way
>> for a really long time. I'm not sure that actually makes a lot of
Thanks for the review. Please find my comments inline below:
On Tue, Aug 25, 2020 at 5:47 PM Masahiko Sawada
wrote:
>
> Let me share other comments on the latest version patch:
>
> Some words need to be tagged. For instance, I found the following words:
>
> VACUUM
> DISABLE_PAGE_SKIPPING
> HEAP_X
On 2020-08-15 16:23, Tom Lane wrote:
I wouldn't say that it's*fundamentally* new, but nonethless it disturbs
me that this proposal has pg_dump assembling CREATE FUNCTION commands in
very different ways depending on the server version. I'd rather see us
continuing to build the bulk of the comman
On 2020-08-15 16:36, Tom Lane wrote:
I wrote:
I wouldn't say that it's *fundamentally* new, but nonethless it disturbs
me that this proposal has pg_dump assembling CREATE FUNCTION commands in
very different ways depending on the server version. I'd rather see us
continuing to build the bulk of
On Wed, Aug 26, 2020 at 12:54 PM tsunakawa.ta...@fujitsu.com
wrote:
>
>
> Following this idea, what do you think about adding a new value "none" to
> wal_level, where no WAL is generated? The setting of wal_level is recorded
> in pg_control. The startup process can see the value and reject rec
At Tue, 25 Aug 2020 22:52:44 -0400, Bruce Momjian wrote in
> On Wed, Aug 26, 2020 at 11:41:39AM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 25 Aug 2020 10:04:44 -0400, Bruce Momjian wrote
> > in
> > > I think there are a few problems here. In the docs, it says "will still
> > > verify", but i
On Tue, Aug 25, 2020 at 5:17 AM Peter Geoghegan wrote:
>
> I think that the sloppy approach to locking for the
> fsmpage->fp_next_slot field in functions like fsm_search_avail() (i.e.
> not using real atomic ops, even though we could) is one source of
> problems here. That might end up necessitati
At Tue, 25 Aug 2020 19:03:50 -0400, Bruce Momjian wrote in
>
> I can confirm that this two-month old email report still produces
> different results with indexes on/off in git master, which I don't think
> is ever correct behavior.
I agree to that the behavior is broken.
> ---
On Mon, Aug 17, 2020 at 10:12 PM Andy Fan wrote:
>
>
> On Mon, Jun 22, 2020 at 9:39 AM Tom Lane wrote:
>
>> I wrote:
>> > Nope. The entire reason why we have that kluge is that we don't know
>> > until much later how many times we expect to execute the subplan.
>> > AlternativeSubPlan allows th
On Wed, Aug 26, 2020 at 06:38:52AM +0200, Peter Eisentraut wrote:
> I had meant to exclude cases like this from this patch set. If you see a
> case like this in *this* patch set, please point it out.
Last time I looked at that a lot of parameters are kept around as a
matter of symmetry with sibli
On Wed, Aug 26, 2020 at 8:14 AM David Rowley wrote:
> On Wed, 26 Aug 2020 at 05:18, Andy Fan wrote:
> >
> >
> > On Tue, Aug 25, 2020 at 11:53 PM Andres Freund
> wrote:
> >>
> >> On 2020-08-25 20:48:37 +1200, David Rowley wrote:
> >> > Also, just in case anyone is misunderstanding this Andres' a
On Tue, Aug 25, 2020 at 03:52:14PM +0200, Daniel Gustafsson wrote:
> The USE_OPENSSL_RANDOM macro is defined when OpenSSL is used as a randomness
> provider, but the implementation of strong randomness is guarded by
> USE_OPENSSL
> in most places. This is technically the same thing today, but it
Hello,
I think it's worth thinking about a sophisticated feature like Oracle's
UNRECOVERABLE data loading (because SQL Server's BCP load utility also has such
a feature, but for an empty table), how about an easier approach like MySQL? I
expect this won't complicate Postgres code much.
The c
65 matches
Mail list logo
