On 2021-01-18 18:23, Tom Lane wrote:
The reason I got interested in this right now is the nearby
discussion [1] about why findoidjoins misses some catalog
relationships and whether we should fix that and/or make its results
more readily accessible. I'd thought perhaps FK constraint entries
On 2021-01-18 00:35, Robert Haas wrote:
I don't have any complaint about labelling some of the unique indexes
as primary keys, but I think installing foreign keys that don't really
enforce anything may lead to confusion.
FWIW, "not enforced" constraints (such as foreign keys) is a feature
On Mon, Dec 21, 2020 at 1:50 PM Hou, Zhijie wrote:
>
> Hi
>
> +
> + index_oid_list = RelationGetIndexList(rel);
> ...
>
> As memtioned in the comments of RelationGetIndexList:
> * we return a copy of the list palloc'd in the caller's context. The caller
> * may list_free() the returned
On Thu, Jan 21, 2021 at 12:17 PM Fujii Masao
wrote:
> On 2021/01/21 14:46, Bharath Rupireddy wrote:
> > On Thu, Jan 21, 2021 at 10:06 AM Fujii Masao
> > wrote:
> > > >> + if (entry->server_hashvalue == hashvalue &&
> + (entry->xact_depth
On Wed, Dec 23, 2020 at 1:45 PM Amit Kapila wrote:
>
> On Wed, Dec 23, 2020 at 7:52 AM Hou, Zhijie wrote:
> >
> > Hi
> >
> > > > I may be wrong, and if I miss sth in previous mails, please give me some
> > > hints.
> > > > IMO, serial insertion with underlying parallel SELECT can be
> > > >
On 2021/01/21 14:46, Bharath Rupireddy wrote:
On Thu, Jan 21, 2021 at 10:06 AM Fujii Masao
wrote:
> >> + if (entry->server_hashvalue == hashvalue &&
+ (entry->xact_depth > 0 || result))
+ {
+
> > > Attaching v15 patch set. Please consider it for further review.
> >
> > Hi
> >
> > I have some comments for the 0001 patch
> >
> > In v15-0001-postgres_fdw-function-to-discard-cached-connecti
> >
> > 1.
> > + If there is no open connection to the given foreign server,
> false
> > +
On Thu, Jan 21, 2021 at 11:15 AM Hou, Zhijie wrote:
>
> > Attaching v15 patch set. Please consider it for further review.
>
> Hi
>
> I have some comments for the 0001 patch
>
> In v15-0001-postgres_fdw-function-to-discard-cached-connecti
>
> 1.
> + If there is no open connection to the given
On Thu, Jan 21, 2021 at 12:47 PM Hou, Zhijie wrote:
>
> >
> Hi
>
> It seems there are some previous comments[1][2] not addressed in current
> patch.
> Just to make sure it's not missed.
>
> [1]
>
On Thu, Jan 21, 2021 at 10:06 AM Fujii Masao
wrote:
> >> + if (entry->server_hashvalue == hashvalue &&
> >> + (entry->xact_depth > 0 || result))
> >> + {
> >> + hash_seq_term();
> >> +
> Attaching v15 patch set. Please consider it for further review.
Hi
I have some comments for the 0001 patch
In v15-0001-postgres_fdw-function-to-discard-cached-connecti
1.
+ If there is no open connection to the given foreign server,
false
+ is returned. If no foreign server with
On Tue, Jan 19, 2021 at 09:21:41PM +0100, Daniel Gustafsson wrote:
>> In order to
>> move on with this set, I would suggest to extract some parts of the
>> patch set independently of the others and have two buildfarm members
>> for the MSVC and non-MSVC cases to stress the parts that can be
>>
On Wed, 13 Jan 2021 at 15:38, Edmund Horner wrote:
> Thanks for updating the patch. I'd be very happy if this got picked up
> again, and I'd certainly follow along and do some review.
Likewise here. I this patch was pretty close so it seems a shame to
let it slip through the cracks.
I spoke
On Thu, Jan 21, 2021 at 1:50 PM Zhihong Yu wrote:
>
> For v12-0003-Enable-parallel-INSERT-and-or-SELECT-for-INSERT-INTO.patch:
>
> + boolisParallelModifyLeader = IsA(planstate, GatherState) &&
> IsA(outerPlanState(planstate), ModifyTableState);
>
> Please wrap long line.
>
OK.
I
On Wed Jan 20, 2021 at 2:08 PM EST, Dmitry Dolgov wrote:
> > On Wed, Jan 20, 2021 at 11:34:16AM -0500, Dian M Fay wrote:
> > > Thanks, I need to remember to not skipp doc building for testing process
> > > even for such small changes. Hope now I didn't forget anything.
> > >
> > > > On Wed, Jan
On 2021/01/21 12:00, Bharath Rupireddy wrote:
On Wed, Jan 20, 2021 at 6:58 PM Fujii Masao wrote:
+ * It checks if the cache has a connection for the given foreign server that's
+ * not being used within current transaction, then returns true. If the
+ * connection is in use, then it emits a
On Thu, Jan 21, 2021 at 1:28 PM Zhihong Yu wrote:
>
> Hi,
> For v12-0001-Enable-parallel-SELECT-for-INSERT-INTO-.-SELECT.patch :
>
> is found from the additional parallel-safety checks, or from the existing
> parallel-safety checks for SELECT that it currently performs.
>
> existing and 'it
On Thu, Jan 21, 2021 at 12:11:37AM +0200, Heikki Linnakangas wrote:
> Summary: In the the worst scenario, the patched version is still 24% slower
> than unpatched. But many other scenarios are now faster with the patch.
Is there a reason explaining the sudden drop for numsnaps within the
[10,60]
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
> On 03.01.2021 14:29, Noah Misch wrote:
> >On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> Thank you for the review.
> New version of the patch is attached, though I haven't tested it properly
> yet.
On 2021/01/18 12:00, torikoshia wrote:
On 2021-01-15 15:23, torikoshia wrote:
Thanks for your reviewing and comments!
On 2021-01-14 12:39, Ian Lawrence Barwick wrote:
Looking at the code, this happens as the wait start time is being recorded in
the lock record itself, so always contains
On Wed, Dec 16, 2020 at 8:27 AM Michael Paquier wrote:
>
> On Tue, Dec 15, 2020 at 06:34:16PM +0100, Magnus Hagander wrote:
> > Is this really a common enough operation that we need it in the main
> > grammar?
> >
> > Having the functionality, definitely, but what if it was "just" a
> > function
On Wed, Jan 20, 2021 at 6:58 PM Fujii Masao wrote:
> + * It checks if the cache has a connection for the given foreign server
> that's
> + * not being used within current transaction, then returns true. If the
> + * connection is in use, then it emits a warning and returns false.
>
> The comment
Hi,
For v12-0003-Enable-parallel-INSERT-and-or-SELECT-for-INSERT-INTO.patch:
+ boolisParallelModifyLeader = IsA(planstate, GatherState) &&
IsA(outerPlanState(planstate), ModifyTableState);
Please wrap long line.
+ uint64 *processed_count_space;
If I read the code correctly,
On Sun, Nov 22, 2020 at 9:19 PM James Hilliard
wrote:
> In order to avoid hitting these limits we can bypass the wrapper layer
> and just use mach directly.
FWIW I looked into using mach_vm_alllocate() years ago because I
wanted to be able to use its VM_FLAGS_SUPERPAGE_SIZE_2MB flag to
implement
On 1/21/21 3:09 AM, tsunakawa.ta...@fujitsu.com wrote:
From: Tomas Vondra
Right, that's pretty much what I ended up doing (without the CMD_INSERT
check it'd add batching info to explain for updates too, for example).
I'll do a bit more testing on the attached patch, but I think that's the
Hi,
For v12-0001-Enable-parallel-SELECT-for-INSERT-INTO-.-SELECT.patch :
is found from the additional parallel-safety checks, or from the existing
parallel-safety checks for SELECT that it currently performs.
existing and 'it currently performs' are redundant. You can omit 'that it
currently
On Thu, 21 Jan 2021 at 09:56, Tom Lane wrote:
> Craig Ringer writes:
> > On Wed, 20 Jan 2021 at 05:23, Tom Lane wrote:
> >> BTW, it also looks like the patch is doing nothing to prevent the
> >> backtrace from being sent to the connected client.
>
> > I don't see a good reason to send a bt to
From: Tom Lane
> The "single target table" could be partitioned, in which case there'll be
> multiple resultrelinfos, some of which could be foreign tables.
Thank you. I thought so at first, but later I found that ExecInsert() only
handles one element in mtstate->resultRelInfo. So I thought
Dear Heikki,
I tested in the same situation, and I confirmed that almost same results are
returned.
(results are at the end of the e-mail)
You think that these results are acceptable
because resowners own many resources(more than 64) in general
and it's mainly faster in such a situation, isn't
On Wed, 20 Jan 2021 at 02:45, Stephen Frost wrote:
> Greetings,
>
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Craig Ringer (craig.rin...@enterprisedb.com) wrote:
> > > On Thu, 14 Jan 2021 at 03:44, Stephen Frost
> wrote:
> > > > Alright, how does this look? The new entries are all
On Thu, Jan 7, 2021 at 2:16 AM Tomas Vondra
wrote:
>
> Hi,
>
> I think I've managed to get the 0002 patch [1] rebased to master and
> working (with help from Masahiko Sawada). It's not clear to me how it
> could have worked as submitted - my theory is that an incomplete patch
> was submitted by
From: Tomas Vondra
> Right, that's pretty much what I ended up doing (without the CMD_INSERT
> check it'd add batching info to explain for updates too, for example).
> I'll do a bit more testing on the attached patch, but I think that's the
> right fix to
> push.
Thanks to the outer check for
"tsunakawa.ta...@fujitsu.com" writes:
> Just for learning, could anyone tell me what this loop for? I thought
> current Postgres's DML supports a single target table, so it's enough to
> handle the first element of mtstate->resultRelInfo.
The "single target table" could be partitioned, in
On 1/21/21 2:53 AM, Amit Langote wrote:
On Thu, Jan 21, 2021 at 10:42 AM Tomas Vondra
wrote:
On 1/21/21 2:24 AM, Amit Langote wrote:
On Thu, Jan 21, 2021 at 9:56 AM Tomas Vondra
wrote:
On 1/21/21 1:17 AM, Zhihong Yu wrote:
Hi,
The assignment to resultRelInfo is done when
From: Zhihong Yu
> My first name is Zhihong.
> You can call me Ted if you want to save some typing :-)
Ah, I'm very sorry. Thank you, let me call you Ted then. That can't be
mistaken.
Regards
Takayuki Tsunakawa
Craig Ringer writes:
> On Wed, 20 Jan 2021 at 05:23, Tom Lane wrote:
>> BTW, it also looks like the patch is doing nothing to prevent the
>> backtrace from being sent to the connected client.
> I don't see a good reason to send a bt to a client. Even though these
> backtraces won't be analysing
On Thu, Jan 21, 2021 at 10:42 AM Tomas Vondra
wrote:
> On 1/21/21 2:24 AM, Amit Langote wrote:
> > On Thu, Jan 21, 2021 at 9:56 AM Tomas Vondra
> > wrote:
> >> On 1/21/21 1:17 AM, Zhihong Yu wrote:
> >>> Hi,
> >>> The assignment to resultRelInfo is done when junk_filter_needed is true:
> >>>
>
From: Tomas Vondra
> Right. But I think Tom is right this should initialize ri_BatchSize for all
> the
> resultRelInfo elements, not just the first one. Per the attached patch, which
> resolves the issue both on x86_64 and armv7l for me.
I think Your patch is perfect in the sense that it's
Hi, Takayuki-san:
My first name is Zhihong.
You can call me Ted if you want to save some typing :-)
Cheers
On Wed, Jan 20, 2021 at 5:37 PM tsunakawa.ta...@fujitsu.com <
tsunakawa.ta...@fujitsu.com> wrote:
> From: Zhihong Yu
>
> > Do we need to consider how this part of code inside
>
>
> Thanks for the feedback.
> Posting an updated set of patches. Changes are based on feedback, as detailed
> below:
Hi
It seems there are some previous comments[1][2] not addressed in current patch.
Just to make sure it's not missed.
[1]
On 1/21/21 2:22 AM, Tom Lane wrote:
Tomas Vondra writes:
I may be wrong, but the most likely explanation seems to be this is due
to the junk filter initialization, which simply moves past the end of
the mtstate->resultRelInfo array.
resultRelInfo is certainly pointing at garbage at that
On Wed, 20 Jan 2021 at 05:23, Tom Lane wrote:
>
> Recursion is scary, but it should (I think) not be possible if this
> is driven off CHECK_FOR_INTERRUPTS. There will certainly be none
> of those in libbacktrace.
>
We can also hold interrupts for the call, and it might be wise to do so.
One
On 1/21/21 2:24 AM, Amit Langote wrote:
On Thu, Jan 21, 2021 at 9:56 AM Tomas Vondra
wrote:
On 1/21/21 1:17 AM, Zhihong Yu wrote:
Hi,
The assignment to resultRelInfo is done when junk_filter_needed is true:
if (junk_filter_needed)
{
resultRelInfo =
On Wed, Jan 20, 2021 at 03:34:39PM -0300, Alvaro Herrera wrote:
> On 2021-Jan-20, Alexey Kondratov wrote:
>> Ugh, forgot to attach the patches. Here they are.
>
> Yeah, looks reasonable.
Patch 0002 still has a whole set of issues as I pointed out a couple
of hours ago, but if we agree on 0001 as
From: Zhihong Yu
> Do we need to consider how this part of code inside ExecInitModifyTable()
> would evolve ?
> I think placing the compound condition toward the end of
> ExecInitModifyTable() is reasonable because it checks the latest information.
+1 for Zaihong-san's idea. But instead of
On Wed, 20 Jan 2021 at 01:31, Robert Haas wrote:
> On Sat, Jan 16, 2021 at 3:21 PM Tom Lane wrote:
> > I'd argue that backtraces for those processes aren't really essential,
> > and indeed that trying to make the syslogger report its own backtrace
> > is damn dangerous.
>
> I agree. Ideally I'd
Robert Haas writes:
>>> Maybe it would be better if it said:
>>> connection to database at socket "/tmp/.s.PGSQL.5432" failed: FATAL:
>>> database "rhaas" does not exist
>> I'd be inclined to spell it "connection to server at ... failed",
>> but that sort of wording is surely also possible.
>
On Thu, Jan 21, 2021 at 9:56 AM Tomas Vondra
wrote:
> On 1/21/21 1:17 AM, Zhihong Yu wrote:
> > Hi,
> > The assignment to resultRelInfo is done when junk_filter_needed is true:
> >
> > if (junk_filter_needed)
> > {
> > resultRelInfo = mtstate->resultRelInfo;
> >
> >
Tomas Vondra writes:
> I may be wrong, but the most likely explanation seems to be this is due
> to the junk filter initialization, which simply moves past the end of
> the mtstate->resultRelInfo array.
resultRelInfo is certainly pointing at garbage at that point.
> It kinda seems the
Hi,
Do we need to consider how this part of code inside ExecInitModifyTable()
would evolve ?
I think placing the compound condition toward the end
of ExecInitModifyTable() is reasonable because it checks the latest
information.
Regards
On Wed, Jan 20, 2021 at 5:11 PM Tomas Vondra
wrote:
>
>
>
On 1/21/21 2:02 AM, Zhihong Yu wrote:
Hi, Tomas:
In my opinion, my patch is a little better.
Suppose one of the conditions in the if block changes in between the
start of loop and the end of the loop:
* Determine if the FDW supports batch insert and determine the batch
* size
Hi, Tomas:
In my opinion, my patch is a little better.
Suppose one of the conditions in the if block changes in between the start
of loop and the end of the loop:
* Determine if the FDW supports batch insert and determine the batch
* size (a FDW may support batching, but it may be
On 1/21/21 1:17 AM, Zhihong Yu wrote:
Hi,
The assignment to resultRelInfo is done when junk_filter_needed is true:
if (junk_filter_needed)
{
resultRelInfo = mtstate->resultRelInfo;
Should the code for determining batch size access mtstate->resultRelInfo
On 1/21/21 12:59 AM, Tom Lane wrote:
Tomas Vondra writes:
OK, pushed after a little bit of additional polishing (mostly comments).
Thanks everyone!
florican reports this is seriously broken on 32-bit hardware:
At Wed, 20 Jan 2021 16:40:59 +0900, Michael Paquier wrote
in
> On Wed, Jan 20, 2021 at 07:25:37AM +0100, Peter Eisentraut wrote:
> > It looks like we are not getting any consensus on this approach. One
> > reduced version I would consider is just the second part, so you'd write
> > something
On 1/21/21 12:52 AM, Tomas Vondra wrote:
Hmm, seems that florican doesn't like this :-(
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican=2021-01-20%2023%3A08%3A15
It's a i386 machine running FreeBSD, so not sure what exactly it's picky
about. But when I tried running this
Hackers,
It looks like both heapgettup() and heapgettup_pagemode() are coded
incorrectly when setting the page to start the scan on for a backwards
scan when heap_setscanlimits() has been used.
It looks like the code was not updated during 7516f5259.
The current code is:
/* start from last
Hi,
The assignment to resultRelInfo is done when junk_filter_needed is true:
if (junk_filter_needed)
{
resultRelInfo = mtstate->resultRelInfo;
Should the code for determining batch size access mtstate->resultRelInfo
directly ?
diff --git
Tomas Vondra writes:
> OK, pushed after a little bit of additional polishing (mostly comments).
> Thanks everyone!
florican reports this is seriously broken on 32-bit hardware:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican=2021-01-20%2023%3A08%3A15
First guess is incorrect
Hi Tomas and hackers,
On 2021/01/21 7:00, Tomas Vondra wrote:
I created patches and my test results on PG10, 11, 12, and 14 are fine.
0001:
- Fix query to use pg_statistic_ext only
- Replace statuses "required" and "built" with "defined"
- Remove the size columns
- Fix
Hmm, seems that florican doesn't like this :-(
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=florican=2021-01-20%2023%3A08%3A15
It's a i386 machine running FreeBSD, so not sure what exactly it's picky
about. But when I tried running this under valgrind, I get some strange
failures
On Wed, Jan 20, 2021 at 4:07 PM Tom Lane wrote:
>
> James Hilliard writes:
> > On Tue, Jan 19, 2021 at 6:37 PM Tom Lane wrote:
> >> I've found no direct means to control the
> >> SDK path at all, but so far it appears that "xcrun --show-sdk-path"
> >> agrees with the compiler's default
On Wed, 2021-01-20 at 19:07 +, Jacob Champion wrote:
> I think you'll want to be careful to specify the format as much as
> possible, both to make sure that other backend TLS implementations can
> actually use the same escaping system and to ensure that user regexes
> don't suddenly start
James Hilliard writes:
> On Tue, Jan 19, 2021 at 6:37 PM Tom Lane wrote:
>> I've found no direct means to control the
>> SDK path at all, but so far it appears that "xcrun --show-sdk-path"
>> agrees with the compiler's default -isysroot path as seen in the
>> compiler's -v output. I suspect
OK, pushed after a little bit of additional polishing (mostly comments).
Thanks everyone!
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 19/01/2021 11:09, Heikki Linnakangas wrote:
On 18/01/2021 18:11, Robert Haas wrote:
On Mon, Jan 18, 2021 at 11:11 AM Robert Haas wrote:
On Mon, Jan 18, 2021 at 10:19 AM Heikki Linnakangas wrote:
On 18/01/2021 16:34, Alvaro Herrera wrote:
So according to your performance benchmark, we're
On 03.01.2021 14:29, Noah Misch wrote:
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
On 08.06.2020 19:31, Alvaro Herrera wrote:
I'm thinking what's a good way to have a test that's committable. Maybe
it would work to add a TAP test to pg_upgrade that runs initdb, does
On 1/20/21 7:41 AM, Tatsuro Yamada wrote:
Hi Tomas,
On 2021/01/20 11:35, Tatsuro Yamada wrote:
Apologies for all the extra work - I haven't realized this flaw when
pushing for showing more stuff :-(
Don't worry about it. We didn't notice the problem even when viewed by
multiple
people
On Tue, Jan 19, 2021 at 6:37 PM Tom Lane wrote:
>
> James Hilliard writes:
> > Actually, this looks path looks wrong in general, the value for
> > "xcrun --sdk macosx --show-sdk-path" should take precedence over
> > "xcrun --show-sdk-path" as the latter may be used for IOS potentially.
>
> What
On Wed, Jan 20, 2021 at 10:53 AM Peter Geoghegan wrote:
> This patch is unusual in that you really need to think about emergent
> behaviors to understand it. That is certainly a difficult thing to do,
> and it's understandable that even an expert might not grok it without
> considering it
st 20. 1. 2021 v 21:32 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > st 20. 1. 2021 v 21:07 odesílatel Tom Lane napsal:
> >> Uh, what? I don't understand what this "partition context" is.
>
> > It was my name for an access to window partition local memory -
> >
Pavel Stehule writes:
> st 20. 1. 2021 v 21:07 odesílatel Tom Lane napsal:
>> Uh, what? I don't understand what this "partition context" is.
> It was my name for an access to window partition local memory -
> WinGetPartitionLocalMemory
Ah.
> We need some interface for this cache
I'm not
st 20. 1. 2021 v 21:07 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > The second question is work with partition context value. This should be
> > only one value, and of only one but of any type per function. In this
> case
> > we cannot use GET statements. I had an idea of enhancing
Pavel Stehule writes:
> The second question is work with partition context value. This should be
> only one value, and of only one but of any type per function. In this case
> we cannot use GET statements. I had an idea of enhancing declaration. Some
> like
> DECLARE
> pcx PARTITION CONTEXT
On Wed, Jan 20, 2021 at 1:54 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2021-Jan-20, Robert Haas wrote:
> >> I figured it was something like that. I don't know whether the right
> >> thing is to use something like PQdb() to get the correct database
> >> name, or whether we should go with
I wrote:
> ...
> 2. pull_varnos() is not passed the planner "root" data structure,
> so it can't get at the PlaceHolderInfo list. We can change its
> API of course, but that propagates to dozens of places.
> ...
> The 0001 patch attached goes ahead and makes those API changes.
> I think this is
> On Wed, Jan 20, 2021 at 11:34:16AM -0500, Dian M Fay wrote:
> > Thanks, I need to remember to not skipp doc building for testing process
> > even for such small changes. Hope now I didn't forget anything.
> >
> > > On Wed, Jan 20, 2021 at 09:58:43AM -0500, Dian M Fay wrote:
> >
> > > Here's a
On Mon, 2021-01-18 at 11:23 +0100, Daniel Gustafsson wrote:
> + /* use commas instead of slashes */
> + X509_NAME_print_ex(bio, x509name, 0, XN_FLAG_SEP_COMMA_PLUS);
> I don't have strong opinions on whether we shold use slashes or commas, but I
> think it needs to be
Some catalog tables have references to pg_attribute.attnum.
In the documentation, it only says "(references pg_attribute.attnum)"
but not which oid column to include in the two-column "foreign key".
This would not be a problem if there would only be one reference to
pg_class.oid,
but some
Alvaro Herrera writes:
> On 2021-Jan-20, Robert Haas wrote:
>> I figured it was something like that. I don't know whether the right
>> thing is to use something like PQdb() to get the correct database
>> name, or whether we should go with Tom's suggestion and omit that
>> detail altogether, but I
On Wed, Jan 20, 2021 at 5:33 AM Amit Kapila wrote:
> > Victor independently came up with a benchmark that ran over several
> > hours, with cleanup consistently held back by ~5 minutes by a long
> > running transaction:
> >
>
> AFAICS, the long-running transaction used in the test is below:
>
On 2021-Jan-20, Robert Haas wrote:
> On Wed, Jan 20, 2021 at 1:25 PM Alvaro Herrera
> wrote:
> > That's because pgbench reports the input argument dbname, but since you
> > didn't specify anything, then PQconnectdbParams() uses the libpq
> > behavior. I think we'd have to use PQdb() instead.
>
On 2021-Jan-20, Alexey Kondratov wrote:
> On 2021-01-20 21:08, Alexey Kondratov wrote:
> >
> > I did a refactoring of ATExecSetTableSpaceNoStorage() in the 0001. New
> > function SetRelTablesapce() is placed into the tablecmds.c. Following
> > 0002 gets use of it. Is it close to what you and
On Wed, Jan 20, 2021 at 1:25 PM Alvaro Herrera wrote:
> That's because pgbench reports the input argument dbname, but since you
> didn't specify anything, then PQconnectdbParams() uses the libpq
> behavior. I think we'd have to use PQdb() instead.
I figured it was something like that. I don't
On 2021-Jan-20, Robert Haas wrote:
> On Wed, Jan 20, 2021 at 12:19 PM Tom Lane wrote:
> > Robert Haas writes:
> > > I just made the mistake of trying to run pgbench without first running
> > > createdb and got this:
> >
> > > pgbench: error: connection to database "" failed: could not connect
On 2021-Jan-20, Alexander Korotkov wrote:
> My proposal is to make everything after the ** operator use strict mode
> (patch attached). I think this shouldn't be backpatched, just applied to
> the v14. Other suggestions?
I think changing the mode midway through the operation is strange. What
On 2021-01-20 21:08, Alexey Kondratov wrote:
On 2021-01-20 18:54, Alvaro Herrera wrote:
On 2021-Jan-20, Alvaro Herrera wrote:
On 2021-Jan-20, Michael Paquier wrote:
> +/*
> + * This is mostly duplicating ATExecSetTableSpaceNoStorage,
> + * which should maybe be factored out to a library
On 2021-01-20 18:54, Alvaro Herrera wrote:
On 2021-Jan-20, Alvaro Herrera wrote:
On 2021-Jan-20, Michael Paquier wrote:
> +/*
> + * This is mostly duplicating ATExecSetTableSpaceNoStorage,
> + * which should maybe be factored out to a library function.
> + */
> Wouldn't it be better to do
On Wed, Jan 20, 2021 at 12:47 PM Tom Lane wrote:
> Fair. One possibility, which'd take a few more cycles in libpq but
> likely not anything significant, is to replace "could not connect to ..."
> with "while connecting to ..." once we're past the connect() per se.
Yeah. I think this is kind of
Robert Haas writes:
> On Wed, Jan 20, 2021 at 12:19 PM Tom Lane wrote:
>> But the 'could not connect to socket' part is a consequence of my
>> recent fiddling with libpq's connection failure reporting, see
>> 52a10224e. We could discuss exactly how that ought to be spelled,
>> but the idea is
> Where do you need this information?
I'm writing some code that takes a given query, and generates type-safe
bindings for it, so people can write SQL queries and get structs (or vectors of
structs) out the other end. So I'm pretty flexible about where I get it, given
that it'll be part of my
On Wed, Jan 20, 2021 at 12:19 PM Tom Lane wrote:
> Robert Haas writes:
> > I just made the mistake of trying to run pgbench without first running
> > createdb and got this:
>
> > pgbench: error: connection to database "" failed: could not connect to
> > socket "/tmp/.s.PGSQL.5432": FATAL:
On Thu, Jan 7, 2021 at 6:36 AM Alexander Korotkov wrote:
>
> > I read your patch over quickly and it seems like a reasonable
> > approach (but sadly underdocumented). Can we extend the idea
> > to fix the to_tsquery case?
>
> Sure, I'll provide a revised patch.
The next version of the patch is
Robert Haas writes:
> I just made the mistake of trying to run pgbench without first running
> createdb and got this:
> pgbench: error: connection to database "" failed: could not connect to
> socket "/tmp/.s.PGSQL.5432": FATAL: database "rhaas" does not exist
> This looks pretty bogus because
Hi!
We have a bug report which says that jsonpath ** operator behaves strangely
in the lax mode [1].
Naturally, the result of this query looks counter-intuitive.
# select jsonb_path_query_array('[{"a": 1, "b": [{"a": 2}]}]', 'lax
$.**.a');
jsonb_path_query_array
[1,
I just made the mistake of trying to run pgbench without first running
createdb and got this:
pgbench: error: connection to database "" failed: could not connect to
socket "/tmp/.s.PGSQL.5432": FATAL: database "rhaas" does not exist
This looks pretty bogus because (1) I was not attempting to
Michael Paquier writes:
> On Tue, Jan 19, 2021 at 05:03:49PM -0500, Tom Lane wrote:
>> In short I propose the attached patch, which also gets rid of
>> that duplicate query.
> Agreed, +1.
Pushed, thanks for looking at it.
regards, tom lane
"Wesley Aptekar-Cassels" writes:
> I am interested in figuring out how to get the names and types of the
> columns from an arbitrary query.
Where do you need this information? Usually the easiest way is to
prepare (plan) the query and then extract metadata, for instance
PQprepare and
On Wed Jan 20, 2021 at 11:22 AM EST, Dmitry Dolgov wrote:
> > On Tue Jan 19, 2021 at 1:42 PM EST, Pavel Stehule wrote:
> >
> > I found minor issues.
> >
> > Doc - missing tag
> >
> > and three whitespaces issues
> >
> > see attached patch
>
> Thanks, I need to remember to not skipp doc building
Hi all,
I am interested in figuring out how to get the names and types of the columns
from an arbitrary query. Essentially, I want to be able to take a query like:
CREATE TABLE foo(
bar bigserial,
baz varchar(256)
);
SELECT * FROM foo WHERE bar = 42;
and figure out programmatically
1 - 100 of 135 matches
Mail list logo
