> 11 янв. 2020 г., в 7:34, Bruce Momjian написал(а):
>
> Actually, it might be worse than that. In my reading of
> RecordTransactionCommit(), we do this:
>
> write to WAL
> flush WAL (durable)
> make visible to other backends
> replicate
> communicate to the cli
On Sat, Jan 11, 2020 at 10:34:20AM +0900, Michael Paquier wrote:
> Thanks for the lookup. I'll look at that again in a couple of days
> and hopefully wrap it by then.
And done.
--
Michael
signature.asc
Description: PGP signature
On Fri, 2020-01-10 at 09:29 -0500, Tom Lane wrote:
> > ALTER SYSTEM is read only in my mind.
>
> I'm still having trouble with this conclusion. I think it can only
> be justified by a very narrow reading of "reflected in pg_dump"
> that relies on the specific factorization we've chosen for upgrad
Laurenz Albe writes:
> Perhaps it would be good to consider this question:
> Do we call something "read-only" if it changes nothing, or do we call it
> "read-only" if it is allowed on a streaming replication standby?
> The first would be more correct, but the second may be more convenient.
Yeah,
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:tested, passed
I like this patch, because I used similar functionality some year
On Fri, Jan 10, 2020 at 10:51:50PM -0500, Tom Lane wrote:
! Here's a draft patch that cleans up all the logic errors I could find.
Okiee, thank You!
Let's see (was a bit busy yesterday trying to upgrade pgadmin3 -
difficult matter), now lets sort this out:
With the first patch applied (as from Fr
Peter writes:
> With the first patch applied (as from Friday - applied only on the
> client side), the application did appear to work well.
> But then, when engaging bandwidth-limiting to some modem-speed, it did
> not work: psql would receive all (or most of) the data from a SELECT,
> but then so
On Wed, Jan 08, 2020 at 02:49:48PM +1300, Thomas Munro wrote:
> On Sun, Dec 29, 2019 at 8:02 PM Noah Misch wrote:
> > ==00:00:00:28.322 1527557== Source and destination overlap in
> > memcpy(0x1000104, 0x1000104, 4)
> > ==00:00:00:28.322 1527557==at 0x4C2E74D: memcpy@@GLIBC_2.14
> > (vg_repl
Joe Nelson wrote:
> > I see this patch has been moved to the next commitfest. What's the next
> > step, does it need another review?
Peter Eisentraut wrote:
> I think you need to promote your patch better.
Thanks for taking the time to revive this thread.
Quick sales pitch for the patch:
* Stan
While reading the code for heapam.c:heap_multi_insert I happened upon this
comment which I'm either too thick for, or it lacks a word or two:
* ..
* A check here does not definitively prevent a serialization anomaly;
* that check MUST be done at least past the point of acquiring an
Daniel Gustafsson writes:
> The part I don't understand is "otherwise there race condition", it doesn't
> sound complete to me as a non-native english speaker. Should that really be
> "otherwise there *is a (potential)* race condition" or something similar?
I agree, it's missing "is a".
> On 13 Jan 2020, at 00:25, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> The part I don't understand is "otherwise there race condition", it doesn't
>> sound complete to me as a non-native english speaker. Should that really be
>> "otherwise there *is a (potential)* race condition" or somet
John Naylor writes:
>> I no longer use state variables to track scanner state, and in fact I
>> removed the existing "state_before" variable in ECPG. Instead, I used
>> the Flex builtins yy_push_state(), yy_pop_state(), and yy_top_state().
>> These have been a feature for a long time, it seems, so
Hi,
I've pushed these two improvements after some minor improvements, mostly
to comments. I ended up not using the extra tests, as it wasn't clear to
me it's worth the extra duration.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remot
On Sun, Dec 29, 2019 at 01:15:24PM -0500, Jeff Janes wrote:
> On Fri, Dec 20, 2019 at 12:11 PM Justin Pryzby wrote:
>
> > This is a usability complaint. If one knows enough about vacuum and/or
> > logging, I'm sure there's no issue.
>
> > | 11 DEBUG: "t": found 999 removable, 999 nonremovable
On Mon, Jan 06, 2020 at 11:26:06PM -0600, Justin Pryzby wrote:
> As Jeff has pointed out, high correlation has two effects in cost_index():
> 1) the number of pages read will be less;
> 2) the pages will be read more sequentially;
>
> cost_index reuses the pages_fetched variable, so (1) isn't part
On Thu, Jan 9, 2020 at 4:41 PM Mahendra Singh Thalor wrote:
>
> On Mon, 9 Dec 2019 at 14:37, Amit Kapila wrote:
> >
> > On Mon, Dec 9, 2019 at 2:27 PM Amit Kapila wrote:
> > >
> > > I have modified the patch for the above points and additionally ran
> > > pgindent. Let me know what you think ab
On Sat, Jan 11, 2020 at 7:48 PM Masahiko Sawada
wrote:
>
> On Sat, 11 Jan 2020 at 13:18, Amit Kapila wrote:
> >
> > On Sat, Jan 11, 2020 at 9:23 AM Masahiko Sawada
> > wrote:
> > >
> > > On Fri, 10 Jan 2020 at 20:54, Mahendra Singh Thalor
> > > wrote:
> > > >
> > > > On Fri, 10 Jan 2020 at 15:
On Mon, Jan 13, 2020 at 9:20 AM Amit Kapila wrote:
>
> On Sat, Jan 11, 2020 at 7:48 PM Masahiko Sawada
> wrote:
> >
> > On Sat, 11 Jan 2020 at 13:18, Amit Kapila wrote:
> > >
> > > On Sat, Jan 11, 2020 at 9:23 AM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Fri, 10 Jan 2020 at 20:54, Mahendr
This diff fixes what I consider a typo.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/include/access/session.h b/src/include/access/session.h
index ac552105b9..4c1f6ffd40 100644
--- a/src/include/access/session.h
+++ b/src/include/access/session.h
@@ -19,7 +19,7 @@
During one of my works for logical rewrite, I want to check if the expr is
a given Expr.
so the simplest way is:
if (expr->opno == 418 && nodeTag(linitial(expr->args)) == T_xxx &&
nodeTag(lsecond(expr->args)) == T_ )
{
..
}
if we write code like above, we may have issues if the oid change
21 matches
Mail list logo
