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
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
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-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
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 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
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 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
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 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
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 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
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
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
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
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
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
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
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 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
>
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
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 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
> > >
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:
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
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
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
>> >>
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
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
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 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
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
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
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
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,
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 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
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:
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
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
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
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
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 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
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 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 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, 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 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 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 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,
> >
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
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
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
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 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 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 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 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 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 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
>
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 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 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.
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 <
>
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
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
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 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
69 matches
Mail list logo
