Alexander Korotkov wrote:
> The problem is that you need to have not only opclass entries for the
> operators, but also operators themselves. I.e. separate operators for
> int4[] @>> int8, int4[] @>> int4, int4[] @>> int2, int4[] @>> numeric. You
> tried to add multiple pg_amop rows for single o
Robert Haas wrote:
> On Wed, Jul 19, 2017 at 8:26 AM, Neha Sharma
> wrote:
> > I am getting FailedAssertion while executing the attached script.However,I
> > am not able to produce the core dump for the same,the script runs in
> > background and takes around a day time to produce the mentioned err
Mark Rofail wrote:
> On Tue, Jul 18, 2017 at 11:14 PM, Alvaro Herrera
> wrote:
> >
> > Why did we add an operator and not a support
> > procedure?
>
> I thought the support procedures were constant within an opclass.
Uhh ... I apologize but I think I was bar
Peter Geoghegan wrote:
> Index bloat is a general problem that B-Trees have in all other major
> systems, but I think that PostgreSQL has a tendency to allow indexes
> to become progressively more bloated over time, in a way that it often
> can never recover from [1].
Interesting assertion. Many
Michael Paquier wrote:
> - getObjectDescription and getObjectIdentity are called in quite a
> couple of places. We could have those have a kind of missing_ok, but
> as the status is just for adding cache lookup errors I have kept the
> interface simple as this keeps the code in objectaddress.c mor
Michael Paquier wrote:
> On Thu, Jul 20, 2017 at 4:04 PM, Alvaro Herrera
> wrote:
> > I think the addition of checks everywhere for NULL return is worse.
> > Let's add a missing_ok flag instead, so that most callers can just trust
> > that they get a non null value if
Kyotaro HORIGUCHI wrote:
> Finally, I added a new TAP test library PsqlSession. It offers
> interactive psql sessions. Then added a simple test to
> postgres_fdw using it.
Hmm, I think this can be very useful for other things. Let's keep this
in mind to use in the future, even if we find another
Robert Haas wrote:
> I think those top-of-file lists are just annoying, and would prefer to
> rip them out entirely rather than spend time maintaining them.
+1
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-
Tom Lane wrote:
> We could stabilize this test result by forcing lc_messages = C in
> the foreign server options. However, that would lose regression
> coverage of situations where the remote locale is different, which
> doesn't seem like a terribly good thing.
I don't understand what is the ben
I'm back at looking into this again, after a rather exhausting week. I
think I have a better grasp of what is going on in this code now, and it
appears to me that we should change the locking so that active_pid is
protected by ReplicationSlotControlLock instead of the slot's spinlock;
but I haven'
Alvaro Herrera wrote:
> I'm back at looking into this again, after a rather exhausting week. I
> think I have a better grasp of what is going on in this code now,
Here's an updated patch, which I intend to push tomorrow.
> and it
> appears to me that we should chan
Petr Jelinek wrote:
> On 25/07/17 01:33, Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> >> I'm back at looking into this again, after a rather exhausting week. I
> >> think I have a better grasp of what is going on in this code now,
> >
> > Her
Kunshchikov Vladimir wrote:
> Errors should be like this:
> pg_restore: [compress_io] could not read from input file: d3/2811.dat.gz:
> invalid distance too far back
>
> Attached small fix for this issue.
After looking at this patch, I don't like it very much. In particular,
I don't like the w
Chapman Flack wrote:
> Any takers if I propose this amendment in the form of a patch?
>
> Relying on the perl idiom instead of a $node->isa() test shortens
> the patch; does that ameliorate at all the concern about complicating
> core for the benefit of modules?
Yeah, I like this (I also got wor
atorikoshi wrote:
> Attached patch removes the comments about min_group_size.
Agreed. Removed those comments. Thanks for the patch.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers
Kunshchikov Vladimir wrote:
> Hello Alvaro, thanks for the feedback, fixed all of your points.
> Attached new version of patch.
Looks great -- it's a lot smaller than the original even. One final
touch -- see cfread(), where we have an #ifdef where we test for
fp->compressedfp; the "#else" branc
Amit Kapila wrote:
> On Sat, Jul 15, 2017 at 2:30 AM, Alvaro Herrera
> wrote:
> > a transaction wants to lock the
> > updated version of some tuple, and it does so; and some other
> > transaction is also locking the same tuple concurrently in a compatible
> > way
Robert Haas wrote:
> On Wed, Jul 26, 2017 at 5:38 AM, Ashutosh Bapat
> wrote:
> > According to F.34.1.1 at [1] passing connection string as dbname
> > option should work, so your question is valid. I am not aware of any
> > discussion around this on hackers. Comments in connect_pg_server()
> > don
> The attached patch fixes the problem. When locking some old tuple version of
> the chain, if we detect that we already hold that lock
> (test_lockmode_for_conflict returns HeapTupleSelfUpdated), do not try to lock
> it again but instead skip ahead to the next version. This fixes the synthetic
>
Alvaro Herrera wrote:
> Hmm, yeah, that's not good. However, I didn't like the idea of putting
> it inside the locked area, as it's too much code. Instead I added just
> before acquiring the spinlock. We cancel the sleep unconditionally
> later on if we didn't
Claudio Freire wrote:
> > The vacuuming the very large table with no index could also take a
> > long time, and it scans and vacuums blocks one by one. So I imagined
> > that we can vacuum the FSM once vacuumed a certain amount of blocks.
> > And that can avoid bloating table during the long-time
Claudio Freire wrote:
> On Thu, Jul 27, 2017 at 1:46 PM, Alvaro Herrera
> wrote:
> > Claudio Freire wrote:
> >
> >> > The vacuuming the very large table with no index could also take a
> >> > long time, and it scans and vacuums blocks one by one. So I
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > Hmm, yeah, that's not good. However, I didn't like the idea of putting
> > it inside the locked area, as it's too much code. Instead I added just
> > before acquiring the spinlock. We cancel the sleep un
Kunshchikov Vladimir wrote:
> Hello Alvaro,
>
> here goes v4 version: removed unused header.
>
> Compilation of this code snippet with -Wall -Wexter -std=c89 doesn't produce
> any warnings.
Great, thanks.
+const char *
+get_cfp_error(cfp* fp)
+{
+#ifdef HAVE_LIBZ
+ if(fp->compressedfp){
Vladimir Kunschikov wrote:
> >This "maxlen" business and the fallback error message are
> >strange. We have roughly equivalent code in pg_basebackup.c
> >which has been working since 2011
> >Perhaps you can drop the memchr/fallback tricks and adopt the
> >pg_basebackup coding? Or is there a speci
Mark Rofail wrote:
> These are limitations of the patch ordered by importance:
>
> ✗ presupposes that count(distinct y) has exactly the same notion of
> equality that the PK unique index has. In reality, count(distinct) will
> fall back to the default btree opclass for the array element type.
Ope
Tom Lane wrote:
> Alvaro Herrera writes:
> > ... However, when you create an index, you can
> > indicate which operator class to use, and it may not be the default one.
> > If a different one is chosen at index creation time, then a query using
> > COUNT(distin
Robert Haas wrote:
> An alternative approach is to have some kind of other identifier,
> let's call it a distributed transaction ID (DXID) which is mapped by
> each node onto a local XID.
Postgres-XL seems to manage this problem by using a transaction manager
node, which is in charge of assigning
Andres Freund wrote:
> On 2017-08-01 13:48:34 -0400, Robert Haas wrote:
> > On Tue, Aug 1, 2017 at 1:39 PM, Andres Freund wrote:
> > > Oid is probably not good enough - with parallel tests and such it's not
> > > necessarily predicable. Even less so when the tests are run against an
> > > existing
I think pg_class is a reasonable place to put more generic relkind lists
alongside a matching error message for each, rather than specialized
"does this relkind have storage" macros. What about something like a
struct list in pg_class.h,
{
{
relkinds_r_i_T,
{ 'r', 'i', 'T' },
Alvaro Herrera wrote:
> I think pg_class is a reasonable place to put more generic relkind lists
> alongside a matching error message for each, rather than specialized
> "does this relkind have storage" macros. What about something like a
> struct list in pg_class.h,
I
Peter Eisentraut wrote:
> I don't find this style of error message optimal anyway. If I do, for
> example
>
> ALTER TABLE someview ADD CONSTRAINT ...
> ERROR: "someview" is not a table, foreign table, whatever
>
> then this information is not helpful. It's not like I'm going to turn
> my view
Petr Jelinek wrote:
> I split it into several patches:
I wish you'd stop splitting error message strings across multiple lines.
I've been trapped by a faulty grep not matching a split error message a
number of times :-( I know by now to remove words until I get a match,
but it seems an unnecessa
Kunshchikov Vladimir wrote:
> Hello Alvaro,
>
> here goes v4 version: removed unused header.
>
> Compilation of this code snippet with -Wall -Wexter -std=c89 doesn't produce
> any warnings.
Great, thanks! I have pushed this to all branches since 9.4. Would you
please give it a look? Please l
Alvaro Herrera wrote:
> Fix pg_dump's errno checking for zlib I/O
So this broke a few buildfarm members. I'll into it tomorrow.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent
Peter Eisentraut wrote:
> Add new files to nls.mk and add translation markers
This reminds me that I noticed a few days ago another really serious
broken piece in pg_upgrade where check_required_directory() is incurring
in the ugliest case of string building I've ever seen. I didn't have
the cour
Joe Conway wrote:
> On 08/02/2017 10:52 PM, Ashutosh Bapat wrote:
> > On Wed, Aug 2, 2017 at 11:15 PM, Alvaro Herrera
> > wrote:
> >> Alvaro Herrera wrote:
> >>> I think pg_class is a reasonable place to put more generic relkind lists
> >>> alongsid
Peter Eisentraut wrote:
> Is there a preferred method to select between using elog() and
> errmsg_internal()?
>
> Attached is a patch that converts some DEBUG messages to one of those
> two to remove them from translation, but I'm not sure which one to pick
> other than by random aesthetics.
I th
Tom Lane wrote:
> I think Peter's got the error and the detail backwards. It should be
> more like
>
> ERROR: "someview" cannot have constraints
> DETAIL: "someview" is a view.
>
> If we do it like that, we need one ERROR message per error reason,
> and one DETAIL per relkind, which should be m
Robert Haas wrote:
> I think this approach is actually better anyway. There's no guarantee
> that VACUUM can be responsive enough to get the job done in time, work
> items or no work items,
Yeah, autovacuum work items don't have a guaranteed response time.
They're okay for things that "ought to
Masahiko Sawada wrote:
> While hacking the btree code I found two points we can improve in nbtxlog.c.
>
> @@ -135,7 +135,7 @@ _bt_clear_incomplete_split(XLogReaderState
> *record, uint8 block_id)
> Pagepage = (Page) BufferGetPage(buf);
> BTPageOpaque pa
Андрей Бородин wrote:
> ==What==
> I propose to add hook inside BufferSync() function it inform extensions that
> we
> are going to write pages to disk. Please see patch attached. I pass a
> timestamp
> of the checkpoint, but it would be good if we could also pass there number of
> checkpoint or
Mengxing Liu wrote:
> In the last week, I focus on:
>
>
> 1) Continuing on optimization of skip list.
Let me state once again that I'm certainly not an
expert in the predicate locks module and that I hope Kevin will chime in
with more useful feedback than mine.
Some random thoughts:
* I wonder
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > I just noticed that Jacana failed again in the subscription test, and it
> > looks like it's related to this. I'll take a look tomorrow if no one
> > beats me to it.
> > https://buildfarm.postgresql.org/cgi-bi
Robert Haas wrote:
> On Mon, Aug 7, 2017 at 8:14 PM, Alvaro Herrera
> wrote:
> > BTW, I noticed that the PG_WAIT_LOCK value that we're using for wait
> > event here (and in the replication slot case) is bogus. We probably
> > need something new here.
>
> Yeah
Thread moved to -hackers.
Thomas Munro wrote:
> On Wed, Aug 9, 2017 at 7:39 AM, Alvaro Herrera
> wrote:
> > While at it, fix numerous other problems in the vicinity:
> All of the above seem like good candidates for a checker script in
> src/tools/check_XXX.pl, a bit li
This thread is surprising. If we generate the few lines of code being
in trouble, we don't need any checker script, so I don't see why we'd go
the route of the checker script instead.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
Tom Lane wrote:
> I think generating whatever we can from a single authoritative file
> is indeed a good idea.
Yay.
> But I had the impression that people also wanted to enforce a rule
> about "only one use of each wait event name", which'd require a
> checker script, no? (I'm not really convin
Dean Rasheed wrote:
> On 9 August 2017 at 13:03, Robert Haas wrote:
> > On Tue, Aug 8, 2017 at 11:34 PM, Tom Lane wrote:
> >> A small suggestion is that it'd be better to write it like "Specified
> >> upper bound \"%s\" precedes lower bound \"%s\"." I think "succeeds" has
> >> more alternate mea
Masahiko Sawada wrote:
> Hi all,
>
> In snapbuild.c file, there is a comment as follows.
>
>* NB: Because of that xmax can be lower than xmin, because we only
>* increase xmax when a catalog modifying transaction commits. While odd
>* looking, it's correct and actually more efficient
Alvaro Herrera wrote:
> Masahiko Sawada wrote:
> > Hi all,
> >
> > In snapbuild.c file, there is a comment as follows.
> >
> >* NB: Because of that xmax can be lower than xmin, because we only
> >* increase xmax when a catalog modifying transact
Robert Haas wrote:
> Actually, now that you mention it, I think it *is* broken already, or
> more to the point, if you configure that value, the autovacuum
> launcher hangs up, because of the AutovacuumWorkItem stuff that Alvaro
> added. When I just tested it, the AV launcher somehow ended up
> w
autovacuum continues without workitem
support.
I intend to give these patches further thought before pushing anything,
will update this thread no later than tomorrow 19:00 UTC-0300.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Trainin
Robert Haas wrote:
> On Mon, Aug 14, 2017 at 1:12 PM, Alvaro Herrera
> wrote:
> > Yeah, the problem that lwlocks aren't released is because the launcher
> > is not in a transaction at that point, so AbortCurrentTransaction()
> > doesn't release locks like it nor
Michael Paquier wrote:
> On Tue, Aug 15, 2017 at 10:27 AM, Masahiko Sawada
> wrote:
> > Currently vacuum verbose outputs vacuum logs as follows. The first log
> > message INFO: vacuuming "public.hoge" writes the relation name with
> > schema name but subsequent vacuum logs output only relation na
Michael Paquier wrote:
> On Tue, Aug 15, 2017 at 11:14 AM, Alvaro Herrera
> wrote:
> >> In vacuum_rel()@vacuum.c, there are a couple of logs that could be
> >> improved as well with the schema name.
> >
> > I agree that there's a lot of room for improvem
Tom Lane wrote:
> Robert Haas writes:
> > I really, really strongly encourage you to rip the use of DSA out here
> > entirely. It is reducing the reliability of a critical part of the
> > system for no actual benefit other than speculation that this is going
> > to be better in the future, and it
Christoph Berg wrote:
> Re: Thomas Munro 2017-08-10
>
> > > Agreed. Here's a version that skips those useless detail messages
> > > using a coding pattern I found elsewhere.
> >
> > Rebased after bf6b9e94.
>
> > message ? errdetail("Diagnostic message: %s", message) : 0));
>
> "Diagnostic mes
Andres Freund wrote:
> On 2017-08-16 17:06:42 -0400, Tom Lane wrote:
> > If I understand what this is meant to do, maybe better
> > pg_move_replication_slot_lsn() or pg_change_replication_slot_lsn() ?
> > The point being that you're adjusting the LSN pointer contained
> > in the slot, which is dis
Ildar Musin wrote:
> While we've been developing pg_pathman extension one of the most frequent
> questions we got from our users was about global index support. We cannot
> provide it within an extension. And I couldn't find any recent discussion
> about someone implementing it. So I'm thinking ab
Erikjan Rijkers wrote:
> On 2017-08-18 11:12, Ildar Musin wrote:
> > Hi hackers,
> >
> > While we've been developing pg_pathman extension one of the most
> > frequent questions we got from our users was about global index
> > support. We cannot provide it within an extension. And I couldn't find
>
Ildar Musin wrote:
> I found the thread about indirect indexes
> (https://www.postgresql.org/message-id/20161018182843.xczrxsa2yd47pnru%40alvherre.pgsql),
> but it seems that it haven't been updated for some time and I couldn't
> find InMemoryIndexTuple in the latest patch. Is there a newer versio
bute list is the object key.
* In ndistinct, the value is now an integer rather than a floating point
number.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
commit 49695b5ef165b1736fab65d6443640c5529b6338[m
Aut
reSQL Development, 24x7 Support, Remote DBA, Training & Services
commit 237909c440054e97c09dc6e7711a4ca92892465b[m
Author: Alvaro Herrera
AuthorDate: Thu Apr 20 18:19:06 2017 -0300
CommitDate: Thu Apr 20 18:19:06 2017 -0300
Put WITH clause at the end
diff --git a/doc/src
Tom Lane wrote:
> After sleeping and thinking more, I've realized that the
> slow-bgworker-start issue actually exists on *every* platform, it's just
> harder to hit when select() is interruptable. But consider the case
> where multiple bgworker-start requests arrive while ServerLoop is
> activel
Simon Riggs wrote:
> Replication lag tracking for walsenders
>
> Adds write_lag, flush_lag and replay_lag cols to pg_stat_replication.
Did anyone notice that this seems to be causing buildfarm member 'tern'
to fail the recovery check? See here:
https://buildfarm.postgresql.org/cgi-bin/show_stag
David Rowley wrote:
> The attached small patched fixes an incorrect usage of an error code
> in the extended stats code.
Thanks for the report. I'm on vacation starting today until May 2nd.
If nobody commits this in the meantime, I'll get to it when I'm back.
--
Álvaro Herreraht
Petr Jelinek wrote:
> So the only way to fulfill the requirement you stated is to just not try
> to drop the slot, ever, on DROP SUBSCRIPTION. That makes the default
> behavior leave resources on upstream that will eventually cause that
> server to stop unless user notices before. I think we bette
Petr Jelinek wrote:
> On 02/05/17 18:00, Robert Haas wrote:
> > On Tue, May 2, 2017 at 11:49 AM, Alvaro Herrera
> > wrote:
> >> Petr Jelinek wrote:
> >>> So the only way to fulfill the requirement you stated is to just not try
> >>> to drop the
Robert Haas wrote:
> On Tue, May 2, 2017 at 12:25 PM, Alvaro Herrera
> wrote:
> > 2) don't drop because we know it won't work. I see two options:
> >c) ignore a drop slot failure, i.e. don't cause a transaction abort.
> > An easy way to implement
Alvaro Herrera wrote:
> While writing the recent ext.stats docs, I became annoyed by the output
> functions of the new types used by multivariate statistics: they are
> almost JSON, but not quite. Since they can become largish, I propose
> that we make a point of ensuring the out
Peter Eisentraut wrote:
> Most documentation and error messages still uses the term "transaction
> log" to refer to the write-ahead log. Here is a patch to rename that,
> which I think should be done, to match the xlog -> wal renaming in APIs.
+1 for the idea. I suggest grepping for "transaction
1 AND b = '1' AND c = 1;
-- create statistics
-CREATE STATISTICS func_deps_stat WITH (dependencies) ON (a, b, c) FROM
functional_dependencies;
+CREATE STATISTICS func_deps_stat USING (dependencies) ON (a, b, c) FROM
functional_dependencies;
ANALYZE functional_dependencies;
@@ -259,7 +2
Robert Haas wrote:
> I suspect that most users would find it more useful to capture all of
> the rows that the statement actually touched, regardless of whether
> they hit the named table or an inheritance child.
Yes, agreed. For the plain inheritance cases each row would need to
have an indicat
Alvaro Herrera wrote:
> In the meantime, I noticed that pg_dump support for extstats is not
> covered, which I'll go fix next.
Here I add one, which seems to work for me.
Considering that Stephen missed a terminating semicolon for test with
create_order 96 (the last one prior to my
David Fetter wrote:
> When we add a "temporary" GUC, we're taking on a gigantic burden.
> Either we support it forever somehow, or we put it on a deprecation
> schedule immediately and expect to be answering questions about it for
> years after it's been removed.
>
> -1 for the GUC.
Absolutely.
David Fetter wrote:
> On Wed, May 03, 2017 at 10:33:32AM -0700, David Fetter wrote:
> > On Wed, May 03, 2017 at 10:57:06AM -0300, Alvaro Herrera wrote:
> > > Peter Eisentraut wrote:
> > > > Most documentation and error messages still uses the term "transaction
Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > 2.
> > USING keyword, no brackets
> > CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1
> > WHERE partial-stuff;
> >
> > and if there are options, use the WITH for the optional par
Stephen Frost wrote:
> > Here I add one, which seems to work for me.
Pushed it -- I also added another one which specifies options, to test
WITH handling in ruleutils.
> > Considering that Stephen missed a terminating semicolon for test with
> > create_order 96 (the last one prior to my commit)
Andrew Dunstan wrote:
> On 05/03/2017 04:42 PM, Tom Lane wrote:
> > One other point is that as long as we've got reserved keywords introducing
> > each clause, there isn't actually an implementation reason why we couldn't
> > accept the clauses in any order. Not sure I want to document it that w
Tom Lane wrote:
> The other significant delay in stats.sql is
>
> -- force the rate-limiting logic in pgstat_report_stat() to time out
> -- and send a message
> SELECT pg_sleep(1.0);
>
> Now, we do seem to need a delay there, because the rate-limiting logic
> is unlikely to have permitted the co
Tom Lane wrote:
> But I agree with Andres' complaint that just duplicating the code isn't
> the best way. The configure script has a loop that's basically like
>
> for f in tclsh tcl tclsh8.6 tclsh86 tclsh8.5 tclsh85 tclsh8.4 tclsh84
> tclsh8.3 tclsh83
> do
>... break if $f is the right one
Andrew Dunstan wrote:
> Hadn't though about LATERAL, good point. Still, there will be other cases.
I'm not sure what your point is. We know that for some cases the
optimization barrier semantics are useful, which is why the proposal is
to add a keyword to install one explicitely:
with
Here's a patch implementing this idea. From gram.y's comment, the
support syntax is now:
/*
*
*QUERY :
! *CREATE STATISTICS stats_name [(stat types)] arguments
!
! *where 'ar
Claudio Freire wrote:
> On Tue, Apr 25, 2017 at 2:45 PM, Bruce Momjian wrote:
> > However, given your explanation, I have added the item:
> >
> >Improve speed of VACUUM's removal of trailing empty
> > heap pages (Alvaro Herrera)
>
> Tha
Bruce Momjian wrote:
> On Tue, Apr 25, 2017 at 04:03:53PM +1200, David Rowley wrote:
> > ..On 25 April 2017 at 13:31, Bruce Momjian wrote:
> > > The only unusual thing is that this release has ~180 items while most
> > > recent release have had ~220. The pattern I see that there are more
> > > l
Thanks for doing this, looks great. A few notes:
Add the ability to compute a correlation ratio and the number of
distinct values on several columns (Tomas Vondra, David Rowley)
I think this should be worded in terms of "extended data statistics" or
suc
Paresh More wrote:
> Hello Alvaro,
>
> I applied the patch which you mentioned and tried compiling postgresql
> server for windows 32 and 64 and the results are:-
>
> 1) postgresql server(96) with tcl version 8.5 is compiling fine with out
> any issue.
> 2) postgresql server(10) snapshot with tc
Fabien COELHO wrote:
>
> Here is a v3, with less files. I cannot say I find it better, but it still
> works.
>
> The "command_likes" function has been renamed "command_checks".
Do parts of this need to be backpatched? I notice that you're patching
pgbench.c, probably to fix some bug(s); is the
Hi Mengxing,
Mengxing Liu wrote:
> Hi, Alvaro and Kevin. I'm Mengxing.
>
> This is a “synchronization” email to tell you what I've done and my next
> plan. I'm looking forward to your advice.
Welcome!
> According to my proposal, I want to prepare the experimental environment
> during the
Thomas Munro wrote:
> Recall that transition tables can be specified for statement-level
> triggers AND row-level triggers. If you specify them for row-level
> triggers, then they can see all rows changed so far each time they
> fire.
Uhmm ... why do we do this? It seems like a great way to cau
I'm surprised that there is so much activity in this thread. Is this
patch being considered for pg10?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
FWIW I ended up reverting the whole thing, even from master. A more
complete solution would have to be researched.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-
Tom Lane wrote:
> Hmm ... I'm not sure that I buy that particular argument. If you're
> concerned that the grammar could not handle "FROM x JOIN y USING (z)",
> wouldn't it also have a problem with "FROM x JOIN y ON (z)"?
>
> It might work anyway, since the grammar should know whether ON or USIN
Tom Lane wrote:
> Have you thought further about the upthread suggestion to just borrow
> SELECT's syntax lock stock and barrel? That is, it'd look something
> like
>
> CREATE STATISTICS name [(list of stats types)] expression-list FROM ...
> [ WHERE ... ] [ WITH (options) ]
>
> This would
Tom Lane wrote:
> Have you thought further about the upthread suggestion to just borrow
> SELECT's syntax lock stock and barrel? That is, it'd look something
> like
>
> CREATE STATISTICS name [(list of stats types)] expression-list FROM ...
> [ WHERE ... ] [ WITH (options) ]
>
> This would
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Have you thought further about the upthread suggestion to just borrow
> >> SELECT's syntax lock stock and barrel?
>
> > Bison seems to like the productions below. Is this what you had in
&
Tom Lane wrote:
> Tomas Vondra writes:
> >> Although I've not done anything about it here, I'm not happy about the
> >> handling of dependencies for stats objects.
>
> > Yeah, it's a bit frankensteinian ...
>
> I'm prepared to create a fix for that, but it'd be easier to commit the
> current pa
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I'm prepared to create a fix for that, but it'd be easier to commit the
> >> current patch first, to avoid merge conflicts.
>
> > It seems we're mostly in agreement regarding the
Tom Lane wrote:
> I did not review the rest of the regression test changes, nor the
> tab-complete changes. I can however report that DROP STATISTICS
> doesn't successfully complete any stats object names.
The attached patch fixes this problem.
--
Álvaro Herrerahttps://www.2nd
901 - 1000 of 9812 matches
Mail list logo
