Hi,
Currently we do not try to pull up sub-select of type ANY_SUBLINK if it
refers to any Vars of the parent query, as indicated in the code snippet
below:
JoinExpr *
convert_ANY_sublink_to_join(PlannerInfo *root, SubLink *sublink,
Relids available_rels)
{
...
Hi, Tomas!
I took a look at this patchset.
On Tue, Jun 11, 2019 at 8:31 PM Tomas Vondra
wrote:
> Attached is this patch series, rebased on top of current master and the
> opclass parameters patch [1]. I previously planned to keep those two
> efforts separate for a while, but I decided to give it
Attached is new version:
- Rebased. Cleaned up
- Rebased to the current master
- Fixed a known bug in the first step patch. It caused
timeline-following failure on a standby of a promoted primary.
- Fixed confused naming and setting of the parameter
includes_paeg_header.
- Removed useless
Richard Guo wrote:
> Can we try to pull up direct-correlated ANY SubLink with the help of
> LATERAL?
> By this way, we can convert the query:
>
> select * from a where a.i = ANY(select i from b where a.j > b.j);
>
> To:
>
> select * from a SEMI JOIN lateral(select * from b where a.j > b.j)
>
writes:
> Hi,I just want know does PostgreSQL support debian Linux with ARM CPU
> Platform,Thank you!
The PostgreSQL community provided packages (https://apt.postgresql.org/)
are only built for amd64, i386 and ppc64el, but Debian itself ships
PostgreSQL on every architecture it supports.
Each
On Fri, Sep 6, 2019 at 5:07 PM Alvaro Herrera from 2ndQuadrant <
alvhe...@alvh.no-ip.org> wrote:
> On 2019-Sep-06, Surafel Temesgen wrote:
>
> > > ... yet this doesn't appear to have resulted in any change in the code,
> > > or I just missed it. Are you going to update the patch per that?
> >
> >
Hi Anastasia
On Thu, Aug 22, 2019 at 9:43 PM Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
>
> But during the review, I found a bug in the current implementation.
> New behavior must apply to crash-recovery only, now it applies to
archiveRecovery too.
> That can cause a silent loss
On Tue, Jul 23, 2019 at 1:53 PM Masahiko Sawada wrote:
>
>
> To invoke autovacuum even on insert-only tables we would need check
> the number of inserted tuples since last vacuum. I think we can keep
> track of the number of inserted tuples since last vacuum to the stats
> collector and add the th
On 2019-Sep-10, Tsunakawa, Takayuki wrote:
> Agreed. Fixed. I changed the CF status to "need review."
I have changed it again to "ready for committer". We could really use
help from a windows-enabled committer on this patch, I think.
--
Álvaro Herrerahttps://www.2ndQuadrant.c
Hi,
when the environment variable POSTGRESQL_UPGRADE_PGUPGRADE_OPTIONS is
used to specify options for pg_upgrade, options related to
unix_socket_directory/ies are being overridden by hardcoded options,
making it difficult to upgrade in some usecases.
The attached patch changes the order of those
[Casual readers with opinions on GUC naming: consider skipping to the end.]
MarkBufferDirtyHint() writes WAL even when rd_firstRelfilenodeSubid or
rd_createSubid is set; see attached test case. It needs to skip WAL whenever
RelationNeedsWAL() returns false.
On Tue, Aug 27, 2019 at 03:49:32PM +09
On Tue, Sep 10, 2019 at 1:36 AM Michael Paquier wrote:
> The error handling is awkward. I think that you should just call
> pg_log_error in pg_strtoint64_range instead of returning an error
> string as you do. You could do that by passing down the option name
> to the routine, and generate a new
On Fri, Sep 06, 2019 at 10:54:13AM -0700, Melanie Plageman wrote:
On Thu, Sep 5, 2019 at 10:35 PM Thomas Munro wrote:
Seems like a good time for me to try to summarise what I think the
main problems are here:
1. The match-bit storage problem already discussed. The tuples that
each process r
Alvaro Herrera 于2019年9月4日周三 上午4:12写道：
> > +static void
> > +init_toast_buffer(ToastBuffer *buf, int32 size, bool compressed)
> > +{
> > + buf->buf = (const char *) palloc0(size);
>
> This API is weird -- you always palloc the ToastBuffer first, then call
> init_toast_bufer on it. Why not pal
Hi,
Please don't top-post. If you're not responding to parts of the e-mail,
then don't quote it.
On Fri, Sep 06, 2019 at 12:50:33PM +0200, Esteban Zimanyi wrote:
Dear Tom
Many thanks for your quick reply. Indeed both solutions you proposed can be
combined together in order to solve all the pro
On Thu, Sep 05, 2019 at 09:54:33AM -0700, Melanie Plageman wrote:
On Tue, Sep 3, 2019 at 9:36 AM Alvaro Herrera
wrote:
On 2019-Jul-11, Tomas Vondra wrote:
> On Wed, Jul 10, 2019 at 04:51:02PM -0700, Melanie Plageman wrote:
> > I think implementing support for parallel hashjoin or explicitly
Richard Guo writes:
> Currently we do not try to pull up sub-select of type ANY_SUBLINK if it
> refers to any Vars of the parent query, as indicated in the code snippet
> below:
> if (contain_vars_of_level((Node *) subselect, 1))
> return NULL;
> Why do we have this check?
Because the
Patrik Novotny writes:
> when the environment variable POSTGRESQL_UPGRADE_PGUPGRADE_OPTIONS is
> used to specify options for pg_upgrade, options related to
> unix_socket_directory/ies are being overridden by hardcoded options,
> making it difficult to upgrade in some usecases.
> The attached patc
Hi Tom,
thanks for you reply. You're right, and I apologise for the confusion.
Options I was talking about are specified via the `--old-options`
parameter of the pg_upgrade (ex.: --old-options '-c
unix_socket_directories=/run')
Mentioning of the environment variable came only from my own
confusion
Patrik Novotny writes:
> thanks for you reply. You're right, and I apologise for the confusion.
> Options I was talking about are specified via the `--old-options`
> parameter of the pg_upgrade (ex.: --old-options '-c
> unix_socket_directories=/run')
> Mentioning of the environment variable came o
On 2019-Sep-09, Alvaro Herrera from 2ndQuadrant wrote:
> Question about 0001. In the CONNECTION_SETENV state, you end by falling
> through to the CONNECTION_CHECK_TARGET case; but in that switch it seems
> a bit unnatural to do that. I think doing "goto keep_trying" is another
> way of doing the
Hello,
On 2019-Apr-13, Tom Lane wrote:
> Andres Freund writes:
> > I think it probably would work for catalog tables, as it's coded right
> > now. There's no catalog lookups RelationInitTableAccessMethod() for
> > tables that return true for IsCatalogTable(). In fact, I think we should
> > appl
I have figured out another solution to the problem that macOS SIP
defeats the use of DYLD_LIBRARY_PATH for running the temp-install
regression tests. It's not without problems either, but it might show a
path forward.
First of all, I think I now know the exact mechanism by which this
breakage hap
Peter Eisentraut writes:
> I have figured out another solution to the problem that macOS SIP
> defeats the use of DYLD_LIBRARY_PATH for running the temp-install
> regression tests. It's not without problems either, but it might show a
> path forward.
> ...
> The precise issue is that /bin/sh filt
I propose to settle this issue by applying "Robert's changes two and
three", which has been +1'd by two people already and I also accept
myself as improvement. I don't think any further changes are required.
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index c1d1b6b2db..7afe7bf6
On 2019-Aug-01, Thomas Munro wrote:
> On Wed, Jun 26, 2019 at 6:38 AM Andres Freund wrote:
> > On 2019-06-20 09:30:34 +0200, Peter Eisentraut wrote:
> > > I'm looking for feedback from those who have worked on tableam and
> > > storage manager to see what the right interfaces are or whether some
On 2019-Sep-09, Paul Guo wrote:
> >
> > Thank for rebasing.
> >
> > I didn't like 0001 very much.
> >
> > * It seems now would be the time to stop pretending we're using a file
> > called recovery.conf; I know we still support older server versions that
> > use that file, but it sounds like we sho
I wrote:
> Patrik Novotny writes:
>> thanks for you reply. You're right, and I apologise for the confusion.
>> Options I was talking about are specified via the `--old-options`
>> parameter of the pg_upgrade (ex.: --old-options '-c
>> unix_socket_directories=/run')
>> Mentioning of the environment
Stephen Frost writes:
> * David Steele (da...@pgmasters.net) wrote:
>> On 9/3/19 12:04 PM, Tom Lane wrote:
>>> * Would it be better to substitute SIGTERM instead of SIGINT?
>>> The POSIX default handling is the same for both, but some programs
>>> might interpret them differently.
>> I prefer SIG
Hello,
On 2019-Sep-06, Andres Freund wrote:
> On 2019-08-19 08:51:43 -0700, Andres Freund wrote:
> > On August 19, 2019 7:43:28 AM PDT, Alvaro Herrera
> > wrote:
> > >Never mind. I was able to reproduce it later, and verify that Andres'
> > >proposed strategy doesn't seem to fix the problem.
So in this patch, the input restrictlist is modified to include the
clauses generated by generate_join_implied_equalities_for_all. That
doesn't seem okay -- doesn't it affect downstream usage of the
restrictlist in the caller of set_joinrel_size_estimates?
I wonder if it's possible to do this by
Thanks! I have pushed this patch. I didn't test on Windows, but I did
verify that it works with python2 and 3 on my Linux machine.
CLDR has made release 35 already, upon download of which the script
generates a few more lines in the unaccent.rules file, as attached.
--
Álvaro Herrera
On Tue, Sep 10, 2019 at 04:30:41AM +0300, Nikita Glukhov wrote:
On 04.09.2019 1:02, Alvaro Herrera wrote:
On 2019-Jun-11, Tomas Vondra wrote:
1) We need a better infrastructure to parse opclass parameters. For
example the gtsvector_options does this:
I think this is part of what Nikolay's pa
On Wed, Sep 11, 2019 at 12:03:58AM +0200, Tomas Vondra wrote:
On Tue, Sep 10, 2019 at 04:30:41AM +0300, Nikita Glukhov wrote:
On 04.09.2019 1:02, Alvaro Herrera wrote:
On 2019-Jun-11, Tomas Vondra wrote:
1) We need a better infrastructure to parse opclass parameters. For
example the gtsvecto
On 11.09.2019 1:14, Tomas Vondra wrote:
BTW, is there a place where we actually verify the signature of the
new am
proc? Because I only see code like this:
+ case OPCLASS_OPTIONS_PROC:
+ ok = true;
+ break;
in all "validate" functions.
See assignProcTypes() at src/backe
Martijn van Oosterhout writes:
> The original three patches have been collapsed into one as given the
> changes discussed it didn't make sense to keep them separate. There
> are now two patches (the third is just to help with testing):
> Patch 1: Tracks the listening backends in a list so non-lis
On 11.09.2019 1:03, Tomas Vondra wrote:
On Tue, Sep 10, 2019 at 04:30:41AM +0300, Nikita Glukhov wrote:
2. New AM method amattoptions().
amattoptions() is used to specify per-column AM-specific options.
The example is signature length for bloom indexes (patch #3).
I'm somewhat confused
On Fri, Sep 6, 2019 at 4:19 PM Tomas Vondra
wrote:
>
> On Wed, Sep 04, 2019 at 07:19:47PM +0300, Sergei Kornilov wrote:
> >
> > ...
> >
> >Results:
> >
> > test | mode | average_tps | degradation_perc
> >--+--+-+--
> > hea
Hello,
On Sun, Sep 8, 2019 at 11:45 AM Imai Yoshikazu wrote:
>
> I also saw the codes and have one comment.
Thanks for looking at this patch!
> [0002 patch]
> In pgss_planner_hook:
>
> + /* calc differences of buffer counters. */
> + bufusage = compute_buffer_counter
From: Alvaro Herrera from 2ndQuadrant [mailto:alvhe...@alvh.no-ip.org]
> Testing protocol version 2 is difficult! Almost every single test fails
> because of error messages being reported differently; and streaming
> replication (incl. pg_basebackup) doesn't work at all because it's not
> possible
On 2019-Sep-11, Tsunakawa, Takayuki wrote:
> From: Alvaro Herrera from 2ndQuadrant [mailto:alvhe...@alvh.no-ip.org]
> > Remaining patchset attached (per my count it's v13 of your patchset.
>
> I'm afraid those weren't attached.
Oh, oops. Here they are then.
--
Álvaro Herreraht
On Tue, Sep 03, 2019 at 02:38:56PM -0400, Alvaro Herrera wrote:
On 2019-Aug-01, Tomas Vondra wrote:
I'll move it to the next CF. Aside from the issues pointed by Kyotaro-san
in his review, I still haven't made my mind about whether to base the use
statistics targets set for the attributes. That
On 09.09.2019 22:47, Alexander Korotkov wrote:
On Mon, Sep 9, 2019 at 8:32 PM Nikita Glukhov wrote:
On 08.09.2019 22:32, Alexander Korotkov wrote:
On Fri, Sep 6, 2019 at 5:44 PM Alexander Korotkov
wrote:
I'm going to push both if no objections.
So, pushed!
Two years ago there was a simil
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> SIGTERM, which needs to be adjusted. For another, its
> SIGQUIT handler does exit(1) not _exit(2), which seems rather
> dubious ... should we make it more like the rest? I think
> the reasoning there might've been that if some DBA decides to
> SIGQUIT
Hi,
Please see attached draft of the PG12 Beta 4 press release.
I went through the list of open items that were resolved before beta
4[1] for the detailed please. Please let me know if I described any of
them incorrectly, or if you believe that any other fixes should be on
the list.
Thanks!
Jon
At Wed, 11 Sep 2019 01:36:15 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1FD33579@G01JPEXMBYT05>
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > SIGTERM, which needs to be adjusted. For another, its
> > SIGQUIT handler does exit(1) not _exit(2), which seems rather
>
On Mon, Sep 09, 2019 at 09:43:06AM +0900, Michael Paquier wrote:
> On Sun, Sep 08, 2019 at 07:44:16PM -0400, Tom Lane wrote:
>> The whole thing should be back-patched into branches that have
>> any affected tests. (But, please, not till after beta4 is
>> tagged.)
>
> Sure. Don't worry about that
On 9/10/19 9:36 PM, Tsunakawa, Takayuki wrote:
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
SIGTERM, which needs to be adjusted. For another, its
SIGQUIT handler does exit(1) not _exit(2), which seems rather
dubious ... should we make it more like the rest? I think
the reasoning there might've b
From: David Steele [mailto:da...@pgmasters.net]
> > Can't we use SIGKILL instead of SIGINT/SIGTERM to stop the grandchildren,
> just in case they are slow to respond to or ignore SIGINT/SIGTERM? That
> matches the idea of pg_ctl's immediate shutdown.
>
> -1, at least not immediately. Archivers c
On Tue, Sep 10, 2019 at 06:44:48AM +, Tsunakawa, Takayuki wrote:
> We don't have to call pgwin32_is_service() to determine whether we
> call SetErrorMode() in postmaster.c because:
>
> * The dialog box doesn't appear under Windows service, whether
> * PostgreSQL itself starts as a service or a
On Tue, Sep 10, 2019 at 08:03:32AM -0400, Robert Haas wrote:
> -1. I think it's very useful to have routines for this sort of thing
> that return an error message rather than emitting an error report
> directly. That gives the caller a lot more control.
Please let me counter-argue here. There ar
Hi Alvaro,
Thank you for reviewing this patch.
On Wed, Sep 11, 2019 at 4:48 AM Alvaro Herrera from 2ndQuadrant <
alvhe...@alvh.no-ip.org> wrote:
> So in this patch, the input restrictlist is modified to include the
> clauses generated by generate_join_implied_equalities_for_all. That
> doesn't
From: Michael Paquier [mailto:mich...@paquier.xyz]
> Imagine an application which relies on Postgres, still does *not* start
> it as a service but uses "pg_ctl start"
> automatically. This could be triggered as part of another service startup
> which calls say system(), or as another script. Woul
On Wed, Aug 07, 2019 at 09:03:21AM +, Evgeny Efimkin wrote:
> The new status of this patch is: Ready for Committer
I may be wrong of course, but it looks that this is wanted and the
current shape of the patch looks sensible:
- Register the query ID using a backend entry.
- Only consider the to
On Wed, Sep 11, 2019 at 04:15:24AM +, Tsunakawa, Takayuki wrote:
> From: Michael Paquier [mailto:mich...@paquier.xyz]
>> Imagine an application which relies on Postgres, still does *not* start
>> it as a service but uses "pg_ctl start"
>> automatically. This could be triggered as part of anoth
On Tue, Sep 10, 2019 at 03:38:21PM +0900, Michael Paquier wrote:
> I recall having a negative impression on the patch when first looking
> at it, and still have the same impression when looking at the last
> version. Just with a quick look, assuming that you can bypass all
> cleanup operations nor
> 21 авг. 2019 г., в 12:23, Peter Eisentraut
> написал(а):
>
> On 2019-08-21 08:56, Andrey Borodin wrote:
>> postgres=# create database a template template0 collation_provider icu
>> lc_collate 'en_US.utf8';
>> CREATE DATABASE
>> postgres=# \c a
>> 2019-08-21 11:43:40.379 +05 [41509] FATAL:
At Wed, 11 Sep 2019 11:01:24 +0900 (Tokyo Standard Time), Kyotaro Horiguchi
wrote in
<20190911.110124.96874741.horikyota@gmail.com>
> At Wed, 11 Sep 2019 01:36:15 +, "Tsunakawa, Takayuki"
> wrote in
> <0A3221C70F24FB45833433255569204D1FD33579@G01JPEXMBYT05>
> > From: Tom Lane [mailto:
On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila wrote:
>
> The current example shows the usage of looping in plpgsql, so as such
> there is no correctness issue, but OTOH there is no harm in updating
> the example as proposed by Ian Barwick. Does anyone else see any
> problem with this idea? If we ag
On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote:
> Good thought, but I think even if we want to change the name of
> tuple_data_split, it might be better done separately.
Yes, that's not the problem of this patch. Not sure if it actually
makes sense either to change it.
The regressio
Hi
create table omega(a int);
create view omega_view as select * from omega;
insert into omega values(10);
postgres=# select table_type, table_name from information_schema.tables
where table_name like 'omega%';
┌┬┐
│ table_type │ table_name │
╞╪╡
│
Michael Paquier wrote:
> Using a wrapper in src/fe_utils makes sense. I would have used
> options.c for the new file, or would that be too much generic?
Sure, options.c sounds fine -- it doesn't seem any more generic than
"arg_utils" and is a little simpler. The only other question I have is
if t
On Tue, Sep 03, 2019 at 08:06:43AM +0200, Fabien COELHO wrote:
> Attached is a rebase after TestLib.pm got a documentation in
> 6fcc40b1.
I am not completely sure what to think about this patch, but here are
some high-level comments.
+=item $node->icommand_checks(cmd, ...)
+
+=cut
+
+sub icommand
st 11. 9. 2019 v 7:45 odesílatel Amit Kapila
napsal:
> On Sun, Sep 1, 2019 at 9:09 AM Amit Kapila
> wrote:
> >
> > The current example shows the usage of looping in plpgsql, so as such
> > there is no correctness issue, but OTOH there is no harm in updating
> > the example as proposed by Ian Bar
64 matches
Mail list logo
