At Thu, 24 Oct 2019 17:37:52 +0800 (CST), Thunder wrote in
> Thanks for replay.I feel confused about snapshot.
>
> At 2019-10-23 11:51:19, "Kyotaro Horiguchi" wrote:
> >Hello.
> >
> >At Tue, 22 Oct 2019 20:42:21 +0800 (CST), Thunder wrote
> >in
> >> Update the patch.
> >>
> >> 1. The
On Tue, Oct 29, 2019 at 10:01 AM Masahiko Sawada wrote:
>
> On Mon, Oct 28, 2019 at 6:08 PM Dilip Kumar wrote:
> >
> > On Fri, Oct 25, 2019 at 9:19 PM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, Oct 25, 2019 at 2:06 PM Dilip Kumar wrote:
> > > >
> > > > On Fri, Oct 25, 2019 at 10:22 AM
On Mon, Oct 28, 2019 at 6:08 PM Dilip Kumar wrote:
>
> On Fri, Oct 25, 2019 at 9:19 PM Masahiko Sawada wrote:
> >
> > On Fri, Oct 25, 2019 at 2:06 PM Dilip Kumar wrote:
> > >
> > > On Fri, Oct 25, 2019 at 10:22 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > For more detail of my idea it is
Hi Alvaro,
On Tue, Oct 29, 2019 at 12:02 AM Alvaro Herrera
wrote:
> On 2019-Oct-23, Michael Paquier wrote:
> > On Wed, Oct 23, 2019 at 11:16:25AM +0900, Amit Langote wrote:
> > > IMO, parts of the patch that only refactors the existing code should
> > > be first in the list as it is easier to
Thomas Munro writes:
On Sun, Sep 1, 2019 at 5:04 PM Thomas Munro
wrote:
Adding to CF.
Rebased. An OID clashed so re-roll the dice. Also spotted a typo.
I have some questions in this code.
First,
"FullTransactionIdPrecedes(xmax, val)" is not equal to "val >= xmax" of
the previous
Here's a slightly smaller repro:
https://gist.github.com/wkalt/36720f39c97567fa6cb18cf5c05ac60f
On Mon, Oct 28, 2019 at 09:00:24PM -0700, Wyatt Alt wrote:
> I think this demonstrates a bug, tested in 11.5:
> https://gist.github.com/wkalt/a298fe82c564668c803b3537561e67a0
If this source goes away, then we would lose it. It is always better
to copy directly the example in the message sent to
Hello,
I think this demonstrates a bug, tested in 11.5:
https://gist.github.com/wkalt/a298fe82c564668c803b3537561e67a0
The same script succeeds if the index on line 11 is either dropped, made to
be non-partial on b, or shifted to a different column (the others are used
in the partitioning; maybe
On Mon, Oct 28, 2019 at 12:06:44PM -0300, Alvaro Herrera wrote:
> On 2019-Oct-28, Michael Paquier wrote:
>
> > On Sun, Oct 27, 2019 at 07:12:07PM -0500, Justin Pryzby wrote:
> > > commit #898e5e32 (Allow ATTACH PARTITION with only
> > > ShareUpdateExclusiveLock)
> > > updates ddl.sgml but not
On Mon, Oct 28, 2019 at 11:22 PM vignesh C wrote:
>
> Hi,
>
> Please find the attached patch having the fix for the typos and
> inconsistencies present in code.
> The patch contains the following changes:
> 1) attibute -> attribute
> 2) efficent -> efficient
> 3) becuase -> because
> 4) fallthru
The attached patch teaches psql to redisplay any not-yet-executed
query text after editing with \e. The fact that you don't get to
see what you're about to execute has been complained of before,
most recently at bug #16034 [1]. In that thread I complained that
we needed some
On Tue, Oct 29, 2019 at 1:52 AM Peter Eisentraut
wrote:
> As mentioned in [0], pg_upgrade currently does not preserve the version
> of collation objects created by initdb. Here is an attempt to fix that.
>
> The way I deal with this here is by having the binary-upgrade mode in
> pg_dump delete
On Mon, Oct 28, 2019 at 04:14:41PM +0900, Michael Paquier wrote:
> This brings also the point that you could just update pg_class to fix
> things if you have a broken cluster.
>
> In short, the attached fixes the issue for me, and that's the last bug
> I know of in what has been reported..
This
On Tue, Oct 29, 2019 at 12:15 PM Andres Freund wrote:
> I've groused about this a few times, but to me it seems wrong that
> HashJoin and Hash are separate nodes. They're so tightly bound together
> that keeping them separate just doesn't architecturally makes sense,
> imo. So I wrote a
On Mon, Oct 28, 2019 at 12:02:20PM -0300, Alvaro Herrera wrote:
> I also think that this has value -- let's go for it. I think I'll be
> back on Wednesday to review it, if you would prefer to wait.
No worries, thanks for looking it.
--
Michael
signature.asc
Description: PGP signature
Hi,
On 2019-10-28 15:05:01 -0400, Robert Haas wrote:
> On Fri, Sep 27, 2019 at 3:21 AM Andres Freund wrote:
> > - JIT-Expr: whether the expression was JIT compiled (might e.g. not be
> > the case because no parent was provided)
> > - JIT-Deform-{Scan,Outer,Inner}: wether necessary, and whether
Hi,
On 2019-10-27 23:46:22 -0700, Soumyadeep Chakraborty wrote:
> Apologies, I realize my understanding of symbol resolution and the
> referenced_functions mechanism wasn't correct. Thank you for your very
> helpful
> explanations.
No worries! I was just wondering whether I was misunderstanding
> When a zedstore table is queried using *invalid* ctid, the server
> crashes due to assertion failure. See below,
>
> postgres=# select * from t2 where ctid = '(0, 0)';
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing
Laurenz Albe writes:
> On Mon, 2019-10-28 at 13:00 -0400, Robert Haas wrote:
>> I wish that this argument were completely correct, but it isn't,
>> because the current query could involve a function written in some
>> procedural language (or in C) which could do anything, including
>> accessing
Robert Haas writes:
> On Sat, Oct 26, 2019 at 1:44 PM Virender Singla
> wrote:
>> If long-running transaction is "read committed", then we are sure that any
>> new query coming
>> (even on same table1 as vacuum table) will need snapshot on point of time
>> query start and not the time
On Mon, 2019-10-28 at 13:00 -0400, Robert Haas wrote:
> On Sat, Oct 26, 2019 at 1:44 PM Virender Singla
> wrote:
> > If long-running transaction is "read committed", then we are sure that any
> > new query coming
> > (even on same table1 as vacuum table) will need snapshot on point of time
>
On Fri, Sep 27, 2019 at 3:21 AM Andres Freund wrote:
> - JIT-Expr: whether the expression was JIT compiled (might e.g. not be
> the case because no parent was provided)
> - JIT-Deform-{Scan,Outer,Inner}: wether necessary, and whether JIT
> accelerated.
>
> I don't like these names much, but
>But that's pretty crappy, because it means that the 'shape' of the output
>depends on the jit_details option.
Yeah, that would be hard to work with. What about adding it as a sibling group?
"Filter": "(lineitem.l_shipdate <= '1998-09-18 00:00:00'::timestamp
without time zone)",
"Filter JIT": {
01.10.2019 8:41, Antonin Houska wrote:
Anastasia Lubennikova wrote:
The patch implementing new opclass option is attached.
It adds new attribute pg_opclass.opcisbitwise, which is set to true if opclass
equality is the same as binary equality.
By default it is true.
I think the default value
Amit Kapila writes:
> On Sat, Oct 26, 2019 at 10:49 PM Tom Lane wrote:
>> I'm inclined to think that we need to make ecpglib.h's bool-related
>> definitions exactly match c.h, which will mean that it has to pull in
>> on most platforms, which will mean adding a control symbol
>> for that to
Hi,
Please find the attached patch having the fix for the typos and
inconsistencies present in code.
The patch contains the following changes:
1) attibute -> attribute
2) efficent -> efficient
3) becuase -> because
4) fallthru -> fall through
5) uncoming -> upcoming
6) ans -> and
7) requrested ->
On Mon, Oct 28, 2019 at 2:00 PM Peter Geoghegan wrote:
> On Sun, Oct 27, 2019 at 7:04 PM Alexander Korotkov
> wrote:
> > It tool me a lot of efforts to revise a concurrency section in README.
> > I can't judge the result, but I probably did my best. I'd like to
> > commit this patchset
On Mon, Oct 28, 2019 at 3:29 PM william allen
wrote:
> Hi - is this likely to be applied to an upcoming release? / How does a
> novice apply a patch..?
>
>
At this moment is missing review, so it is probably far from being
commitable. Any attention is appreciated and might help pushing it
On Sat, Oct 26, 2019 at 1:44 PM Virender Singla wrote:
> If long-running transaction is "read committed", then we are sure that any
> new query coming
> (even on same table1 as vacuum table) will need snapshot on point of time
> query start and not the time transaction
> starts (but still why
On Mon, Oct 28, 2019 at 9:37 AM Konstantin Knizhnik
wrote:
> Sorry, but both statements are not true.
Well, I think they are true.
> I am not sure how vital is lack of aborts for transactions working with
> GTT at replica.
> Some people said that there is no sense in aborts of read-only
>
On Mon, Oct 28, 2019 at 9:48 AM Konstantin Knizhnik
wrote:
> Logically it may be good decision. But piratically support of parallel
> access to GTT requires just accessing their data through shared buffer.
> But in case of local temp tables we need also need to some how share
> table's metadata
Robert Haas writes:
> On Mon, Oct 28, 2019 at 11:02 AM Shay Rojansky wrote:
>> Before PG12, select strpos('test', '') returns 1 (empty substring found at
>> first position of the string), whereas starting with PG12 it returns 0
>> (empty substring not found).
> It looks to me like this got
SELECT ctid, chunk_id, chunk_seq, md5(chunk_data) FROM
pg_toast.pg_toast_16103925 WHERE chunk_id = 64265646;
ctid | chunk_id | chunk_seq | md5
--+--+---+-
(0 rows)
SELECT count(1) FROM pg_toast.pg_toast_16103925 WHERE chunk_id = 64265646;
count
---
2
(1 row)
On Mon, Oct 28, 2019 at 11:02 AM Shay Rojansky wrote:
> Before PG12, select strpos('test', '') returns 1 (empty substring found at
> first position of the string), whereas starting with PG12 it returns 0 (empty
> substring not found).
>
> Is this behavior change intentional? If so, it doesn't
Diggory Blake writes:
> Would it be possible to just use `IS`, `IS NOT` instead of `IS [NOT]
> DISTINCT FROM`? It's always surprised me that you can write `IS NULL`, `IS
> TRUE`, etc. but they're all special-cased. I could see it introducing a
> parsing ambiguity, but it doesn't seem impossible
Hi,
On 2019-10-28 10:41:31 -0400, Robert Haas wrote:
> I mean, do we have to break the extensions? If we just added ==
> operators that behaved like IS NOT DISTINCT FROM to each datatype, why
> would anything get broken? I mean, if someone out there has a
> ==(int4,int4) operator, that would get
On Mon, Oct 28, 2019 at 11:20 AM Tom Lane wrote:
> > I mean, do we have to break the extensions? If we just added ==
> > operators that behaved like IS NOT DISTINCT FROM to each datatype, why
> > would anything get broken?
>
> Is that the proposal? I certainly assumed that Eugen had in mind a
>
On 28/10/2019 13:48, Surafel Temesgen wrote:
>
>
> On Fri, Oct 25, 2019 at 10:45 PM Vik Fearing
> mailto:vik.fear...@2ndquadrant.com>> wrote:
>
> >
> > I don't understand what you mean by this.
> >
> >
> >
> > The primary purpose of adding row end time to primary key is
On Mon, Oct 28, 2019 at 10:03 AM Asif Rehman wrote:
> I have updated the patch to include the changes suggested by Jeevan. This
> patch also implements the thread workers instead of
> processes and fetches a single file at a time. The tar format has been
> disabled for first version of parallel
Robert Haas writes:
> On Mon, Oct 28, 2019 at 10:07 AM Tom Lane wrote:
>> Of course neither of those ideas is as short as "==", but
>> I think we should put some weight on not breaking things.
>> I do not believe Robert's position that nobody will complain
>> if we break extensions' use of "=="
Hi,
PostgreSQL 10 introduced extended statistics, allowing us to consider
correlation between columns to improve estimates, and PostgreSQL 12
added support for MCV statistics. But we still had the limitation that
we only allowed using a single extended statistics per relation, i.e.
given a table
On 2019-Oct-28, Michael Paquier wrote:
> On Sun, Oct 27, 2019 at 07:12:07PM -0500, Justin Pryzby wrote:
> > commit #898e5e32 (Allow ATTACH PARTITION with only ShareUpdateExclusiveLock)
> > updates ddl.sgml but not alter_table.sgml, which only says:
> >
> >
Greetings hackers,
Before PG12, select strpos('test', '') returns 1 (empty substring found at
first position of the string), whereas starting with PG12 it returns 0
(empty substring not found).
Is this behavior change intentional? If so, it doesn't seem to be
documented in the release notes...
On 2019-Oct-23, Michael Paquier wrote:
> On Wed, Oct 23, 2019 at 11:16:25AM +0900, Amit Langote wrote:
> > IMO, parts of the patch that only refactors the existing code should
> > be first in the list as it is easier to review, especially if it adds
> > no new concepts. In this case, your patch
On Mon, Oct 28, 2019, at 08:52, Andrew Dunstan wrote:
>
> For release 13+, I have given some more thought to what should be done.
> I think the bar for altering the behaviour of a function should be
> rather higher than we have in the present case, and the longer the
> function has been
On Mon, Oct 28, 2019 at 10:07 AM Tom Lane wrote:
> I kind of like AINT ;-) ... although adding two new short,
> fully-reserved words is likely to cause push-back from people
> whose schemas get broken by that.
>
> A more practical answer might be to allow these to be abbreviated
> along the lines
08.10.2019 17:08, Stephen Frost wrote:
I attached the updated version. Now it prints a better error message
and generates an SQL script instead of multiple warnings. The attached test
script shows that.
Have you tested this with extensions, where the user has changed the
privileges on the
Hi - is this likely to be applied to an upcoming release? / How does a novice
apply a patch..?
Thanks
-Original Message-
From: Juan José Santamaría Flecha
Sent: 04 September 2019 22:48
To: Tom Lane
Cc: Michael Paquier ; williamedwinal...@live.com;
pgsql-b...@lists.postgresql.org;
Andrew Dunstan writes:
> On 10/28/19 8:37 AM, Robert Haas wrote:
>> I certainly agree with that. I do think, though, that IS DISTINCT FROM
>> is a terribly verbose thing to have to write all the time. It's not
>> that bad when you write a query that contains one instance of it, but
>> I've both
On Mon, 28 Oct 2019 at 13:31, Andrew Dunstan
wrote:
> How about instead of new operators we just provide a nice shorthand way
> of saying these? e.g. ARE and AINT :-)
Seems to me like this is something that those users who want it can
implement for themselves with little to no effort without
Hi
In our usage scenario the standby node could be OOM killed and we have to
create new standby node.
If master node has uncommitted long transaction and new standby node can not
provide service.
So for us this is a critical issue.
I do hope any suggestion to this issue.
And can any one help
On 10/21/19 9:28 AM, Andrew Dunstan wrote:
> On 10/21/19 2:07 AM, Tomas Vondra wrote:
>> On Sun, Oct 20, 2019 at 06:51:05PM -0400, Andrew Dunstan wrote:
I think the general premise of this thread is that the application
developer does not realize that may be necessary, because it's a
On 28.10.2019 15:13, Robert Haas wrote:
On Fri, Oct 25, 2019 at 12:22 PM Konstantin Knizhnik
wrote:
On 25.10.2019 18:01, Robert Haas wrote:
On Fri, Oct 11, 2019 at 9:50 AM Konstantin Knizhnik
wrote:
Just to clarify.
I have now proposed several different solutions for GTT:
Shared vs.
Kyotaro Horiguchi writes:
> At Sat, 26 Oct 2019 08:55:03 +0200, Peter Eisentraut
> wrote in
>> IDENT_USERNAME_MAX is the maximum length of the information returned
>> by an ident server, per RFC 1413. Using it as the buffer size in peer
>> authentication is inappropriate. It was done here
On 28.10.2019 15:07, Robert Haas wrote:
On Fri, Oct 25, 2019 at 11:14 AM Pavel Stehule wrote:
Access to GTT at replica:
1. Access is prohibited (as for original temp tables). No changes at all.
2. Tuples of temp tables are marked with forzen XID. Minimal changes,
rollbacks are not
Hello Masao-san,
Maybe. If you cannot check, you can only guess. Probably it should be
small, but the current version does not allow to check whether it is so.
Could you elaborate what you actually want to measure the performance
impact by adding explicit begin and commit? Currently pgbench
On 10/28/19 8:37 AM, Robert Haas wrote:
> On Mon, Oct 28, 2019 at 7:54 AM Isaac Morland wrote:
>> Postgres already allows != as a synonym for <>. I think having =! mean
>> something subtly but significantly different is a terrible idea. At a
>> minimum we would have to remove the synonym,
Would it be possible to just use `IS`, `IS NOT` instead of `IS [NOT]
DISTINCT FROM`? It's always surprised me that you can write `IS NULL`, `IS
TRUE`, etc. but they're all special-cased. I could see it introducing a
parsing ambiguity, but it doesn't seem impossible to resolve?
On Mon, Oct 28,
On Mon, Oct 28, 2019 at 5:01 AM Peter Eisentraut
wrote:
> This patch adds const qualifiers to internal range type APIs. It
> doesn't require any new casts or remove any old ones.
Just out of curiosity, what is the motivation for this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
On Fri, Oct 25, 2019 at 12:38 PM Tom Lane wrote:
> end of things. And allowing arbitrary queries to go over a postgres_fdw
> connection would be absolutely disastrous from a debuggability and
> maintainability standpoint, because they might change the remote
> session's state in ways that
As mentioned in [0], pg_upgrade currently does not preserve the version
of collation objects created by initdb. Here is an attempt to fix that.
The way I deal with this here is by having the binary-upgrade mode in
pg_dump delete all the collations created by initdb and then dump out
CREATE
On Fri, Oct 25, 2019 at 10:45 PM Vik Fearing
wrote:
> >
> > I don't understand what you mean by this.
> >
> >
> >
> > The primary purpose of adding row end time to primary key is to allow
> > duplicate value to be inserted into a table with keeping constraint in
> > current data but it can
po 28. 10. 2019 v 12:39 odesílatel Eugen Konkov napsal:
> > x IS NOT DISTINCT FROM y
>
> > I'm vaguely imagining
>
> > x = {magic} y
>
> > where unlike Eugen's suggestion, "=" is the real name of the underlying
> > comparison operator. For dump/restore this could be spelled
On Mon, Oct 28, 2019 at 4:43 AM Peter Eisentraut
wrote:
> Here is a new implementation that works just like that.
This looks like a marked notational improvement.
With the patch:
[rhaas pgsql]$ git grep PG_CATCH | wc -l
102
[rhaas pgsql]$ git grep PG_FINALLY | wc -l
55
I'm actually
On Mon, Oct 28, 2019 at 7:54 AM Isaac Morland wrote:
> Postgres already allows != as a synonym for <>. I think having =! mean
> something subtly but significantly different is a terrible idea. At a minimum
> we would have to remove the synonym, which would be a backwards compatibility
> break.
On Fri, Oct 25, 2019 at 12:22 PM Konstantin Knizhnik
wrote:
> On 25.10.2019 18:01, Robert Haas wrote:
> > On Fri, Oct 11, 2019 at 9:50 AM Konstantin Knizhnik
> > wrote:
> >> Just to clarify.
> >> I have now proposed several different solutions for GTT:
> >>
> >> Shared vs. private buffers for
On Fri, Oct 25, 2019 at 11:14 AM Pavel Stehule wrote:
>> > Access to GTT at replica:
>> > 1. Access is prohibited (as for original temp tables). No changes at all.
>> > 2. Tuples of temp tables are marked with forzen XID. Minimal changes,
>> > rollbacks are not possible.
>> > 3. Providing
On Mon, 28 Oct 2019 at 07:39, Eugen Konkov wrote:
If we should follow this form, then IS DISTINCT should be written as:
> x =! y
> This looks unusual, because JavaScript also follow != form. so I hope
> it will be easy to detect/implement != form, which I used to read as:
> negate the result
> x IS NOT DISTINCT FROM y
> I'm vaguely imagining
> x = {magic} y
> where unlike Eugen's suggestion, "=" is the real name of the underlying
> comparison operator. For dump/restore this could be spelled verbosely
> as
> x OPERATOR(someplace.=) {magic} y
> The hard
Hi Alexander,
On Sun, Oct 27, 2019 at 7:04 PM Alexander Korotkov
wrote:
> It tool me a lot of efforts to revise a concurrency section in README.
> I can't judge the result, but I probably did my best. I'd like to
> commit this patchset including both bug fixes and README update. But
> I'd like
On Sun, Oct 27, 2019 at 7:07 PM David Fetter wrote:
>
> There's a SQL MED standard feature for CREATE ROUTINE MAPPING that
> does something similar to this. Might it be possible to incorporate
> it into the previous patch that implemented that feature?
Thanks for the idea, David. I'll
On Fri, Oct 25, 2019 at 9:19 PM Masahiko Sawada wrote:
>
> On Fri, Oct 25, 2019 at 2:06 PM Dilip Kumar wrote:
> >
> > On Fri, Oct 25, 2019 at 10:22 AM Masahiko Sawada
> > wrote:
> > >
> > > For more detail of my idea it is that the first worker who entered to
> > > vacuum_delay_point adds its
This patch adds const qualifiers to internal range type APIs. It
doesn't require any new casts or remove any old ones.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From
On 2018-12-14 16:49, Tom Lane wrote:
I don't especially like the MACRO({...}) proposal, because it looks way
too much like gcc's special syntax for "statement expressions". If we
have to go this way, I'd rather see if MACRO((...)) can be made to work.
But I question your assumption that we have
Updated patch attached.
On 2019-09-18 10:31, Michael Paquier wrote:
-* Verify XLOG status looks valid.
+* Check that contents look valid.
*/
- if (ControlFile->state < DB_SHUTDOWNED ||
- ControlFile->state > DB_IN_PRODUCTION ||
-
On Fri, Oct 25, 2019 at 09:54:53AM +0300, Heikki Linnakangas wrote:
> No particular reason, it's just a nice round value in decimal.
Well:
$ pg_controldata | grep -i fake
Fake LSN counter for unlogged rels: 0/3E8
;p
--
Michael
signature.asc
Description: PGP signature
On Mon, Oct 28, 2019 at 12:20 PM Amit Kapila wrote:
>
> On Sun, Oct 27, 2019 at 12:52 PM Dilip Kumar wrote:
> >
> > On Fri, Oct 25, 2019 at 9:19 PM Masahiko Sawada
> > wrote:
> > >
> > >
> > I haven't yet read the new set of the patch. But, I have noticed one
> > thing. That we are getting
Thank you for your response.
> By the way the table mentions the phases common to CLUSTER and VACUUM FULL. I
> wonder why some of them are described as "CLUSTER is" and others are "The
> command is"..
The 'writing new heap' phase seems to appear only when the CLUSTER statement is
executed.
On Sat, Oct 26, 2019 at 11:45 AM Michael Paquier wrote:
> On Fri, Oct 25, 2019 at 04:42:24PM +0900, Amit Langote wrote:
> > Hmm, if we're inventing a new API to replace the old one, why not use
> > that opportunity to be consistent with our general style, which
> > predominantly seems to be
Hi,
Currently, we need to scan the WHOLE shared buffers when VACUUM
truncated off any empty pages at end of transaction or when relation
is TRUNCATEd.
As for our customer case, we periodically truncate thousands of tables,
and it's possible to TRUNCATE single table per transaction. This can be
On Sun, Oct 27, 2019 at 07:12:07PM -0500, Justin Pryzby wrote:
> commit #898e5e32 (Allow ATTACH PARTITION with only ShareUpdateExclusiveLock)
> updates ddl.sgml but not alter_table.sgml, which only says:
>
> https://www.postgresql.org/docs/12/release-12.html
> |An ACCESS EXCLUSIVE lock is held
On Fri, Oct 25, 2019 at 12:06 AM Fabien COELHO wrote:
>
>
> Hello,
>
> >> Yep. Or anything else, including without (), to allow checking the
> >> performance impact or non impact of transactions on the initialization
> >> phase.
> >
> > Is there actually such performance impact? AFAIR most
At Fri, 25 Oct 2019 12:28:38 -0400, Tom Lane wrote in
> Jehan-Guillaume de Rorthais writes:
> > When investigating for the bug reported in thread "logical replication -
> > negative bitmapset member not allowed", I found a way to seg fault
> > postgresql
> > only when cassert is enabled.
> >
On Thu, Oct 24, 2019 at 01:59:29PM +0900, Michael Paquier wrote:
> Yes, I can confirm the report. In the case of this scenario the
> reindex is waiting for the first transaction to finish before step 5,
> the cancellation causing the follow-up process to not be done
> (set_dead & the next ones).
> 2019年10月26日 上午12:22，Konstantin Knizhnik 写道：
>
>
>
> On 25.10.2019 18:01, Robert Haas wrote:
>> On Fri, Oct 11, 2019 at 9:50 AM Konstantin Knizhnik
>> wrote:
>>> Just to clarify.
>>> I have now proposed several different solutions for GTT:
>>>
>>> Shared vs. private buffers for GTT:
>>>
On Sun, Oct 27, 2019 at 12:52 PM Dilip Kumar wrote:
>
> On Fri, Oct 25, 2019 at 9:19 PM Masahiko Sawada wrote:
> >
> >
> I haven't yet read the new set of the patch. But, I have noticed one
> thing. That we are getting the size of the statistics using the AM
> routine. But, we are copying
Hi Andres,
Apologies, I realize my understanding of symbol resolution and the
referenced_functions mechanism wasn't correct. Thank you for your very
helpful
explanations.
> There's also a related edge-case where are unable to figure out a symbol
> name in llvm_function_reference(), and then
On Mon, Oct 28, 2019 at 02:26:39PM +0900, Kyotaro Horiguchi wrote:
> By the way the table mentions the phases common to CLUSTER and
> VACUUM FULL. I wonder why some of them are described as "CLUSTER is"
> and others are "The command is"..
Because VACUUM FULL does not use the sort-and-scan mode,
On Fri, Oct 25, 2019 at 03:43:18PM +0900, Michael Paquier wrote:
> Attached is a patch to fix the issue. As we know that the old index
> will have a definition and dependencies that match with the old one, I
> think that we should just remove any dependency records on the new
> index before
On Sat, Oct 26, 2019 at 10:49 PM Tom Lane wrote:
>
> I'm inclined to think that we need to make ecpglib.h's bool-related
> definitions exactly match c.h, which will mean that it has to pull in
> on most platforms, which will mean adding a control symbol
> for that to ecpg_config.h. I do not
90 matches
Mail list logo
