On Tue, Jun 11, 2019 at 9:47 PM Robert Haas wrote:
> On Tue, May 21, 2019 at 2:10 PM Robert Haas wrote:
> > Updated and rebased patches attached.
>
> And again.
>
Hi Robert,
I have tested the TOAST patches(v3) with different storage options
like(MAIN, EXTERNAL, EXTENDED, etc.), and
combination
Hello Daniel,
I want to measure TPS at a particular connection count. [...]
pgbench's "including connections establishing" number is polluted by
fact that for many seconds the benchmark is running with less than the
expected number of connections. I thought that was why the 'excluding'
nu
Hello Shawn, Alvaro,
Thank you for testing patches and comments.
Yes, there are two patches:
(1) v4_default_partition_pruning.patch fixes problems with default
partition pruning
and (2) v3_ignore_contradictory_where_clauses_at_partprune_step.patch determines
if a given clause contradicts a sub-par
On Fri, Jun 21, 2019 at 1:21 AM Thomas Munro wrote:
> I ran into someone with a system where big queries scanning 8GB+ of
> all-in-cache data took consistently ~2.5x longer on a primary server
> than on a replica. Both servers had concurrent activity on them but
> plenty of spare capacity and sim
On Mon, Jun 24, 2019 at 11:10:54PM +0300, Alexander Lakhin wrote:
> When running on REL_11_STABLE the following query:
> CREATE PROCEDURE test_ambiguous_procname(int) as $$ begin end; $$
> language plpgsql;
> CREATE PROCEDURE test_ambiguous_procname(text) as $$ begin end; $$
> language plpgsql;
> D
Short benchmark runs are bad if the runs aren't long enough to produce
consistent results.
Having to do long runs because a benchmarking tool 'converges to reality' over
time in reporting a tps number, due to miscalculation, is also bad.
I want to measure TPS at a particular connection count.
> In particular, in order to consider it unexpected, you have to suppose
>> that the content rules for postgresql.auto.conf are different from those
>> for postgresql.conf (wherein we clearly allow last-one-wins). Can you
>> point to any user-facing documentation that says that?
>
> The backend a
On 6/25/19 4:06 AM, Alvaro Herrera wrote:
> On 2019-Jun-24, Robert Haas wrote:
>
>> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
>>> All that said, whatever code it is that we write for pg_basebackup to
>>> do this properly should go into our client side library, so other tools
>>> can le
On Mon, Jun 24, 2019 at 11:47:09AM +0200, Dent John wrote:
> I’ll see if I can get the patch applied and feed back on how much it
> move towards making my use case a viable proposition.
There is another patch which provides more coverage for reloptions:
https://commitfest.postgresql.org/23/2064/
On Mon, Jun 24, 2019 at 11:27:26PM +0200, Peter Eisentraut wrote:
> Yeah but the new code already rejects those anyway. Note how
> timestamptz_in() has explicit switch cases to accept those, and we
> didn't carry those over into check_recovery_time().
Ditto. I was not paying much attention to th
On Mon, Jun 24, 2019 at 04:51:04PM -0700, Noah Misch wrote:
> On Mon, Jun 24, 2019 at 08:52:00AM -0400, Alvaro Herrera wrote:
>> On 2019-Jun-24, Michael Paquier wrote:
>>> Alvaro, did 313f56ce fix all the issues related to this thread?
>>
>> Yes, as far as I am aware it does.
>
> I agree, it did.
On Sun, Jun 23, 2019 at 10:29:25PM +0900, Michael Paquier wrote:
> So, are there any objections with this patch? Or do people think that
> it's too late for v12 and that it is better to wait until v13 opens
> for business?
Committed, and open item closed.
--
Michael
signature.asc
Description: P
On Mon, Jun 24, 2019 at 08:52:00AM -0400, Alvaro Herrera wrote:
> On 2019-Jun-24, Michael Paquier wrote:
> > On Fri, Jun 14, 2019 at 06:31:52PM -0400, Alvaro Herrera wrote:
> > > BTW I tested this manually and it seemed to work as intended, ie., if I
> > > change /etc/hosts for the hostname I am us
On Mon, Jun 24, 2019 at 4:16 PM Tomas Vondra
wrote:
>
> On Mon, Jun 24, 2019 at 01:00:50PM -0400, James Coleman wrote:
> >On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs wrote:
> >>
> >> On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
> >>>
> >>> On Thu, Jun 13, 2019 at 11:38:12PM -0400, James C
On 2019-06-24 06:06, Michael Paquier wrote:
> - if (strcmp(*newval, "epoch") == 0 ||
> - strcmp(*newval, "infinity") == 0 ||
> - strcmp(*newval, "-infinity") == 0 ||
> Why do you remove these? They should still be rejected because they
> make no sense as recovery targets,
On 2019-06-19 22:34, Peter Eisentraut wrote:
> src/include/common/unicode_norm_table.h also should be updated to the
> latest Unicode tables, as described in src/common/unicode. See attached
> patches. This also passes the tests described in
> src/common/unicode/README. (That is, the old code do
On 2019-06-19 21:55, Tom Lane wrote:
> Peter Eisentraut writes:
>>> Indeed. Here is an updated script and patch.
>
>> committed (to master)
>
> Cool, but should we also put your recalculation script into git, to help
> the next time we decide that we need to update this list? It's
> demonstrat
On Mon, Jun 24, 2019 at 07:05:24PM +0100, Simon Riggs wrote:
On Mon, 24 Jun 2019 at 18:01, James Coleman wrote:
On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs
wrote:
> What is the specific use case for this? This sounds quite general case.
They are both general cases in some sense, but the co
On Mon, Jun 24, 2019 at 01:00:50PM -0400, James Coleman wrote:
On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs wrote:
On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
>I think the first thing to do is get some concrete numbers on
Hello hackers,
When running on REL_11_STABLE the following query:
CREATE PROCEDURE test_ambiguous_procname(int) as $$ begin end; $$
language plpgsql;
CREATE PROCEDURE test_ambiguous_procname(text) as $$ begin end; $$
language plpgsql;
DROP PROCEDURE test_ambiguous_procname;
under valgrind I get th
Greetings,
* Sascha Kuhl (yogidaba...@gmail.com) wrote:
> Does Microsoft or any other DB manufacturer have an ear on this mailing
> list?
Many, many, many of the people who are on this mailing list work for DB
manufacturers.
I suspect that most of them are manufacturing PostgreSQL.
Thanks,
Ste
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Stephen and Magnus want a warning, because it's an indication that a
> > tool author, or *something* modified the file in an unexpected way, and
> > that we are having to do some kind of cleanup on the file because of i
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2019-Jun-24, Robert Haas wrote:
>
> > On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > > All that said, whatever code it is that we write for pg_basebackup to do
> > > this properly should go into our client side library
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> >> Ah, got it. So it seems like the correct behavior might be for
> >> ALTER SYSTEM to
> >> (a) run through the whole file and remove any conflicting lines;
> >> (b) ap
Stephen Frost writes:
> Stephen and Magnus want a warning, because it's an indication that a
> tool author, or *something* modified the file in an unexpected way, and
> that we are having to do some kind of cleanup on the file because of it.
But you're presuming something that not everybody agree
On 2019-Jun-24, Robert Haas wrote:
> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > All that said, whatever code it is that we write for pg_basebackup to do
> > this properly should go into our client side library, so other tools can
> > leverage that and avoid having to write it them
On 2019-Jun-23, Sascha Kuhl wrote:
> Does Microsoft or any other DB manufacturer have an ear on this mailing
> list?
This is a public mailing list, so anybody with an interest can subscribe
to it. If you search the archives, you might find a more explicit
answer to your question.
--
Álvaro Her
Does Microsoft or any other DB manufacturer have an ear on this mailing
list?
Sascha Kuhl
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> > All that said, whatever code it is that we write for pg_basebackup to do
> > this properly should go into our client side library, so other tools can
> > leverage that and avoid having to writ
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> > Ah, got it. So it seems like the correct behavior might be for
> > ALTER SYSTEM to
> > (a) run through the whole file and remove any conflicting lines;
> > (b) append new setting at the
Robert Haas writes:
> On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
>> Ah, got it. So it seems like the correct behavior might be for
>> ALTER SYSTEM to
>> (a) run through the whole file and remove any conflicting lines;
>> (b) append new setting at the end.
> That is exactly the behavior fo
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jun 21, 2019 at 11:24 AM Stephen Frost wrote:
> > That's not quite accurate, given that it isn't how the ALTER SYSTEM call
> > itself works, and clearly isn't how the authors of that feature expected
> > things to work or they woul
On Thu, 20 Jun 2019 at 00:31, Andres Freund wrote:
>
> > > Or else, do you think we can just increment the record pointer by
> > > doing something like (lastReplayedEndRecPtr % XLOG_BLCKSZ) +
> > > SizeOfXLogShortPHD() ?
> >
> > I found out that we can't do this, because we don't know whether the
On Mon, 24 Jun 2019 at 18:01, James Coleman wrote:
> On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs
> wrote:
>
> > What is the specific use case for this? This sounds quite general case.
>
> They are both general cases in some sense, but the concerns lie mostly
> with what happens when they're une
Hi,
On 2019-06-24 10:41:06 -0700, Ashwin Agrawal wrote:
> Proposing following changes to make predicate locking and checking
> functions generic and remove dependency on HeapTuple and Heap AM. We
> made these changes to help with Zedstore. I think the changes should
> help Zheap and other AMs in g
On Mon, Jun 3, 2019 at 5:24 PM Ashwin Agrawal wrote:
> There were few more minor typos I had collected for table am, passing them
> along here.
>
> Some of the required callback functions are missing Assert checking (minor
> thing), adding them in separate patch.
>
Curious to know if need to reg
On 2019-Jun-22, Alexander Korotkov wrote:
> 2. Also introduce FullMultixactId, and apply to MultixactId the
> similar change as #1.
> 3. Change SLRU on-disk format to handle 64-bit xids and multixacts.
> In particular make SLRU page numbers 64-bit too. Add SLRU upgrade
> procedure to pg_upgrade.
Proposing following changes to make predicate locking and checking
functions generic and remove dependency on HeapTuple and Heap AM. We
made these changes to help with Zedstore. I think the changes should
help Zheap and other AMs in general.
- Change PredicateLockTuple() to PredicateLockTID(). So,
On Sat, Jun 22, 2019 at 5:13 PM Stephen Frost wrote:
> All that said, whatever code it is that we write for pg_basebackup to do this
> properly should go into our client side library, so other tools can leverage
> that and avoid having to write it themselves.
That is probably only going to help
On Fri, Jun 21, 2019 at 12:55 PM Tom Lane wrote:
> Ah, got it. So it seems like the correct behavior might be for
> ALTER SYSTEM to
> (a) run through the whole file and remove any conflicting lines;
> (b) append new setting at the end.
That is exactly the behavior for which I am arguing. Stephe
On Fri, Jun 21, 2019 at 11:24 AM Stephen Frost wrote:
> That's not quite accurate, given that it isn't how the ALTER SYSTEM call
> itself works, and clearly isn't how the authors of that feature expected
> things to work or they would have actually made it work. They didn't,
> and it doesn't actu
On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs wrote:
>
> On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
>>
>> On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
>> >I think the first thing to do is get some concrete numbers on performance
>> >if we:
>> >
>> >1. Only sort one group
On Mon, 24 Jun 2019 at 16:10, James Coleman wrote:
> On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
> >I think the first thing to do is get some concrete numbers on performance
> if we:
> >
> >1. Only sort one group at a time.
> >2. Update the costing to prefer traditional sort un
On Wed, 5 Jun 2019 at 17:14, Rafia Sabih wrote:
> Regarding this, I came across this,
> /*
> * Incremental sort can't be used with either EXEC_FLAG_REWIND,
> * EXEC_FLAG_BACKWARD or EXEC_FLAG_MARK, because we hold only current
> * bucket in tuplesortstate.
> */
> I think that is quite un
I wrote:
> > I'll look for other rules that could be more
> > easily optimized, but I'm not terribly optimistic.
>
> I found a possible other way to bring the size of the transition table
> under 32k entries while keeping the existing no-backup rules in place:
> Replace the "quotecontinue" rule wi
On 2019-06-20 18:33, Andres Freund wrote:
> I wonder if we need to split the timeout into two: One value for
> postmaster to acknowledge the action, one for that action to
> complete. It seems to me that that'd be useful for all of starting,
> restarting and stopping.
>
> I think we have all the n
Thomas Munro writes:
> Hmm. I wonder if we should rename force_parallel_mode to
> force_gather_node in v13. The current name has always seemed slightly
> misleading to me; it sounds like some kind of turbo boost button but
> really it's a developer-only test mode. Also, does it belong under
> D
Hi,
On June 24, 2019 8:19:13 AM PDT, Robert Haas wrote:
>On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov
> wrote:
>> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro
>wrote:
>> > Thanks for the reviews! Pushed.
>>
>> Any ideas we should move towards 64-bit xids in more places? That
>has
>> been
On Mon, Jun 24, 2019 at 11:21 AM Tom Lane wrote:
> > I'm repeating myself, but I still think it's super-useful to
> > distinguish things which are "for expert use only" from things which
> > are "totally bonkers."
>
> Agreed, although "DML vs DDL" is a pretty poor approximation of that
> boundary.
Robert Haas writes:
> On Fri, Jun 21, 2019 at 4:37 PM Tom Lane wrote:
>> This line of thought leads to the conclusion that we do want
>> separate "allow_system_table_dml" and "allow_system_table_ddl"
>> bools. Otherwise, the backwards-compatibility hack would need
>> to turn on a level of unsafe
On Fri, Jun 21, 2019 at 7:01 PM Alexander Korotkov
wrote:
> On Thu, Mar 28, 2019 at 8:30 AM Thomas Munro wrote:
> > Thanks for the reviews! Pushed.
>
> Any ideas we should move towards 64-bit xids in more places? That has
> been discussed several times already. I think last time it was
> discu
On Thu, Jun 13, 2019 at 11:38:12PM -0400, James Coleman wrote:
>I think the first thing to do is get some concrete numbers on performance if
>we:
>
>1. Only sort one group at a time.
>2. Update the costing to prefer traditional sort unless we have very
>high confidence we'll win with incremental s
On Fri, Jun 21, 2019 at 3:45 AM RekGRpth wrote:
> >It is not plpgsql's job to clean up after other backend subsystems
> during a transaction abort.
> But plpgsql do clean up on success! I suggest only do cleanup and on
> exception.
Except that's wrong, because when an error happens, cleanup is -
Thomas Munro writes:
> In commit a76200de we added a line to unset MAKELEVEL to fix a problem
> with our temp-install logic. I don't think it was a great idea to
> clear MAKEFLAGS at the same time, because now when you type "make -s
> -j8" on a non-GNU system it ignores you and is loud and slow.
On Fri, Jun 21, 2019 at 6:54 PM Tom Lane wrote:
> > That's not a bad goal, although invoking a user-supplied callback
> > while holding a buffer lock is a little scary.
>
> I nominate Robert for Understater of the Year. I think there's pretty
> much 0 chance of that working reliably.
It's an hon
On Fri, Jun 21, 2019 at 4:37 PM Tom Lane wrote:
> This line of thought leads to the conclusion that we do want
> separate "allow_system_table_dml" and "allow_system_table_ddl"
> bools. Otherwise, the backwards-compatibility hack would need
> to turn on a level of unsafety that extension scripts h
On Thu, Jun 20, 2019 at 5:00 PM David Fetter wrote:
> Is there perhaps a way to make raising max_connections not require a
> restart? There are plenty of situations out there where restarts
> aren't something that can be done on a whim.
Sure, if you want to make this take about 100x more work.
-
On Mon, 24 Jun 2019 at 00:42, Tomas Vondra wrote:
>
> On Sun, Jun 23, 2019 at 10:23:19PM +0200, Tomas Vondra wrote:
> >On Sun, Jun 23, 2019 at 08:48:26PM +0100, Dean Rasheed wrote:
> >>On Sat, 22 Jun 2019 at 15:10, Tomas Vondra
> >>wrote:
> >>>One annoying thing I noticed is that the base_freque
On Mon, Jun 24, 2019 at 01:44:14PM +0200, Dmitry Dolgov wrote:
On Sun, Jun 23, 2019 at 1:04 PM Floris Van Nee wrote:
However, _bt_readpage messes things up, because it only reads tuples that
match all the provided keys (so where b=2)
Right, the problem you've reported first had a similar orig
On Sat, Apr 7, 2018 at 4:56 PM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> I agree with that. For bounded sort, attached patch now selects minimal
> group
> size as Min(DEFAULT_MIN_GROUP_SIZE, bound). That should improve
> "LIMIT small_number" case.
As I was working on som
On 6/23/19 10:27 PM, Michael Paquier wrote:
> On Sun, Jun 23, 2019 at 06:15:06PM -0400, Andrew Dunstan wrote:
>> Alvaro pointed out to me recently that the buildfarm client doesn't have
>> any provision for running module tests like commit_ts and
>> snapshot_too_old that use NO_INSTALLCHECK. On l
>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>Sent: Friday, April 26, 2019 11:50 PM
>To: 'Kyotaro HORIGUCHI' ;
>thomas.mu...@enterprisedb.com; robertmh...@gmail.com
>Cc: pgsql-hack...@postgresql.org
>Subject: RE: Copy data to DSA area
>
>Hi, I've updated Thomas's quick PoC.
Hi.
On 2019-Jun-24, Michael Paquier wrote:
> On Fri, Jun 14, 2019 at 06:31:52PM -0400, Alvaro Herrera wrote:
> > BTW I tested this manually and it seemed to work as intended, ie., if I
> > change /etc/hosts for the hostname I am using between one connection and
> > the next, we do keep the hostaddr if
> On Sun, Jun 23, 2019 at 1:04 PM Floris Van Nee
> wrote:
>
> However, _bt_readpage messes things up, because it only reads tuples that
> match all the provided keys (so where b=2)
Right, the problem you've reported first had a similar origins. I'm starting to
think that probably using _bt_readp
Hi!
> 24 июня 2019 г., в 15:08, Darafei Komяpa Praliaskouski
> написал(а):
>
> I'm looking at PostGIS geometry GiST index build times and try to optimize
> withing the current GiST framework. The function that shows a lot on my flame
> graphs is penalty.
>
> I spent weekend rewriting PostGI
On Mon, 24 Jun 2019 at 22:16, Michael Paquier wrote:
>
> On Sat, Jun 15, 2019 at 12:25:12PM +1200, David Rowley wrote:
> > With the attached version I'm just calling table_finish_bulk_insert()
> > once per partition at the end of CopyFrom(). We've got an array with
> > all the ResultRelInfos we t
On Sat, Jun 15, 2019 at 12:25:12PM +1200, David Rowley wrote:
> With the attached version I'm just calling table_finish_bulk_insert()
> once per partition at the end of CopyFrom(). We've got an array with
> all the ResultRelInfos we touched in the proute, so it's mostly a
> matter of looping over
Hi,
I'm looking at PostGIS geometry GiST index build times and try to optimize
withing the current GiST framework. The function that shows a lot on my
flame graphs is penalty.
I spent weekend rewriting PostGIS penalty to be as fast as possible.
(FYI https://github.com/postgis/postgis/pull/425/fil
Michael Paquier writes:
> On Sun, Jun 23, 2019 at 09:56:40PM +0200, Peter Eisentraut wrote:
>> On 2019-06-21 15:45, Dagfinn Ilmari Mannsåker wrote:
>>> Also, on Linux it requires libbsd: https://libbsd.freedesktop.org/
>>
>> No, it's in glibc.
>
> From man:
> explicit_bzero() first appeared in g
Thank you, Tom.
(And sorry for the delay following up.)
I’ve marked myself down for review for this patch in the next CF.
I’ll see if I can get the patch applied and feed back on how much it move
towards making my use case a viable proposition.
d.
> On 9 Jun 2019, at 17:21, Tom Lane wrote:
I wrote:
> I'll look for other rules that could be more
> easily optimized, but I'm not terribly optimistic.
I found a possible other way to bring the size of the transition table
under 32k entries while keeping the existing no-backup rules in place:
Replace the "quotecontinue" rule with a new st
> 18 мая 2019 г., в 11:44, Andrey Borodin написал(а):
>
Hi!
Here's rebased version of patches.
Best regards, Andrey Borodin.
0001-Use-memcpy-in-pglz-decompression-for-long-matches.patch
Description: Binary data
0001-Use-memcpy-in-pglz-decompression.patch
Description: Binary data
On Fri, Jun 14, 2019 at 06:31:52PM -0400, Alvaro Herrera wrote:
> BTW I tested this manually and it seemed to work as intended, ie., if I
> change /etc/hosts for the hostname I am using between one connection and
> the next, we do keep the hostaddr if it was specified, or we resolve the
> name agai
Hi,
patch no longer applies (as of 12beta2).
postgres@ubuntudev:~/pg_testing/source/postgresql-12beta2$ patch -p1 <
drop-database-force-20190310_01.patch
patching file doc/src/sgml/ref/drop_database.sgml
patching file doc/src/sgml/ref/dropdb.sgml
patching file src/backend/commands/dbcommands.c
H
Heikki,
On Thu, Apr 04, 2019 at 06:15:21PM +0300, Heikki Linnakangas wrote:
> I think we should fix this in a similar manner in B-tree, too, but that can
> be done separately. For B-tree, we need to worry about
> backwards-compatibility, but that seems simple enough; we just need to
> continue to
Hi,
In commit a76200de we added a line to unset MAKELEVEL to fix a problem
with our temp-install logic. I don't think it was a great idea to
clear MAKEFLAGS at the same time, because now when you type "make -s
-j8" on a non-GNU system it ignores you and is loud and slow.
Admittedly there is somet
76 matches
Mail list logo
