On Wed, Dec 11, 2019 at 10:45:25AM -0500, Stephen Frost wrote:
> I'm confused- wouldn't the above approach be a function that's returning
> only one row, if you had a bunch of columns and then had NULL values for
> those cases that didn't apply..? Or, if you were thinking about the SRF
> approach
On Fri, Dec 13, 2019 at 11:08 AM Masahiko Sawada
wrote:
>
> On Fri, 13 Dec 2019 at 14:19, Amit Kapila wrote:
> >
> > > > >
> > > > > How about adding an additional argument to ReinitializeParallelDSM()
> > > > > that allows the number of workers to be reduced? That seems like it
> > > > > would b
On Fri, Dec 6, 2019 at 5:30 PM Amit Kapila wrote:
>
> On Mon, Nov 25, 2019 at 8:25 PM Jehan-Guillaume de Rorthais
> wrote:
> >
> > On Wed, 6 Nov 2019 14:34:38 +0100
> > Peter Eisentraut wrote:
> >
> > > On 2019-11-05 17:29, Jehan-Guillaume de Rorthais wrote:
> > > > My best bet so far is that lo
Will Leinweber writes:
> On 12.1, fresh initdb the following query gives me the error
> "ERROR: failed to construct the join relation"
I'm getting an assertion failure in an assert-enabled build, here:
(gdb) f 3
#3 0x006f382a in create_lateral_join_info (root=0x2d380c8)
at initspla
At Fri, 13 Dec 2019 13:05:41 +0800, Craig Ringer wrote
in
> On Wed, 11 Dec 2019 at 02:08, Alvaro Herrera
> wrote:
>
> > On 2019-Dec-10, Tomas Vondra wrote:
> >
> > > On Tue, Dec 10, 2019 at 09:42:17AM +0900, Kyotaro Horiguchi wrote:
> > > > At Tue, 10 Dec 2019 00:44:09 +0100, Tomas Vondra <
>
Hi Asaba,
On Thu, Dec 12, 2019 at 7:51 AM asaba.takan...@fujitsu.com <
asaba.takan...@fujitsu.com> wrote:
> Hello Surafel,
>
> I'm very interested in this patch.
> Although I'm a beginner,I would like to participate in the development of
> PostgreSQL.
>
>
> 1. I want to suggest new output format.
On Mon, 9 Dec 2019 at 23:35, Julien Delplanque
wrote:
> Hello PostgreSQL hackers,
>
> I hope I am posting on the right mailing-list.
>
> I am actually doing a PhD related to relational databases and software
> engineering.
>
> I use PostgreSQL for my research.
>
> I have a few questions about the
Hi,
On 2019-12-13 13:31:55 +0800, Craig Ringer wrote:
> Am I stabbing completely in the dark when wondering if this might be a step
> towards a way to lift the size limit on VARLENA Datums like bytea ?
It could be - but I think it'd be a pretty small piece of it. But yes, I
have mused about that.
On Thu, Dec 12, 2019, Justin Pryzby wrote in
20191212180506.gr2...@telsasoft.com:
> Actually, I tried using pg_ls_tmpdir(), but it unconditionally masks
> non-regular files and thus shared filesets. Maybe that's worth discussion on
> a
> new thread ?
>
> src/backend/utils/adt/genfile.c
>
On Fri, 13 Dec 2019 at 14:19, Amit Kapila wrote:
>
> On Fri, Dec 13, 2019 at 10:03 AM Masahiko Sawada
> wrote:
> >
> > Sorry for the late reply.
> >
> > On Fri, 6 Dec 2019 at 14:20, Amit Kapila wrote:
> > >
> > >
> > > > > Here, we have a need to reduce the number of workers. Index Vacuum
> > >
On Tue, 10 Dec 2019 at 01:21, Tom Lane wrote:
> Mark Dilger writes:
> > [ useful tips about finding the code that implements a SQL command ]
>
> BTW, if it wasn't obvious already, you *really* want to have some kind
> of tool that easily finds the definition of a particular C symbol.
> You can f
On Tue, 10 Dec 2019 at 09:51, Andres Freund wrote:
> Hi,
>
> I several times, most recently for the record format in the undo
> patchset, wished for a fast variable width integer implementation for
> postgres. Using very narrow integers, for space efficiency, solves the
> space usage problem, but
On Fri, Dec 13, 2019 at 10:03 AM Masahiko Sawada
wrote:
>
> Sorry for the late reply.
>
> On Fri, 6 Dec 2019 at 14:20, Amit Kapila wrote:
> >
> >
> > > > Here, we have a need to reduce the number of workers. Index Vacuum
> > > > has two different phases (index vacuum and index cleanup) which use
On Wed, 11 Dec 2019 at 02:08, Alvaro Herrera
wrote:
> On 2019-Dec-10, Tomas Vondra wrote:
>
> > On Tue, Dec 10, 2019 at 09:42:17AM +0900, Kyotaro Horiguchi wrote:
> > > At Tue, 10 Dec 2019 00:44:09 +0100, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote in
>
> > > I'm not sure how much xact_s
On Thu, 12 Dec 2019 at 16:21, ROS Didier wrote:
> Hi
>With pg_background extension ,it is possible to make "autonomous
> transaction" which means possibility to commit in a transaction.
> It is like a client which connects to a postgresql instance. So you can
> execute any sql orders .
>
>
On Sat, Nov 30, 2019 at 10:57 AM Thomas Munro wrote:
> On Fri, Nov 29, 2019 at 12:34 PM Thomas Munro wrote:
> > ... or stop using
> > _mdfd_getseg() for this so that you can remove segments independently
> > without worrying about sync requests for other segments (it was
> > actually like that in
Sorry for the late reply.
On Fri, 6 Dec 2019 at 14:20, Amit Kapila wrote:
>
> On Thu, Dec 5, 2019 at 7:44 PM Robert Haas wrote:
> >
> > I think it might be a good idea to change what we expect index AMs to
> > do rather than trying to make anything that they happen to be doing
> > right now work
Hello.
At Thu, 12 Dec 2019 22:50:20 +, "Bossart, Nathan"
wrote in
> Hi hackers,
>
> I believe I've uncovered a bug that may cause archive status ".ready"
> files to be created too early, which in turn may cause an incorrect
> version of the corresponding WAL segment to be archived.
>
> Th
On Wed, Dec 11, 2019 at 12:33:53PM -0300, Alvaro Herrera wrote:
> On 2019-Dec-11, Justin Pryzby wrote:
> > + cbarg.blkno = 0; /* Not known yet */
> Shouldn't you use InvalidBlockNumber for this initialization?
..
> > pgstat_progress_update_param(PROGRESS_VACUUM_HEAP_BLKS_SCANNED,
> >
On Wed, Dec 11, 2019 at 7:24 PM Laurenz Albe wrote:
> Doesn't that rely on a specific implementation of double precision (IEEE)?
> I thought that we don't want to limit ourselves to platforms with IEEE floats.
Just by the way, you might want to read the second last paragraph of
the commit message
On Fri, Dec 13, 2019 at 3:13 PM Justin Pryzby wrote:
> On Fri, Dec 13, 2019 at 03:03:47PM +1300, Thomas Munro wrote:
> > On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby wrote:
> > > 2019-12-07 01:35:56 | 11025 | postgres | canceling statement due to
> > > statement timeout
On Thu, Dec 12, 2019 at 8:44 PM Robert Haas wrote:
>
> On Tue, Dec 10, 2019 at 4:32 PM Andres Freund wrote:
> > and then, within an if():
> >
> > /*
> > * We don't try to do group update optimization if a
> > process has
> > * overflowed the subx
On Fri, Dec 13, 2019 at 03:03:47PM +1300, Thomas Munro wrote:
> On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby wrote:
> > I have a nagios check on ancient tempfiles, intended to catch debris left by
> > crashed processes. But triggered on this file:
> >
> > $ sudo find /var/lib/pgsql/12/data/base/
On Thu, 2019-11-28 at 18:46 +0100, Tomas Vondra wrote:
> 13) As for this:
>
> /* make sure that we don't exhaust the hash bits */
> if (partition_bits + input_bits >= 32)
> partition_bits = 32 - input_bits;
>
> We already ran into this issue (exhausting bits in a hash value) in
On Fri, Dec 13, 2019 at 7:05 AM Justin Pryzby wrote:
> I have a nagios check on ancient tempfiles, intended to catch debris left by
> crashed processes. But triggered on this file:
>
> $ sudo find /var/lib/pgsql/12/data/base/pgsql_tmp -ls
> 1429774 drwxr-x--- 3 postgres postgres 4096 De
On 12.1, fresh initdb the following query gives me the error
"ERROR: failed to construct the join relation"
SELECT FROM (
SELECT FROM pg_catalog.pg_stat_bgwriter AS ref_0
LEFT JOIN pg_catalog.pg_stat_bgwriter AS ref_1 ON (true), LATERAL (
SELECT FROM pg_catalog.pg_publication AS r
Hi,
On 2019-12-12 09:27:04 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I pushed this now. We'll see what the slower buildfarm animals say. I'll
> > try to see how long they took in a few days.
>
> friarbird (a CLOBBER_CACHE_ALWAYS animal) just showed a failure in this:
>
> https://buildf
On Wed, Dec 11, 2019 at 11:46:40PM +, Alex Adriaanse wrote:
On Thu., December 5, 2019 at 5:45 PM, Tomas Vondra wrote:
At first I thought maybe this might be due to collations changing and
breaking the index silently. What collation are you using?
We're using en_US.utf8. We did not make any
Hello
On 2019-Dec-12, Andres Freund wrote:
> I see that you pushed this patch.
Yeah, a version of it -- significantly different from what Alexey
submitted last.
> I'm unfortunately unhappy with the
> approach taken. As previously said, handling a lot of this from exec_*
> is a mistake in my op
Hi,
I see that you pushed this patch. I'm unfortunately unhappy with the
approach taken. As previously said, handling a lot of this from exec_*
is a mistake in my opinion. Pretty much the same problem exists for
parametrized query execution from other contexts, e.g. for queries
executed inside pl
On 12/12/19 1:35 PM, Mark Dilger wrote:
Once the xid age reaches one
million, it will start to be the dominant factor.
Actually, it doesn't change much from x = 1 to x = 1,000,000
but I was planning to add another factor to the formula and
forgot before sending the email. I'll leave that as
On Fri, Nov 1, 2019 at 1:19 PM Robert Haas wrote:
> On Fri, Nov 1, 2019 at 3:15 PM Peter Geoghegan wrote:
> > I don't think that those two things are equivalent at all. There may
> > even be workloads that will benefit when run on 32-bit hardware.
> > Having to palloc() and pfree() with 8 byte in
On 12/12/19 1:35 PM, Mark Dilger wrote:
Let C = 1.0002065
Let x = xid_age for a table
Let v = clamp(n_dead_tuples / reltuples*2) to max 0.5
Let a = clamp(changes_since_analyze / reltuples) to max 0.5
Let score = C**x + v + a
I should hasten to add that this is just a proo
Hi,
On 2019-12-13 10:30:19 +1300, Thomas Munro wrote:
> Every SERIALIZABLEXACT holds an xmin that comes from a Snapshot, and
> SxactGlobalXmin holds the oldest of them. But a SERIALIZABLEXACT can
> live longer than a transaction and snapshot, so now I'm wondering if
> it's possible to reach a sta
On 12/12/19 11:26 AM, David Fetter wrote:
On Thu, Dec 12, 2019 at 08:02:25AM -0800, Mark Dilger wrote:
On 11/30/19 2:23 PM, David Fetter wrote:
On Sat, Nov 30, 2019 at 10:04:07AM -0800, Mark Dilger wrote:
On 11/29/19 2:21 PM, David Fetter wrote:
On Fri, Nov 29, 2019 at 07:01:39PM +0100, Da
Hi,
Every SERIALIZABLEXACT holds an xmin that comes from a Snapshot, and
SxactGlobalXmin holds the oldest of them. But a SERIALIZABLEXACT can
live longer than a transaction and snapshot, so now I'm wondering if
it's possible to reach a state where there exist SERIALIZABLEXACT
objects with a range
There were a number of recent threads about building PostgreSQL on
MSYS2. This has been confusing on occasion; see for example [0]. MSYS2
is actually a derivative of Cygwin. What most people are actually doing
is using MSYS2 has the host environment for doing a kind of
cross-compilation to M
On Wed, 11 Dec 2019 at 01:24, Laurenz Albe wrote:
>
> On Tue, 2019-12-10 at 15:50 -0700, Jim Finnerty wrote:
> > As a proof of concept, I hacked around a bit today to re-purpose one of the
> > bits of the Cost structure to mean "is_disabled" so that we can distinguish
> > 'disabled' from 'non-disa
Hi,
On 2019-12-11 13:35:26 -0500, Robert Haas wrote:
> While I have passionate philosophical feelings about this topic, for
> purposes of the present thread the really important question (IMV,
> anyway) is whether there's any way of getting a patch for global
> barriers committed in advance of the
Hi,
On 2019-12-11 10:50:16 -0500, Robert Haas wrote:
> On Tue, Dec 10, 2019 at 4:59 PM Andres Freund wrote:
> > 3) For lots of one-off uses of hashtables that aren't performance
> >critical, we want a *simple* API. That IMO would mean that key/value
> >end up being separately allocated po
Hi,
On 2019-12-11 10:05:00 -0500, Robert Haas wrote:
> On Tue, Dec 10, 2019 at 4:59 PM Andres Freund wrote:
> > > A significant problem in either case is that a simplehash wants to
> > > live in a memory context; no such thing exists either for data in
> > > shared memory nor in frontend code. Ho
On Thu, Dec 12, 2019 at 08:02:25AM -0800, Mark Dilger wrote:
> On 11/30/19 2:23 PM, David Fetter wrote:
> > On Sat, Nov 30, 2019 at 10:04:07AM -0800, Mark Dilger wrote:
> > > On 11/29/19 2:21 PM, David Fetter wrote:
> > > > On Fri, Nov 29, 2019 at 07:01:39PM +0100, David Fetter wrote:
> > > > > Fol
On Wed, Dec 11, 2019 at 9:29 PM Ibrar Ahmed wrote:
>
>
> On Wed, Dec 11, 2019 at 7:29 PM Robert Haas wrote:
>
>> On Mon, Dec 9, 2019 at 2:02 PM Ibrar Ahmed wrote:
>> >> Did you see this thread?
>> >>
>> https://postgr.es/m/CAGTBQpbDCaR6vv9=scXzuT8fSbckf=a3ngzdwfwzbdvugvh...@mail.gmail.com
>> >>
I have just found out the hard way (cf commits 22864f6e0, 776a2c887)
that if one uses EXPLAIN with both ANALYZE and VERBOSE selected,
the output is not the same between force_parallel_mode = off and
force_parallel_mode = regress. This seems to me to be quite broken;
what's the point of force_paral
I have a nagios check on ancient tempfiles, intended to catch debris left by
crashed processes. But triggered on this file:
$ sudo find /var/lib/pgsql/12/data/base/pgsql_tmp -ls
1429774 drwxr-x--- 3 postgres postgres 4096 Dec 12 11:32
/var/lib/pgsql/12/data/base/pgsql_tmp
1698684 d
Li Japin writes:
> Thanks for your confirm. Is there anything I can do?
No, I've got it.
In adding the test coverage I spoke of, I thought we should allow
the date_part tests to check all the entries in timestamp[tz]_tbl
not just those around current time, and I found an independent
problem:
On Thu, 12 Dec 2019 at 14:18, Amit Kapila wrote:
>
> On Thu, Dec 12, 2019 at 11:53 AM Amit Khandekar
> wrote:
> >
> > On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
> >
> > > So max_changes_in_memory is the one
> > > that allows us to reduce the number of transactions required, so we
> > >
Thanks for your confirm. Is there anything I can do?
On Dec 12, 2019, at 11:13 PM, Tom Lane
mailto:t...@sss.pgh.pa.us>> wrote:
Ah, after looking in the git history, not quite that ancient:
this duplication dates to commit 258ee1b63, which moved these
switch cases from the "if (type == RESERV)" s
On 11/30/19 2:23 PM, David Fetter wrote:
On Sat, Nov 30, 2019 at 10:04:07AM -0800, Mark Dilger wrote:
On 11/29/19 2:21 PM, David Fetter wrote:
On Fri, Nov 29, 2019 at 07:01:39PM +0100, David Fetter wrote:
Folks,
Per a suggestion Christophe made, please find attached a patch to
$Subject:
A
On Tue, Dec 10, 2019 at 4:32 PM Andres Freund wrote:
> and then, within an if():
>
> /*
> * We don't try to do group update optimization if a process
> has
> * overflowed the subxids array in its PGPROC, since in that
> case we
>
I wrote:
> Li Japin writes:
>> I find there is a duplicate function call on timestamp2tm in
>> timestamptz_part and timestamp_part.
>> Is that necessary? I remove the latter one and it also works.
> Huh. I do believe you're right. Must be an ancient copy-and-paste
> mistake?
Ah, after looking
On Thu, Dec 12, 2019 at 10:47:52AM +0100, Peter Eisentraut wrote:
> On 2019-12-12 07:24, David Fetter wrote:
> > > That problem exists even before you get to the question of whether
> > > this specific option is useful or well-designed ... a question I'm
> > > not opining about here, but it would c
On 2019-Dec-12, Amit Kapila wrote:
> On Thu, Dec 12, 2019 at 6:10 PM Alvaro Herrera
> wrote:
> > The more I look at both these asserts, the less sense they make. Why
> > does clog.c care about PGPROC at all?
>
> It is mainly for group updates. Basically, we want to piggyback the
> procs that
Li Japin writes:
> I find there is a duplicate function call on timestamp2tm in timestamptz_part
> and timestamp_part.
> Is that necessary? I remove the latter one and it also works.
Huh. I do believe you're right. Must be an ancient copy-and-paste
mistake?
regards, to
Hello Thomas,
Thanks for looking at it!
On Thu, Dec 12, 2019 at 5:01 AM Thomas Munro wrote:
>
> We create duplicate pg_depend records:
>
> [...]
>
> I wondered if that was harmless
That's the assumed behavior of recordMultipleDependencies:
/*
* Record the Dependency. Note we don't bother to c
Hi,
I find there is a duplicate function call on timestamp2tm in timestamptz_part
and timestamp_part.
Is that necessary? I remove the latter one and it also works.
Best,
Japin.
remove-duplicate-timestamp2tm-function-call.patch
Description: remove-duplicate-timestamp2tm-function-call.patch
Andres Freund writes:
> I pushed this now. We'll see what the slower buildfarm animals say. I'll
> try to see how long they took in a few days.
friarbird (a CLOBBER_CACHE_ALWAYS animal) just showed a failure in this:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=friarbird&dt=2019-12-12
On Tue, Dec 10, 2019 at 8:25 AM Jeremy Finzel wrote:
> Is there a way for me to test this theory? I tried the following with no
> change in behavior:
>
>1. Disable write load to table
>2. Vacuum analyze table (not vac full)
>3. Create index
>4. Explain
>
> Still did not pick up t
On Thu, Dec 12, 2019 at 6:10 PM Alvaro Herrera wrote:
>
> On 2019-Dec-11, Amit Kapila wrote:
>
> > On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
> > > On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
>
> > > /*
> > > * We don't try to do group update optimi
On Thu, Dec 12, 2019 at 5:58 AM Kyotaro Horiguchi
wrote:
> Hello.
>
> At Wed, 11 Dec 2019 17:32:05 -0500, Robert Haas
> wrote in
> > While reviewing the first patch in Asif Rehman's series of patches for
> > parallel backup over at
> >
> http://postgr.es/m/CADM=Jeg3ZN+kPQpiSfeWCXr=xgplrq4cbqe5zv
Hello.
I think I can say that this patch doesn't slows non-AsyncAppend,
non-postgres_fdw scans.
At Mon, 9 Dec 2019 12:18:44 -0500, Bruce Momjian wrote in
> Certainly any overhead on normal queries would be unacceptable.
I took performance numbers on the current shape of the async execution
pa
On 2019-Dec-11, Amit Kapila wrote:
> On Wed, Dec 11, 2019 at 4:02 AM Andres Freund wrote:
> > On 2019-12-10 13:55:40 +0530, Dilip Kumar wrote:
> > /*
> > * We don't try to do group update optimization if a
> > process has
> > * overflowed the su
Thanks, Robert for the review.
On Wed, Dec 11, 2019 at 1:10 AM Robert Haas wrote:
> On Tue, Dec 10, 2019 at 6:40 AM Suraj Kharage
> wrote:
> > Please find attached patch for backup validator implementation (0004
> patch). This patch is based
> > on Rushabh's latest patch for backup manifest.
>
On Wed, Dec 11, 2019 at 11:46 PM Robert Haas wrote:
>
> On Mon, Dec 2, 2019 at 3:32 AM Dilip Kumar wrote:
> > I have rebased the patch set on the latest head.
>
> 0001 looks like a clever approach, but are you sure it doesn't hurt
> performance when many small XLOG records are being inserted? I t
Hi Amit,
Please see following comments:
1. 0002-Add-info-in-WAL-records-in-preparation-for-logical-s.patch
--- a/src/backend/access/hash/hashinsert.c
+++ b/src/backend/access/hash/hashinsert.c
@@ -17,6 +17,7 @@
#include "access/hash.h"
#include "access/hash_xlog.h"
+#include "catalog/catalog
On 2019-12-12 07:24, David Fetter wrote:
That problem exists even before you get to the question of whether
this specific option is useful or well-designed ... a question I'm
not opining about here, but it would certainly require thought.
I think it was a reasonable extension. We cover lines tha
On Thu, Dec 12, 2019 at 11:53 AM Amit Khandekar wrote:
>
> On Thu, 12 Dec 2019 at 11:34, Amit Khandekar wrote:
>
> > So max_changes_in_memory is the one
> > that allows us to reduce the number of transactions required, so we
> > can cut down on the outer loop iterations and make the test finish
>
On 2019-12-11 18:54, Andreas Karlsson wrote:
I have not used .editorconfig that much, but would it makes sense to add
the below?
[*]
end_of_line = lf
I think that would best be done in response to an actual need.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Developm
Hi
With pg_background extension ,it is possible to make "autonomous
transaction" which means possibility to commit in a transaction.
It is like a client which connects to a postgresql instance. So you can
execute any sql orders .
Best Regards
Didier ROS
-Message d'origine-
De : tsun
69 matches
Mail list logo