Hi Surafel,
On Thu, Aug 27, 2020 at 6:01 PM Surafel Temesgen wrote:
>
> Hi,
>
> In good written query IS NULL and IS NOT NULL check on primary and non null
> constraints columns should not happen but if it is mentioned PostgreSQL have
> to be smart enough for not checking every return result ab
On 2020-08-25 15:32, Laurenz Albe wrote:
On Tue, 2020-08-25 at 13:48 +0200, Daniel Gustafsson wrote:
On 25 Aug 2020, at 12:20, Peter Eisentraut
wrote:
A user tried to use the cracklib build-time option of the passwordcheck module.
This failed, as it turned out because there was no dictionar
st 26. 8. 2020 v 17:06 odesílatel Pavel Stehule
napsal:
> 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
On Thu, Aug 27, 2020 at 11:11:47PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
> >> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> >> even if it's useless in practice.
> >> Given that no buildfarm membe
On 2020-08-27 15:56, Robert Haas wrote:
On Thu, Aug 27, 2020 at 4:34 AM Peter Eisentraut
wrote:
For a top-level direct call, you can pass whatever you want, since all
OUT parameters are presented as initially NULL to the procedure code.
So you could just pass NULL, as in CALL test_proc(5, NULL)
On Thu, Aug 27, 2020 at 8:48 PM Jakub Wartak wrote:
> >> 29.62% postgres [kernel.kallsyms] [k]
> >> copy_user_enhanced_fast_string
> >> ---copy_user_enhanced_fast_string
> >>|--17.98%--copyin
> >> [..]
> >>| __pwrite_nocancel
> >>
On 2020-06-30 19:49, Peter Eisentraut wrote:
This adds support for writing CREATE FUNCTION and CREATE PROCEDURE
statements for language SQL with a function body that conforms to the
SQL standard and is portable to other implementations.
Here is a new patch. The only significant change is that
> 25 авг. 2020 г., в 19:36, Mark Dilger
> написал(а):
Hi Mark!
Thanks for working on this important feature.
I was experimenting a bit with our internal heapcheck and found out that it's
not helping with truncated CLOG anyhow.
Will your module be able to gather tid's of similar corruptions
On Thu, 27 Aug 2020 at 20:58, Drouvot, Bertrand wrote:
>
>
> On 8/27/20 10:16 AM, Masahiko Sawada wrote
> >
> > On Mon, 10 Aug 2020 at 23:43, Drouvot, Bertrand wrote:
> >> Hi,
> >>
> >> On 7/31/20 7:12 AM, Masahiko Sawada wrote:
> >>> + tmpWaitlist = waitlist;
> >>> + while (VirtualTransactio
On Thu, Aug 27, 2020 at 9:21 PM Robert Haas wrote:
>
> On Thu, Aug 27, 2020 at 5:37 AM Ashutosh Sharma wrote:
> > While reviewing the patch for pg_surgery contrib module - [1], Asim
> > Praveen suggested that it would be better to replace the check for
> > access method OID with handler OID. Othe
On 2020-Aug-28, Tatsuro Yamada wrote:
> > IMO the per-type columns should show both the type being enabled as
> > well as it being built.
>
> Hmm. I'm not sure how to get the status (enabled or disabled) of
> extended stats. :(
> Could you explain it more?
pg_statistic_ext_data.stxdndistinct is
Noah Misch writes:
> On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
>> Looks legit, and at least per commit 13bba02271dc we do fix such things,
>> even if it's useless in practice.
>> Given that no buildfarm member has ever complained, this exercise seems
>> pretty pointless.
> L
Hi Mark,
Thanks for the review. Please find my comments inline below:
> HeapTupleForceOption should be added to src/tools/pgindent/typedefs.list.
>
This has been fixed in the v9 patch.
>
> The tidcmp function can be removed, and ItemPointerCompare used directly by
> qsort as:
>
> -
On Fri, Aug 28, 2020 at 1:44 AM Robert Haas wrote:
>
> On Wed, Aug 26, 2020 at 10:26 PM Ashutosh Sharma
> wrote:
> > Okay, point noted.
>
> I spent some time today working on this patch. I'm fairly happy with
> it now and intend to commit it if nobody sees a big problem with that.
> Per discussi
On Thu, Aug 27, 2020 at 12:57:20PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-27, Ranier Vilela wrote:
> > indexcmds.c (1162):
> > memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
>
> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> even if it's useless in practic
Hi Alvaro!
It's been ages since we created a progress reporting feature together. :-D
+1 good idea
+1 that's a good idea. Please add it to the next commitfest!
+1 for the general idea, and +1 for \dX being the syntax to use
Thank you for voting!
IMO the per-type columns should show bo
On 2020/08/27 15:59, Asim Praveen wrote:
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 r
On Thu, Aug 27, 2020 at 5:30 PM Stephen Frost wrote:
> Greetings,
>
> There's no shortage of requests and responses regarding how to have a
> 'read all of the data' role in PG, with various hacks involving "GRANT
> ALL" and "ALTER DEFAULT PRIVILEGES" to "solve" this, neither of which
> really wor
Greetings,
There's no shortage of requests and responses regarding how to have a
'read all of the data' role in PG, with various hacks involving "GRANT
ALL" and "ALTER DEFAULT PRIVILEGES" to "solve" this, neither of which
really works long term ("GRANT ALL" is one-time, and "ALTER DEFAULT"
only he
We have a Postgres 13 open item for Disk-based hash aggregate, which
is the only non-trivial open item. There is a general concern about
how often we get disk-based hash aggregation when work_mem is
particularly low, and recursion seems unavoidable. This is generally
thought to be a problem in the
Hi,
Per Coverity.
When "Prepare for toasting", it is necessary to turn off the flag
TOAST_NEEDS_DELETE_OLD,
if there is no need to delete external values from the old tuple, otherwise,
there are dereference NULL at toast_helper.c (on toast_tuple_cleanup
function).
regards,
Ranier Vilela
fix_n
On Thu, Aug 27, 2020 at 5:06 PM Mark Dilger
wrote:
> These two are both checked in verify_heapam.c. The point is that the system
> will also refuse to write out pages that have this corruption. The Asserts
> could be converted to panics or whatever, but that has other more serious
> consequen
> On Aug 27, 2020, at 4:58 PM, Peter Geoghegan wrote:
>
> On Thu, Aug 27, 2020 at 4:57 PM Mark Dilger
> wrote:
>> The amcheck patch has Asserts in hio.c that purport to disallow writing
>> invalid header bits to disk.
>
> Can it also be a runtime check for the verification process? I think
Ranier Vilela writes:
> More reports.
> Memory Sanitizer:
> running bootstrap script ... ==40179==WARNING: MemorySanitizer:
> use-of-uninitialized-value
If you're going to run tests like that, you need to account for the
known exceptions shown in src/tools/valgrind.supp.
On Thu, Aug 27, 2020 at 4:57 PM Mark Dilger
wrote:
> The amcheck patch has Asserts in hio.c that purport to disallow writing
> invalid header bits to disk.
Can it also be a runtime check for the verification process? I think
that we can easily afford to be fairly exhaustive about stuff like
this
> On Aug 27, 2020, at 4:47 PM, Peter Geoghegan wrote:
>
> On Wed, Aug 26, 2020 at 12:16 PM Alvaro Herrera
> wrote:
>> We could do this in stable branches, if there were any reports that
>> this inconsistency is happening in real world databases.
>
> I hope that the new heapam amcheck stuff e
+1 for the general idea, and +1 for \dX being the syntax to use
IMO the per-type columns should show both the type being enabled as
well as it being built.
(How many more stat types do we expect -- Tomas? I wonder if having one
column per type is going to scale in the long run.)
Also, the stat
More reports.
Memory Sanitizer:
running bootstrap script ... ==40179==WARNING: MemorySanitizer:
use-of-uninitialized-value
#0 0x538cfc1 in pg_comp_crc32c_sb8
/usr/src/postgres/src/port/pg_crc32c_sb8.c:80:4
#1 0x533a0c0 in pg_comp_crc32c_choose
/usr/src/postgres/src/port/pg_crc32c_sse42_cho
On Wed, Aug 26, 2020 at 12:16 PM Alvaro Herrera
wrote:
> We could do this in stable branches, if there were any reports that
> this inconsistency is happening in real world databases.
I hope that the new heapam amcheck stuff eventually leads to our
having total (or near total) certainty about wha
Hi Julien!
Thanks also for the documentation and regression tests. This overall looks
good, I just have a two comments:
Thank you for reviewing the patch! :-D
- there's a whitespace issue in the documentation part:
add_list_extended_stats_for_psql_by_dX_command.patch:10: tab in indent.
Hi,
On 2020-08-27 16:20:30 -0400, Jeff Janes wrote:
> On Thu, Aug 27, 2020 at 3:10 PM Jeff Janes wrote:
>
> > If I create a large table with "CREATE TABLE ... AS SELECT ... from
> > generate_series(1,3e7)" with no explicit transactions, then once it is done
> > I wait for autovac to kick in, the
Hi Stephen,
OS version is Ubuntu 18.04.5 LTS.
Filesystem is ext4 and block size is 4KB.
Talha.
-Original Message-
From: Stephen Frost
Sent: Thursday, August 27, 2020 4:56 PM
To: Sait Talha Nisanci
Cc: Thomas Munro ; Tomas Vondra
; Dmitry Dolgov <9erthali...@gmail.com>; David
Steele
> On Aug 26, 2020, at 4:36 AM, Ashutosh Sharma wrote:
>
> This patch also takes care of all the other review comments from - [1].
>
> [1] -
> https://www.postgresql.org/message-id/CA%2Bfd4k6%2BJWq2MfQt5b7fSJ2wMvCes9TRfbDhVO_fQP9B8JJRAA%40mail.gmail.com
>
>
> --
> With Regards,
> Ashutosh S
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Aug 27, 2020 at 2:51 PM Stephen Frost wrote:
> > > Hm? At least earlier versions didn't do prefetching for records with an
> > > fpw, and only for subsequent records affecting the same or if not in s_b
> > > anymore.
> >
> > We d
On Thu, Aug 27, 2020 at 3:10 PM Jeff Janes wrote:
> If I create a large table with "CREATE TABLE ... AS SELECT ... from
> generate_series(1,3e7)" with no explicit transactions, then once it is done
> I wait for autovac to kick in, then when I try to build an index on that
> table (or drop the tab
On Thu, Aug 27, 2020 at 2:51 PM Stephen Frost wrote:
> > Hm? At least earlier versions didn't do prefetching for records with an
> > fpw, and only for subsequent records affecting the same or if not in s_b
> > anymore.
>
> We don't actually read the page when we're replaying an FPW though..?
> I
On Wed, Aug 26, 2020 at 10:26 PM Ashutosh Sharma wrote:
> Okay, point noted.
I spent some time today working on this patch. I'm fairly happy with
it now and intend to commit it if nobody sees a big problem with that.
Per discussion, I do not intend to back-patch at this time. The two
most signifi
On Thu, Aug 27, 2020 at 03:41:40PM -0400, Bruce Momjian wrote:
> On Thu, Aug 27, 2020 at 04:09:25PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian wrote
> > in
> > bruce> On Wed, Aug 26, 2020 at 06:13:23PM +0900, Kyotaro Horiguchi wrote:
> > > > At Tue, 25
On Thu, Aug 27, 2020 at 04:09:25PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian wrote in
> bruce> 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 w
If I create a large table with "CREATE TABLE ... AS SELECT ... from
generate_series(1,3e7)" with no explicit transactions, then once it is done
I wait for autovac to kick in, then when I try to build an index on that
table (or drop the table) the autovac doesn't go away on its own.
Bisects down to
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On August 27, 2020 11:26:42 AM PDT, Stephen Frost wrote:
> >Is WAL FPW compression enabled..? I'm trying to figure out how, given
> >what's been shared here, that replaying 25GB of WAL is being helped out
> >by 2.5x thanks to prefetch in t
Hi,
On August 27, 2020 11:26:42 AM PDT, Stephen Frost wrote:
>Is WAL FPW compression enabled..? I'm trying to figure out how, given
>what's been shared here, that replaying 25GB of WAL is being helped out
>by 2.5x thanks to prefetch in the SSD case. That prefetch is hurting
>in
>the HDD case e
Greetings,
* Sait Talha Nisanci (sait.nisa...@microsoft.com) wrote:
> OS version is Ubuntu 18.04.5 LTS.
> Filesystem is ext4 and block size is 4KB.
[...]
* Sait Talha Nisanci (sait.nisa...@microsoft.com) wrote:
> I have run some benchmarks for this patch. Overall it seems that there is a
> good
On 2020-Aug-27, Ranier Vilela wrote:
> If we are passing a null pointer in these places and it should not be done,
> it is a sign that perhaps these calls should not or should not be made, and
> they can be avoided.
Feel free to send a patch.
--
Álvaro Herrerahttps://www.2ndQuad
Em qui., 27 de ago. de 2020 às 13:57, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-27, Ranier Vilela wrote:
>
> > indexcmds.c (1162):
> > memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
>
> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> ev
> On Aug 27, 2020, at 9:16 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> The deprecation warnings included in this patch warn that postfix operator
>> support, along with both postfix ! and prefix !! factorial operators, will
>> be removed in PostgreSQL 14.
>
> The operator docs should say
Em qui., 27 de ago. de 2020 às 13:57, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Aug-27, Ranier Vilela wrote:
>
> > indexcmds.c (1162):
> > memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
>
> Looks legit, and at least per commit 13bba02271dc we do fix such things,
> ev
On 2020-Aug-27, Ranier Vilela wrote:
> indexcmds.c (1162):
> memcpy(part_oids, partdesc->oids, sizeof(Oid) * nparts);
Looks legit, and at least per commit 13bba02271dc we do fix such things,
even if it's useless in practice.
Given that no buildfarm member has ever complained, this exercise seems
Em qui., 27 de ago. de 2020 às 12:46, Tom Lane escreveu:
> Ranier Vilela writes:
> > Is this something to worry about, or is it another problem with the
> > analysis tool, that nobody cares about?
>
> As far as the first one goes, I'd bet on buggy analysis tool.
> The complained-of allocation is
Mark Dilger writes:
> The deprecation warnings included in this patch warn that postfix operator
> support, along with both postfix ! and prefix !! factorial operators, will be
> removed in PostgreSQL 14.
The operator docs should say "use factorial() instead", or words to
that effect.
Hackers,
Over in [1] we have been discussing the deprecation of postfix operators, with
the general consensus that deprecation warnings should be included in this
upcoming release and postfix operator support should be removed in PostgreSQL
14. Since not all people who follow -hackers will nec
On 2020-Aug-27, Ashutosh Bapat wrote:
> On Wed, 26 Aug 2020 at 22:47, Alvaro Herrera
> wrote:
> > But I'm not 100% about running the BEFORE triggers. Maybe
> > one way to address this is to check whether the BEFORE triggers in the
> > new target partition are clones; if so then they would hav
>
> 3) I didn't quite get the meaning of the assertion, that is added in a few
> places:
> Assert(so->state.includeTupdesc->natts);
> Should it be Assert(so->state.includeTupdesc->natts > 1) ?
>
It is rather Assert(so->state.includeTupdesc->natts > 0) as INCLUDE tuple
descriptor should not be
On Thu, Aug 27, 2020 at 5:37 AM Ashutosh Sharma wrote:
> While reviewing the patch for pg_surgery contrib module - [1], Asim
> Praveen suggested that it would be better to replace the check for
> access method OID with handler OID. Otherwise, if someone creates a
> new AM using the AM handler that
On Wed, Aug 26, 2020 at 7:40 PM Alvaro Herrera wrote:
> To mark it detached means to set pg_inherits.inhdetached=true. That
> column name is a bit of a misnomer, since that column really means "is
> in the process of being detached"; the pg_inherits row goes away
> entirely once the detach proces
Ranier Vilela writes:
> Is this something to worry about, or is it another problem with the
> analysis tool, that nobody cares about?
As far as the first one goes, I'd bet on buggy analysis tool.
The complained-of allocation is evidently for the "extra" state
associated with the timezone GUC vari
Thanks Daniel for the review and Vignesh for addressing the comments.
I have two remarks with the state of the current patches:
- DefGetCopyHeader() duplicates a lot of code from defGetBoolean(), should we
refactor this so that they can share more of their internals? In the current
implementatio
On Thu, Aug 27, 2020 at 10:04 AM Tom Lane wrote:
> Well, the !! operator itself has been "deprecated" for a long time:
>
> regression=# \do+ !!
> List of operators
>Schema | Name | Left arg type | Right arg type | Result type | Function
> |
> On Aug 27, 2020, at 7:04 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> Yeah, that looks like a good spot. I think we should also add
>> something to the documentation of the factorial operator, mentioning
>> that it will be going away. Perhaps we can advise people to write !!3
>> instead o
Robert Haas writes:
> Yeah, that looks like a good spot. I think we should also add
> something to the documentation of the factorial operator, mentioning
> that it will be going away. Perhaps we can advise people to write !!3
> instead of 3! for forward-compatibility, or maybe we should instead
>
On Thu, Aug 27, 2020 at 4:34 AM Peter Eisentraut
wrote:
> For a top-level direct call, you can pass whatever you want, since all
> OUT parameters are presented as initially NULL to the procedure code.
> So you could just pass NULL, as in CALL test_proc(5, NULL).
Is that actually how other systems
Greetings,
* Sait Talha Nisanci (sait.nisa...@microsoft.com) wrote:
> I have run some benchmarks for this patch. Overall it seems that there is a
> good improvement with the patch on recovery times:
Maybe I missed it somewhere, but what's the OS/filesystem being used
here..? What's the filesyst
On Wed, Aug 26, 2020 at 9:42 AM Sait Talha Nisanci
wrote:
> I have tried combination of SSD, HDD, full_page_writes = on/off and
> max_io_concurrency = 10/50, the recovery times are as follows (in seconds):
>
>No prefetch | Default prefetch
> values |
On Thu, Aug 27, 2020 at 7:12 AM John Naylor wrote:
> Well, for starters it'll say the obvious, but since we have a concrete
> timeframe, maybe a tag to make it more visible, like in the
> attached, compressed to avoid confusing the cfbot.
Yeah, that looks like a good spot. I think we should also
Hi all,
this minor patch is attempting to force the use of the tableam api in dbsize
where ever it is required.
Apparently something similar was introduced for toast relations only.
Intuitively it seems that the distinction between a table and a toast table is
not needed. This patch treats tab
On Thu, Aug 27, 2020 at 6:30 PM Sachin Khanna wrote:
>
> Hi
>
>
>
> I am new to postgreSQL , I am trying to install the same with XML support but
> it is giving below error on configuration.
>
>
>
> ./configure --prefix=/opt/postgresql-12.3/pqsql --with-libxml
> --datadir=/home/postgres/ --with-
>checking for libxml/parser.h... no
>configure: error: header file is required for XML support
sudo yum install libxml2-devel
You need to install the development package before ./configure.
regards,
Ranier Vilela
Hi Yamada-san,
On Thu, Aug 27, 2020 at 03:13:09PM +0900, Tatsuro Yamada wrote:
>
> I re-read a help message of \d* commands and realized it's better to
> use "\dX".
> There are already cases where the commands differ due to differences
> in case, so I did the same way. Please find attached patch.
Hello!
I`ve noticed, that when running switchover replica to master and back to
replica, new history file is streamed to replica, but not archived,
which is not great, because it breaks PITR if archiving is running on
replica. The fix looks trivial.
Bash script to reproduce the problem and pat
Hi
I am new to postgreSQL , I am trying to install the same with XML support but
it is giving below error on configuration.
./configure --prefix=/opt/postgresql-12.3/pqsql --with-libxml
--datadir=/home/postgres/ --with-includes=/usr/lib64/
checking for libxml/parser.h... no
configure: error: h
Thanks for the quick response. I am using RED HAT linux ( ppc64-le ).
Operating System: Red Hat Enterprise Linux Server 7.9 Beta (Maipo)
CPE OS Name: cpe:/o:redhat:enterprise_linux:7.9:beta:server
Kernel: Linux 3.10.0-1136.el7.ppc64le
Architecture: ppc64-le
You have new
Hi,
In good written query IS NULL and IS NOT NULL check on primary and non null
constraints columns should not happen but if it is mentioned PostgreSQL
have to be smart enough for not checking every return result about null
value on primary key column. Instead it can be evaluate its truth value an
On Thu, Aug 27, 2020 at 4:56 PM vignesh C wrote:
>
> On Thu, Aug 27, 2020 at 8:24 AM Amit Kapila wrote:
> >
> > 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 rea
On Thu, 23 Jul 2020 at 19:55, Masahiko Sawada
wrote:
>
> On Thu, 16 Jul 2020 at 04:29, Tom Lane wrote:
> >
> > Peter Eisentraut writes:
> > >> Right, there were a number of combinations that were not properly
> > >> handled. The attached patch should fix them all. It's made against
> > >> PG12
On Thu, Aug 27, 2020 at 8:24 AM Amit Kapila wrote:
>
> 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 s
At Wed, 26 Aug 2020 08:18:49 -0400, Tom Lane wrote in
> 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 t
On Wed, Aug 26, 2020 at 8:55 PM Robert Haas wrote:
>
> 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 in
On Thu, Aug 27, 2020 at 8:48 PM Jakub Wartak wrote:
> I've tried to get cache misses ratio via PMCs, apparently on EC2 they are
> (even on bigger) reporting as not-supported or zeros.
I heard some of the counters are only allowed on their dedicated instance types.
> However interestingly the wo
Hi Alvaro, Thomas, hackers
>> 14.69% postgres postgres[.] hash_search_with_hash_value
>> ---hash_search_with_hash_value
>>|--9.80%--BufTableLookup
[..]
>> --4.90%--smgropen
>> |--2.86%--ReadBufferWithoutRelcach
Hi All,
While reviewing the patch for pg_surgery contrib module - [1], Asim
Praveen suggested that it would be better to replace the check for
access method OID with handler OID. Otherwise, if someone creates a
new AM using the AM handler that is originally supported for e.g.
"heap_tableam_handler
On Wed, Aug 26, 2020 at 6:57 PM Mark Dilger
wrote:
>
>
>
> > On Aug 26, 2020, at 6:33 AM, John Naylor
> > wrote:
>
> > and since POSTFIXOP is gone
> > it doesn't seem to matter how low it is. In fact, I found that the
> > lines with INDENT and UNBOUNDED now work as the lowest precedence
> > decl
Hi Thomas / hackers,
>> The append-only bottleneck appears to be limited by syscalls/s due to small
>> block size even with everything in FS cache (but not in shared buffers,
>> please compare with TEST1 as there was no such bottleneck at all):
>>
>> 29.62% postgres [kernel.kallsyms] [k]
In addition to what Thomas said, I would also recommend you to refer
to the description of --with-libxml command line option provided in
the postgres installation-procedure page - [1].
[1] - https://www.postgresql.org/docs/12/install-procedure.html
--
With Regards,
Ashutosh Sharma
EnterpriseDB:ht
Hello hackers,
While working on two phase related issues, I found something related to two
phase could be optimized.
1. The current implementation decouples PREPRE and COMMIT/ABORT PREPARE a lot.
This is flexible, but if
PREPARE & COMMIT/ABORT mostly happens on the same backend we could use
Procedures currently don't allow OUT parameters. The reason for this is
that at the time procedures were added (PG11), some of the details of
how this should work were unclear and the issue was postponed. I am now
intending to resolve this.
AFAICT, OUT parameters in _functions_ are not allow
On Thu, Aug 27, 2020 at 8:17 PM Khanna, Sachin 000
wrote:
> I am getting following error in configuration.log of installation . Please
> help
You didn't mention what operating system this is, but, for example, if
it's Debian, Ubuntu or similar you might need to install libxml2-dev
and pkg-confi
I am getting following error in configuration.log of installation . Please help
Is there any pkg-config path that needs to be configured/set in environment for
this to work.
configure:8172: checking for libxml-2.0 >= 2.6.23
configure:8179: $PKG_CONFIG --exists --print-errors "libxml-2.0 >= 2.
On Mon, 10 Aug 2020 at 23:43, Drouvot, Bertrand wrote:
>
> Hi,
>
> On 7/31/20 7:12 AM, Masahiko Sawada wrote:
> > + tmpWaitlist = waitlist;
> > + while (VirtualTransactionIdIsValid(*tmpWaitlist))
> > + {
> > + tmpWaitlist++;
> > + }
> > +
> > + num_waitlist_entries = (tmpWaitlist -
On Wed, Aug 26, 2020 at 04:22:51PM -0500, Jim Nasby wrote:
> The comment in procarray.c that described GlobalVisDataRels instead
> mentioned GlobalVisCatalogRels a second time. Patch attached.
Thanks, Jim. Applied.
--
Michael
signature.asc
Description: PGP signature
At Wed, 26 Aug 2020 18:36:50 -0400, Bruce Momjian wrote in
bruce> 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
90 matches
Mail list logo
