On Tue, Jun 9, 2020 at 2:32 PM Michael Paquier wrote:
> Looks fine to me. Are you planning to send an extra patch to switch
> BufFileWrite() to void for 14~?
Thanks! Pushed. I went ahead and made it void in master only.
On Mon, Jun 15, 2020 at 10:29:41PM +0900, Michael Paquier wrote:
> Attempting to run installcheck with 13~ and a value of work_mem lower
> than the default causes two failures, both related to incremental
> sorts (here work_mem = 1MB):
> 1) Test incremental_sort:
> @@ -4,12 +4,13 @@
> select *
On Mon, Jun 15, 2020 at 4:54 PM Tom Lane wrote:
> Meh. That's carrying PC naming foibles to the point where they
> negatively affect our users (by breaking start scripts and such).
> I think we should leave this alone.
+1. Apart from the practical considerations, I just don't see a
problem with
At Tue, 16 Jun 2020 01:46:21 +0900, Fujii Masao
wrote in
> > In short, it is known behavior but it was judged as useless to prevent
> > that.
> > That can happen when checkpointer removes up to the segment that is
> > being read by walsender. I think that that doesn't happen (or
> >
On Tue, 16 Jun 2020 at 08:48, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-06-15 13:15, Ashutosh Bapat wrote:
> > Here are some comments
> > I see below in the .out but there's not corresponding SQL in .sql.
> > +SELECT factorial(-4);
> > + factorial
> > +---
> >
Hello Dagfinn,
The attached patch makes the first mention of another system catalog or
view (as well as pg_hba.conf in pg_hba_file_lines) a link, for easier
navigation.
Why only the first mention? It seems unlikely that I would ever read such
chapter linearly, and even so that I would want
On Mon, Jun 15, 2020 at 11:49:33PM -0300, Ranier Vilela wrote:
> I can confirm that the problem is in pgrename (dirmod.c),
> something is not OK, with MoveFileEx, even with the
> (MOVEFILE_REPLACE_EXISTING) flag.
>
> Replacing MoveFileEx, with
> unlink (to);
> rename (from, to);
>
> #if defined
On Mon, Jun 15, 2020 at 11:33:42PM -0300, Ranier Vilela wrote:
> With Postgres 13, Windows 10 (home), msvc 2019 64 bits,
> Shutting down, without interrupting the database, consistently, this log
> has appeared.
>
> 2020-06-15 21:40:35.998 -03 [3380] LOG: database system shutdown was
>
On Mon, Jun 15, 2020 at 09:49:31AM -0300, Ranier Vilela wrote:
> II already reported on another thread, that vcregress is failing with
> (float8 and partitionprune) and now these messages are showing up.
> None buildfarm animal, have that combination, but as Postgres officially
> supports it ..
On 2020-06-15 13:15, Ashutosh Bapat wrote:
Here are some comments
I see below in the .out but there's not corresponding SQL in .sql.
+SELECT factorial(-4);
+ factorial
+---
+ 1
+(1 row)
+
Should we also add -4! to cover both function as well as the operator?
I will add that.
At Mon, 15 Jun 2020 18:59:49 +0900, Fujii Masao
wrote in
> > It was a kind of hard to decide. Even when max_slot_wal_keep_size is
> > smaller than max_wal_size, the segments more than
> > max_slot_wal_keep_size are not guaranteed to be kept. In that case
> > the state transits as NORMAL->LOST
I can confirm that the problem is in pgrename (dirmod.c),
something is not OK, with MoveFileEx, even with the
(MOVEFILE_REPLACE_EXISTING) flag.
Replacing MoveFileEx, with
unlink (to);
rename (from, to);
#if defined (WIN32) &&! defined (__ CYGWIN__)
unlink(to);
while (rename (from, to)! = 0)
On Mon, 2020-06-15 at 11:19 -0400, Robert Haas wrote:
> On Mon, Jun 15, 2020 at 9:34 AM Tomas Vondra
> wrote:
> > But just reverting 4cad2534d will make this much worse, I think, as
> > illustrated by the benchmarks I did in [1].
>
> I share this concern, although I do not know what we should do
Em seg., 15 de jun. de 2020 às 10:14, Michael Paquier
escreveu:
> Hi all,
>
> I have begun my annual study of WAL consistency across replays, and
> wal_consistency_checking = 'all' is pointing out at some issues with
> at least VACUUM and SPGist:
> FATAL: inconsistent page found, rel
Hi,
On 2020-06-09 17:04:42 -0400, Robert Haas wrote:
> On Tue, Jun 9, 2020 at 3:37 PM Andres Freund wrote:
> > Hm. Looking at this again, perhaps the better fix would be to simply not
> > look at the concrete values of the barrier inside the signal handler?
> > E.g. we could have a new
On Mon, Jun 15, 2020 at 09:33:05PM +0800, 李杰(慎追) wrote:
> This is a good idea.
> We should maintain the consistency of the entire partition table.
> However, this is not a small change in the code.
> May be we need to make a new design for DefineIndex function
Indeed. I have looked at the
"tsunakawa.ta...@fujitsu.com" writes:
> From: Daniel Gustafsson
>> That's less good. The W3C Web Accessibility Initiative has guidance for
>> multi-level header tables which might be useful here.
>> https://www.w3.org/WAI/tutorials/tables/multi-level/
>> Maybe if we use the id and headers
On Sat, Jun 13, 2020 at 08:46:36AM -0400, Bruce Momjian wrote:
> On Wed, Jun 10, 2020 at 04:07:05PM +0200, Laurenz Albe wrote:
> > A customer's upgrade failed, and it took me a while to
> > figure out that the problem was that they had set
> > "vacuum_defer_cleanup_age=1" on the new cluster.
>
Hi,
On 2020-06-15 19:54:25 -0400, Tom Lane wrote:
> Daniel Gustafsson writes:
> > On 15 Jun 2020, at 20:22, Andres Freund wrote:
> >> 1) 'postmaster'. As changing that would be somewhat invasive, the word
> >> is a bit more ambiguous, and it's largely just internal, I've left
> >> this alone
From: Daniel Gustafsson
> Yes, this was a deliberate change made to be able to fit more expansive
> descriptions of columns etc.
Thanks for your quick response and information. I'm relieved to know that it
was not broken.
> That's less good. The W3C Web Accessibility Initiative has guidance
Daniel Gustafsson writes:
> On 15 Jun 2020, at 20:22, Andres Freund wrote:
>> 1) 'postmaster'. As changing that would be somewhat invasive, the word
>> is a bit more ambiguous, and it's largely just internal, I've left
>> this alone for now. I personally would rather see this renamed as
>>
On Tue, Jun 16, 2020 at 09:53:34AM +1200, Thomas Munro wrote:
> On Tue, Jun 16, 2020 at 7:04 AM Daniel Gustafsson wrote:
> > > On 15 Jun 2020, at 20:22, Andres Freund wrote:
> >
> > Thanks for picking this up!
> >
> > > 1) 'postmaster'. As changing that would be somewhat invasive, the word
> > >
On Tue, Jun 16, 2020 at 7:04 AM Daniel Gustafsson wrote:
> > On 15 Jun 2020, at 20:22, Andres Freund wrote:
>
> Thanks for picking this up!
>
> > 1) 'postmaster'. As changing that would be somewhat invasive, the word
> > is a bit more ambiguous, and it's largely just internal, I've left
> >
On Tue, 16 Jun 2020 at 03:29, Robert Haas wrote:
>
> On Sat, Jun 13, 2020 at 2:13 AM Amit Kapila wrote:
> > The performance can vary based on qualification where some workers
> > discard more rows as compared to others, with the current system with
> > step-size as one, the probability of
On Mon, Apr 27, 2020 at 2:07 PM Robert Haas wrote:
> > I'd lean mildly to holding 0002 until after we branch. It probably
> > won't break anything, but it probably won't fix anything either.
>
> True.
Committed now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Internally pg_dump have capability to filter the table data to dump by same
filter clause but it have no interface to use it and the patch here [1]
adds interface to it but it have at-least two issue, one is error message
in case of incorrect where clause specification is somehow hard to debug
and
> On 15 Jun 2020, at 20:22, Andres Freund wrote:
Thanks for picking this up!
> 1) 'postmaster'. As changing that would be somewhat invasive, the word
> is a bit more ambiguous, and it's largely just internal, I've left
> this alone for now. I personally would rather see this renamed as
>
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
>
>> The attached patch makes the first mention of another system catalog or
>> view (as well as pg_hba.conf in pg_hba_file_lines) a link, for easier
>> navigation.
>
> bump...
Added to
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> The attached patch makes the first mention of another system catalog or
> view (as well as pg_hba.conf in pg_hba_file_lines) a link, for easier
> navigation.
bump...
- ilmari
--
"A disappointingly low fraction of the human race is,
at any
On 2020/06/15 13:42, Kyotaro Horiguchi wrote:
At Sat, 13 Jun 2020 01:38:49 +0900, Fujii Masao
wrote in
Hi,
The document explains that "lost" value that
pg_replication_slots.wal_status reports means
some WAL files are definitely lost and this slot cannot be used to
resume
Robert Haas writes:
> On Mon, Jun 15, 2020 at 9:34 AM Tomas Vondra
> wrote:
>> But just reverting 4cad2534d will make this much worse, I think, as
>> illustrated by the benchmarks I did in [1].
> I share this concern, although I do not know what we should do about it.
Well, it's only June.
Attached a log.
I hacked dirmod.c (pgrename), to print GetLastError();
MoveFIleEx from: pg_stat_tmp/global.tmp
MoveFIleEx to: pg_stat_tmp/global.stat
MoveFIleEx win32 error code 5
regards,
Ranier Vilela
logfile
Description: Binary data
On Sat, Jun 13, 2020 at 2:13 AM Amit Kapila wrote:
> The performance can vary based on qualification where some workers
> discard more rows as compared to others, with the current system with
> step-size as one, the probability of unequal work among workers is
> quite low as compared to larger
On Mon, Jun 15, 2020 at 9:34 AM Tomas Vondra
wrote:
> But just reverting 4cad2534d will make this much worse, I think, as
> illustrated by the benchmarks I did in [1].
I share this concern, although I do not know what we should do about it.
--
Robert Haas
EnterpriseDB:
... oh, one slightly more important nit-pick: per the catalogs and
code, the function is factorial(bigint):
Schema | Name| Result data type | Argument data types | Type
+---+--+-+--
pg_catalog | factorial | numeric
On Mon, Jun 15, 2020 at 12:14:55AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Well, I thought we copied everything except things tha can be specified
> > as different in CREATE DATABASE, though I can see why we would not copy
> > them. Should we document this or issue a notice about not
Thanks Amit for the clarifications. Regarding partitioned table, one of the
question was - if we are loading data into a partitioned table using COPY
command, then the input file would contain tuples for different tables
(partitions) unlike the normal table case where all the tuples in the input
Peter Eisentraut writes:
> Adjacent to the discussion in [0] I wanted to document the factorial()
> function and expand the tests for that slightly with some edge cases.
> ...
> I propose to change this to error out for negative numbers.
+1 for all of this, with a couple trivial nitpicks about
On Mon, 15 Jun 2020 at 15:20, Amit Kapila wrote:
>
> On Sun, Jun 14, 2020 at 2:21 PM Tatsuo Ishii wrote:
> >
> > >> Won't it create an inconsistency in viewing the data from the
> > >> different servers? Say, such a transaction inserts one row into a
> > >> local server and another into the
On Sun, Jun 14, 2020 at 11:09:55PM -0700, Jeff Davis wrote:
On Sun, 2020-06-14 at 11:14 -0700, Andres Freund wrote:
I'm somewhat inclined to think that we should revert 4cad2534da6 and
then look at how precisely to tackle this in 14.
I'm fine with that.
I don't see how we could just revert
> That's a problem. I really think that we should make the steps of the
> concurrent operation consistent across all relations, meaning that all
> the indexes should be created as invalid for all the parts of the
> partition tree, including partitioned tables as well as their
> partitions, in the
Hi all,
Attempting to run installcheck with 13~ and a value of work_mem lower
than the default causes two failures, both related to incremental
sorts (here work_mem = 1MB):
1) Test incremental_sort:
@@ -4,12 +4,13 @@
select * from (select * from tenk1 order by four) t order by four, ten;
Hi all,
I have begun my annual study of WAL consistency across replays, and
wal_consistency_checking = 'all' is pointing out at some issues with
at least VACUUM and SPGist:
FATAL: inconsistent page found, rel 1663/16385/22133, forknum 0,
blkno 15
CONTEXT: WAL redo at 0/739CEDE8 for
Em dom., 14 de jun. de 2020 às 23:53, Justin Pryzby
escreveu:
> On Fri, Jun 12, 2020 at 03:15:52PM -0300, Ranier Vilela wrote:
> > Posgres13_beta1, is consistently writing to the logs, "could not rename
> > temporary statistics file".
> > When analyzing the source that writes the log, I
On Mon, Jun 15, 2020 at 9:12 AM Dilip Kumar wrote:
>
> On Fri, Jun 12, 2020 at 4:35 PM Amit Kapila wrote:
> >
>
> > > Basically, this part is still
> > > I have to work upon, once we get the consensus then I can remove those
> > > extra wait event from the patch.
> > >
> >
> > Okay, feel free
Em dom., 14 de jun. de 2020 às 23:08, Michael Paquier
escreveu:
> On Fri, Jun 12, 2020 at 03:15:52PM -0300, Ranier Vilela wrote:
> > Posgres13_beta1, is consistently writing to the logs, "could not rename
> > temporary statistics file".
> > When analyzing the source that writes the log, I
On Mon, Jun 15, 2020 at 08:15:05PM +0800, 李杰(慎追) wrote:
> As shown above, an error occurred while creating an index in the second
> partition.
> It can be clearly seen that the index of the partitioned table is invalid
> and the index of the first partition is normal, the second partition is
>
On Fri, Jun 12, 2020 at 09:13:02PM +0900, Michael Paquier wrote:
> I have merged 0003 and 0004 together and applied them. 0005 seems to
> have a separate issue as mentioned upthread, and I have not really
> looked at 0001 and 0002. Thanks.
And committed 0001 and 0002 after some tiny adjustments
> My (tentative) understanding is that these types of things should use a
> "subtransaction" internally.. So if the toplevel transaction rolls back, its
> changes are lost. In some cases, it might be desirable to not roll back, in
> which case the user(client) should first create indexes
Sorry for the reply.
On 2020/06/08 15:52, Michael Paquier wrote:
On Fri, Jun 05, 2020 at 10:25:00PM +0900, Inoue, Hiroshi wrote:
Keyset-driven cursors always detect changes made by other applications
(and themselves). currtid() is necessary to detect the changes.
CTIDs are changed by updates
On Mon, Jun 15, 2020 at 12:41 PM Peter Eisentraut
wrote:
>
> Adjacent to the discussion in [0] I wanted to document the factorial()
> function and expand the tests for that slightly with some edge cases.
>
> I noticed that the current implementation returns 1 for the factorial of
> all negative
Hi,
Attached is the patch supporting parallel copy for binary format files.
The performance improvement achieved with different workers is as shown
below. Dataset used has 10million tuples and is of 5.3GB size.
parallel workers test case 1(exec time in sec): copy from binary file, 2
indexes on
On Mon, Jun 15, 2020 at 12:30 PM Tatsuo Ishii wrote:
>
> >> Another approach to the atomic visibility problem is to control
> >> snapshot acquisition timing and commit timing (plus using REPEATABLE
> >> READ). In the REPEATABLE READ transaction isolation level, PostgreSQL
> >> assigns a snapshot
On Thu, Jun 11, 2020 at 10:00 PM Tom Lane wrote:
>
> Alexander Korotkov writes:
> > On Thu, Jun 11, 2020 at 3:45 PM Tom Lane wrote:
> >> It is entirely clear from the code, the documentation,
> >> and the relevant RFCs that JSONB does not allow NaNs as numeric
> >> values.
>
> > The JSONB
On 2020/06/15 13:42, Kyotaro Horiguchi wrote:
At Sat, 13 Jun 2020 01:38:49 +0900, Fujii Masao
wrote in
Hi,
The document explains that "lost" value that
pg_replication_slots.wal_status reports means
some WAL files are definitely lost and this slot cannot be used to
resume
On 6/15/20 1:29 PM, Kyotaro Horiguchi wrote:
Thanks for testing, but..
At Mon, 15 Jun 2020 08:51:23 +0500, "Andrey V. Lepikhov"
wrote in
The patch has a problem with partitionwise aggregates.
Asynchronous append do not allow the planner to use partial
aggregates. Example you can see in
Here is an updated patch that I think fixes all the cases that you
identified. (The issue of what kinds of constants or expressions to
accept for cycle marks has not been touched.) To fix the star expansion
I had to add a little bit of infrastructure that could also be used as a
more general
On Fri, 12 Jun 2020 at 02:16, Tom Lane wrote:
>
> * I had to invent some semantics for non-standardized functions,
> particularly numeric_mod, numeric_gcd, numeric_lcm. This area
> could use review to be sure that I chose desirable behaviors.
>
I think the semantics you've chosen for
> On 15 Jun 2020, at 09:49, tsunakawa.ta...@fujitsu.com wrote:
> Is this intentional?
Yes, this was a deliberate change made to be able to fit more expansive
descriptions of columns etc.
> It has become a bit unfriendly to read for me, a visually impaired user who
> uses screen reader
Thanks for testing, but..
At Mon, 15 Jun 2020 08:51:23 +0500, "Andrey V. Lepikhov"
wrote in
> The patch has a problem with partitionwise aggregates.
>
> Asynchronous append do not allow the planner to use partial
> aggregates. Example you can see in attachment. I can't understand why:
> costs
Hello,
The tables for pg_stat_ views in the following page, starting from Table 27.3,
have only one column in PG 13. They had 3 columns in PG 12 and earlier.
https://www.postgresql.org/docs/13/monitoring-stats.html
Is this intentional? It has become a bit unfriendly to read for me, a
On 2020/06/12 18:41, movead...@highgo.ca wrote:
Hello hackers,
Currently, I do some changes based on the last version:
1. Catch up to the current commit (c2bd1fec32ab54).
2. Add regression and document.
3. Add support to switch from xid-base snapshot to csn-base snapshot,
and the same with
On Sun, Jun 14, 2020 at 08:45:17PM -0700, Mark Wong wrote:
> Sounds good to me. Something more like the attached patch?
That's the idea. I have not gone in details into what you have here,
but perhaps it would make sense to do a bit more and show how things
are done in the context of a PL
On Mon, Jun 15, 2020 at 5:00 PM Michael Paquier wrote:
> On Fri, Dec 28, 2018 at 02:21:44PM +1300, Thomas Munro wrote:
> > Just to be clear, although this patch is registered in the commitfest
> > and currently applies and tests pass, it is prototype/WIP code with
> > significant problems that
At Mon, 15 Jun 2020 13:44:31 +0900, Michael Paquier wrote
in
> On Mon, Jun 15, 2020 at 12:40:03PM +0900, Fujii Masao wrote:
> > BTW, I just wonder why each row in pg_replication_slots needs to have
> > min_safe_lsn column? Basically min_safe_lsn should be the same between
> > every replication
At Mon, 15 Jun 2020 13:42:25 +0900 (JST), Kyotaro Horiguchi
wrote in
> Oops! I don't want to believe I did that but it's definitely wrong.
Hmm. Quite disappointing. The patch was just a crap.
This is the right patch.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
diff --git
Adjacent to the discussion in [0] I wanted to document the factorial()
function and expand the tests for that slightly with some edge cases.
I noticed that the current implementation returns 1 for the factorial of
all negative numbers:
SELECT factorial(-4);
factorial
---
1
>> Another approach to the atomic visibility problem is to control
>> snapshot acquisition timing and commit timing (plus using REPEATABLE
>> READ). In the REPEATABLE READ transaction isolation level, PostgreSQL
>> assigns a snapshot at the time when the first command is executed in a
>>
On Mon, Jun 15, 2020 at 12:44:02AM -0400, Tom Lane wrote:
> FWIW, I'd have included a catversion bump in this, to enforce that
> the modified backend functions are used with matching pg_proc entries.
> It's not terribly important at this phase of the devel cycle, but still
> somebody might wonder
On Sat, Jun 13, 2020 at 03:00:54PM +0900, Michael Paquier wrote:
> My take would be to actually enforce that as a requirement for 14~ if
> that works reliably, and of course not backpatch that change as that's
> clearly an improvement and not a bug fix. It would be good to check
> the status of
On Sun, Jun 14, 2020 at 2:21 PM Tatsuo Ishii wrote:
>
> >> Won't it create an inconsistency in viewing the data from the
> >> different servers? Say, such a transaction inserts one row into a
> >> local server and another into the foreign server. Now, if we follow
> >> the above protocol, the
On Sun, 2020-06-14 at 11:14 -0700, Andres Freund wrote:
> I'm somewhat inclined to think that we should revert 4cad2534da6 and
> then look at how precisely to tackle this in 14.
I'm fine with that.
> It'd probably make sense to request small tlists when the number of
> estimated groups is large,
72 matches
Mail list logo
