Alvaro Herrera writes:
> On 2022-Feb-07, Tom Lane wrote:
>> I see that PQgetResult does a hacky "resetPQExpBuffer(&conn->errorMessage)"
>> in between pipelined queries. It seems like if there are real usability
>> issues in this area, they probably come
ried to bring it up to date and add my changes.
We haven't actually maintained ecpg's copies of backend datatype-specific
code in many years. While bringing that stuff up to speed might be
worthwhile (or perhaps not, given the lack of complaints), I'd see it
as a separate project.
regards, tom lane
t, maybe if there's a failure we
could print "while running text-of-command-here" after the fact.
It'd also be a good idea to start using "make -s" by default for the
preparatory steps.
regards, tom lane
e in principle, it seems like it'll just be
useless verbosity in pretty much any actual database. In what scenario
would you have duplicate collation names?
regards, tom lane
Andres Freund writes:
> On 2022-02-21 12:05:42 -0500, Tom Lane wrote:
>> except maybe the "running on port 51696 with PID 1156405" line (and I'm not
>> too wedded to that)?
> We still have a few issues with ports conflicts on windows. We should really
> co
hat this is probably a good change to make.
Hearing no objections, done.
regards, tom lane
ter a configure or make failure, but I think the
REL_11 you're running here doesn't have that defense. It'll only
flush accache after a change in the configure script in git.
regards, tom lane
Kyotaro Horiguchi writes:
> Anyway, don't we use the -ftabstop option flag to silence compiler?
> The warning is contradicting our convention. The attached adds that
> flag.
No, we use pgindent to not have such inconsistent indentation.
regards, tom lane
eems like most of your animals haven't run at all
in the last couple of days. Did you maybe forget to re-enable
their cron jobs after messing with them, or something like that?
regards, tom lane
ing, I fear.
Looks like libpq_pipeline.c has its own pg_fatal, too.
I'm not against choosing some name other than pg_log_fatal, but that
particular suggestion has got conflicts. Got any other ideas?
regards, tom lane
than-idiomatic rather than outright broken.
Updating the patch is going to be a bit tedious, so I'm not
going to do it without buy-in that this solution would be
okay to commit. Any objections?
regards, tom lane
nches, but our hands will be forced once
Python 3.11 is out. Maybe put it in HEAD now, and plan to back-patch
in a few months?
regards, tom lane
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index c93f90de9b..7971050746 100644
--- a/src/backend/executor/spi.c
+++ b/src/backend/
ry small) inner loop for that
case into div_var_fast.
regards, tom lane
Andrew Dunstan writes:
> On 2/23/22 15:30, Andres Freund wrote:
>> Perhaps we should just rename src/test/modules/libpq_pipeline to
>> src/test/modules/libpq and move uri-regress in there as well?
> WFM
+1
regards, tom lane
ch that proves.
In any case, src/test/modules doesn't have to do it.
regards, tom lane
oversight to me.
regards, tom lane
Dean Rasheed writes:
> On Wed, 23 Feb 2022 at 20:55, Tom Lane wrote:
>> I'm +1 on 0001 and 0002, but 0003 feels
>> a bit ad-hoc. It certainly *looks* weird for the allegedly faster
>> function to be handing off to the allegedly slower one. I also wonder
>>
l TAP test; you need some C code to drive the
library. I don't agree with intermixing such code with libpq
itself, independently of any buildsystem issues (which there
might well be). So I think the design of putting such tests under
src/modules is fine.
regards, tom lane
the pipeline mode some more, I no longer think that's
a great idea. ISTM we want pipeline mode to act as nearly as possible
the same as issuing the same series of queries non-pipelined. But
this redefinition would make it different. So, barring objection,
I'll push that cleanup patch as-posted.
regards, tom lane
Peter Eisentraut writes:
> On 23.02.22 23:58, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> libpq TAP tests should be in src/interfaces/libpq/t/.
>> That's failing to account for the fact that a libpq test can't
>> really be a pure-perl TAP test; you
ot; and "hint"
addendums. What we have right now in the frontend code is an impossible
mishmash of three or four ways of filling that lack, all inconsistent.
regards, tom lane
d stick to. Peter's proposal
of a separate test/ subdirectory for C test scaffolding is
probably fine.
regards, tom lane
ior. Looking through the discussions [2], I don't
> see any mention of it, which makes me think
> it was a mistake.
Indeed ... Peter?
regards, tom lane
error that's yet to be
reported to the application. So I think we need something
more like the attached.
regards, tom lane
diff --git a/src/interfaces/libpq/fe-exec.c b/src/interfaces/libpq/fe-exec.c
index 45dddaf556..0c39bc9abf 100644
--- a/src/interfaces/libpq/fe-ex
st cases.
regards, tom lane
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index c93f90de9b..7971050746 100644
--- a/src/backend/executor/spi.c
+++ b/src/backend/executor/spi.c
@@ -156,7 +156,8 @@ SPI_connect_ext(int options)
* XXX It could be bette
't get any warnings from
the similar code in spi.c, probably because those functions can't
be inlined there.
regards, tom lane
diff --git a/doc/src/sgml/spi.sgml b/doc/src/sgml/spi.sgml
index d710e2d0df..7581661fc4 100644
--- a/doc/src/sgml/spi.sgml
Plus, it sounds like we'd have to advise people to reindex *anyway*,
just in a slightly different set of cases.
regards, tom lane
Tomas Vondra writes:
> I wonder if we could check the index tuple length, and adjust the siglen
> based on that, somehow ...
In an already-corrupted index, there won't be a unique answer.
regards, tom lane
L connection.
... and, since we can't readily enforce that the client only sends
those cleartext passwords over suitably-encrypted connections, this
could easily be a net negative for security. Not sure that I think
it's a good idea.
regards, tom lane
Jeff Davis writes:
> On Thu, 2022-02-24 at 20:47 -0500, Tom Lane wrote:
>> ... and, since we can't readily enforce that the client only sends
>> those cleartext passwords over suitably-encrypted connections, this
>> could easily be a net negative for security. Not s
der if it could help on other compiler versions.
I'll mark this RFC.
regards, tom lane
Jeff Davis writes:
> On Fri, 2022-02-25 at 12:39 -0500, Tom Lane wrote:
>> My point is that sending cleartext passwords over the wire is an
>> insecure-by-definition protocol that we shouldn't be encouraging
>> more use of.
> We can require custom auth entries i
t's hanging up.
> We could be more certain if we shut down the cluster in fast rather than
> immediate mode. So I'm thinking of doing something like
Does that risk an indefinite hangup of the buildfarm run?
regards, tom lane
component. I'm not wedded to the way I did it in this
patch, but I think we ought to maintain a notational distinction
between those two sorts of concepts.
regards, tom lane
, I asked you to
do something" rather than needing to carry the full semantics of
what is to be done.
regards, tom lane
nd worker. I've not
tried attaching in something other than PID order, but I probably
will next time.
Thoughts? Ideas on debugging this?
regards, tom lane
king it harder to see what's
connected to what; and what's it buying exactly? I'd rather keep all the
ModifyTable code in one .c file, even if that one is bigger than our
usual practice.
regards, tom lane
ISTS, and I think using that followed
by CREATE is a much better-defined approach.
regards, tom lane
Andres Freund writes:
> On 2022-02-26 14:07:05 -0500, Tom Lane wrote:
>> I have observed this three times in the REL_11 branch, once
>> in REL_12, and a couple of times last summer before it occurred
>> to me to start keeping notes. Over that time the machine has
&g
output would presumably be on a different line and
thus distinguishable from the SSL property; plus, it'd be impossible
for both forms to show up in the same connection.
However, how about writing "SSL compression: on" versus writing
nothing? That avoids doubt about what it means. I don't buy
Michael's argument that this is ambiguous, either.
regards, tom lane
stencies in integer widths?
regards, tom lane
g to run automatic tests in an environment
where they'd be allowed to sudo. (Or at least I sure hope nobody
working on this project is that naive.)
If somebody wants to put this in despite that, I'd merely suggest
that the server-side logic ought to get exercised too.
regards, tom lane
Joseph Koshakow writes:
> [ v4-0001-Check-for-overflow-in-justify_interval-functions.patch ]
Pushed. I added a comment explaining why the one addition in
interval_justify_interval doesn't require an overflow check.
regards, tom lane
braries can manage.
regards, tom lane
ment for marking other functions leakproof.
ISTM the proposed text does a reasonable job of explaining why
we made the decisions currently embedded in pg_proc.proleakproof.
If we make some other decisions in future, updating the rationale
in the docs would be an appropriate part of that.
regards, tom lane
tion to set it, either. There's already -v and friends.
> * Is formfeed output after the result, not before?
Or we could invent WATCH_BEFORE and WATCH_AFTER ...
regards, tom lane
In the current state of affairs, what's considered the ur-source of that
> information?
The source code for the type's send/receive functions :-(. One could
wish for something better, but no one has stepped up to produce such
documentation.
regards, tom lane
stified for other sorts of objects.)
regards, tom lane
oposed value is "too large". Not sure exactly where the
threshold for that ought to be, but maybe BLCKSZ/8 could be a
starting offer.
regards, tom lane
Andrew Dunstan writes:
> On 2/28/22 18:21, Tom Lane wrote:
>> regression=# create table foo(f1 int);
>> CREATE TABLE
>> regression=# alter table foo add column bar text default repeat('xyzzy',
>> 100);
>> ERROR: row is too big: size 57416, ma
but I'm
only -0.1 or so; anybody else want to vote?
regards, tom lane
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'd be more eager to do that if we had some field complaints
>> about it. Since we don't, my inclination is not to, but I'm
>> only -0.1 or so; anybody else want to vote?
> This patch wa
ture?
> It looks like the Skip Scan patch was related to this work in some
> way? Is it blocked on it?
I did promise some time ago to get involved in the skip scan work.
I've so far failed to make good on that promise, but I will make
it a high priority to look at the area during this CF.
regards, tom lane
James Coleman writes:
> On Tue, Jan 4, 2022 at 9:59 PM James Coleman wrote:
>> On Tue, Jan 4, 2022 at 5:31 PM Tom Lane wrote:
>>> I don't really see why this patch is even a little bit safe.
> Suppose lateral is not in play. Then if we have a plan like:
>
n this series.
I've not looked at the subsequent ones.
regards, tom lane
d say that it's equally unproven
that deriving "a > c" from "a = b AND b > c" is worth the cycles.
I'll grant that it's most likely going to be a win if we can use
any of these patterns to generate a restriction clause from what
had been join clauses. Beyond that it's much less clear.
regards, tom lane
e not read the whole patch, but this snippet seems fine to me
if there's also an #undef at the end of the function.
regards, tom lane
Chris Bandy writes:
> On 3/1/22 3:15 AM, Tom Lane wrote:
>> Anyway, I'd be happier about back-patching if we could document
>> actual requests to make it work like the server side does.
> PGO runs PostgreSQL 10 through 14 in Kubernetes, and we have to work
> ar
methods that transmit a cleartext password.
regards, tom lane
t the first point.
regards, tom lane
RWF would be the
thing to do; but that's not special to the last-CF situation.
regards, tom lane
want to review or commit such large chunks.
regards, tom lane
Zhihong Yu writes:
> In test output, I saw:
> src/backend/utils/adt/tid.c:112:16: runtime error: left shift of 65535 by
> 16 places cannot be represented in type 'int'
What compiler is that?
regards, tom lane
Zhihong Yu writes:
> On Thu, Mar 3, 2022 at 7:44 AM Tom Lane wrote:
>> Zhihong Yu writes:
>>> In test output, I saw:
>>> src/backend/utils/adt/tid.c:112:16: runtime error: left shift of 65535 by
>>> 16 places cannot be represented in type 'int'
Zhihong Yu writes:
> On Thu, Mar 3, 2022 at 8:24 AM Tom Lane wrote:
>> Oh, I misread this as a compile-time warning, but it must be from ASAN.
>> Was the test case one of your own, or just our normal regression tests?
> The Jenkins test is ported from contrib/postgres_fdw/sq
Andres Freund writes:
> On 2022-03-03 12:13:40 -0500, Tom Lane wrote:
>> Hmph. I tried enabling -fsanitize=undefined here, and I get some
>> complaints about passing null pointers to memcmp and the like, but
>> nothing about this shift (tested with clang 12.0.1 on RHEL
a live bug.
I'm not sure whether to back-patch --- looking through the
git logs, it seems we've back-patched some fixes like these
and not others. Thoughts?
In any case, if we're going to take this seriously it seems
like we need a buildfarm machine or two testing this option.
Andres Freund writes:
> On 2022-03-03 14:00:14 -0500, Tom Lane wrote:
>> I'm not sure whether to back-patch --- looking through the
>> git logs, it seems we've back-patched some fixes like these
>> and not others. Thoughts?
> It'd be easier to run a BF
Robert Haas writes:
> On Wed, Mar 2, 2022 at 9:35 AM Tom Lane wrote:
>> I've not read the whole patch, but this snippet seems fine to me
>> if there's also an #undef at the end of the function.
>> From later emails, it sounds like that's not the common prac
checks are somewhere
between sloppy and nonexistent:
# select '(400,1)'::tid;
tid
(1345294336,1)
(1 row)
I think I'll fix that while I'm looking at it ... but it still
doesn't explain why no complaint in tidout.
regards, tom lane
Chapman Flack writes:
> On 03/03/22 16:40, Tom Lane wrote:
>> The point is to make it clear that the macro isn't intended to affect
>> code outside the function. Since C lacks block-scoped macros,
>> there's no other way to do that.
> Would the
> Datum
where the
stats collector is intentionally not 100% reliable (and sometimes,
less intentionally, it fails completely). If we get to a place
where we're willing to bank on stats being collected 100% of the
time, it might make sense.
regards, tom lane
ttle suspicious that startcreate is merrily starting
the postmaster on port 5432, without concern for the possibility
that that port is in use or blocked by a packet filter.
regards, tom lane
Andres Freund writes:
> On 2022-03-04 09:54:28 -0500, Tom Lane wrote:
>> I find it a little suspicious that startcreate is merrily starting
>> the postmaster on port 5432, without concern for the possibility
>> that that port is in use or blocked by a packet filter.
>
Andres Freund writes:
> On 2022-03-04 12:23:43 -0500, Tom Lane wrote:
>> pg_regress thinks the postmaster is listening to a Unix socket.
> pg_regress outputs the above message when neither PGHOST, PGPORT or
> --host/--port are set. On windows that nevertheless ends up wit
on of the extension, and that's intentional.
Yeah, exactly. But this opens up an additional consideration we
have to account for: whatever we do needs to work with either 1.1
or 1.2 SQL-level versions of the extension.
regards, tom lane
Agreed, this is not something to move on quickly. We might want
to think about adjusting pg_dump to use explicit GRANTED BY
options in GRANT/REVOKE a release or two before making incompatible
changes.
regards, tom lane
I don't think it's a good idea to hack that without understanding
why it's suddenly going wrong.
regards, tom lane
having to write our own code to do
the I/O redirections --- that's certainly why we use a shell on the
Unix side. But it might well be that biting the bullet and handling
redirection ourselves would be easier than coping with all these
other problems.
regards, tom lane
thentication, libpq will fail. There is no negotiation.
Seems reasonable, but I bet that for very little more code you could
accept a comma-separated list of allowed methods; libpq already allows
comma-separated lists for some other connection options. That seems
like it'd be a useful increment of flexibility.
regards, tom lane
Andrew Dunstan writes:
> On 3/4/22 20:19, Tom Lane wrote:
>> Seems reasonable, but I bet that for very little more code you could
>> accept a comma-separated list of allowed methods; libpq already allows
>> comma-separated lists for some other connection options. That se
Robert Haas writes:
> On Fri, Mar 4, 2022 at 4:34 PM Tom Lane wrote:
>> Agreed, this is not something to move on quickly. We might want
>> to think about adjusting pg_dump to use explicit GRANTED BY
>> options in GRANT/REVOKE a release or two before making incompatible
&
t role admin;
SET
regression=> revoke admin from sally;
ERROR: must have admin option on role "admin"
I think there is an issue here around exactly what the admin option
means, but if it doesn't grant you the ability to remove grants
made by other people, it's pretty hard to see what it's for.
regards, tom lane
Mark Dilger writes:
>> On Mar 6, 2022, at 2:13 PM, Tom Lane wrote:
>> ... Or, if that's our position, why are there
>> per-GUC changes at all, rather than just redefining what the
>> context values mean? (That is, why not redefine USERSET and
>> SUSET as simp
Mark Dilger writes:
> On Mar 6, 2022, at 2:57 PM, Tom Lane wrote:
>> I don't think this is materially different from what we do with
>> permissions on (say) functions. If you want to revoke the public
>> SET privilege on some USERSET variable, you instantiate the
g the URL
during tarball build, but that does nothing for the people who pull
directly from git.
I thought briefly about directing people to read
doc/src/sgml/html/installation.html, but that has the same problem
that it won't be present in a fresh git pull.
regards, tom lane
historical research,
I wonder why it is that we don't attach significance to WITH ADMIN
OPTION being granted to the role itself. It seems like the second
part of that sentence is effectively saying that a role DOES have
admin option on itself, contradicting the first part.
regards, tom lane
Robert Haas writes:
> It appears to me that the actual behavior of having is_admin_of_role()
> return true when member == role dates to
> f9fd1764615ed5d85fab703b0ffb0c323fe7dfd5 (Tom Lane, 2005). If I'm not
> reading this code wrong, prior to that commit, it seems to me that w
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Agreed, this is not something to move on quickly. We might want
>> to think about adjusting pg_dump to use explicit GRANTED BY
>> options in GRANT/REVOKE a release or two before making incompatible
>>
ly that. I don't want us to change the
pg_dump output in such a way that the grants can't be restored at all
to an older server, just because of a syntax choice that we could
make backwards-compatibly instead of not-backwards-compatibly.
regards, tom lane
n such a painful transition, and we have the git
> history if needed.
I think we should leave it in. I foresee that somebody will want to build
plpython2u as an out-of-core extension, at least for a few years yet.
If they do, and the core language does not have its half of that gua
as though that user has
admin privilege (whether or not it's a member). Perhaps I'm
reinventing something that was already discussed upthread. I wonder
what the SQL spec has to say on this point, too.
regards, tom lane
ld state. Maybe we can assume people doing
such a thing have even more clue ... but on the whole I'd rather
not add the additional complication.
regards, tom lane
ildfarm makes of it.
regards, tom lane
Andres Freund writes:
> On 2022-03-07 20:11:52 -0500, Tom Lane wrote:
>> This version seems ready-to-go to me, or at least ready to see
>> what the buildfarm makes of it.
> Pushed. Let's see...
wrasse says you were too quick to drop plpython_error_5.out.
Otherwise l
Dong Wook Lee writes:
> [ 0001_add_test_pg_fsm.patch ]
I think having some coverage here would be great, but I'm concerned that
this patch doesn't look very portable. Aren't the numbers liable to
change on 32-bit machines, in particular?
regards, tom lane
these out and seeing if the
buildfarm complains. (If so, maybe -Wno-register would help?)
regards, tom lane
Andres Freund writes:
> A bit depressing to have a 500 line alternative output file for a one line
> diff :(.
Yeah. How badly do we need that particular test case?
regards, tom lane
Magnus Hagander writes:
> On Mon, Mar 7, 2022 at 11:51 PM Tom Lane wrote:
>> Doesn't really help people working from git, I think, because the
>> master branch is always going to claim to be "devel" even when you
>> rewind it to some old state. Maybe we can
Robert Haas writes:
> On Mar 7, 2022, at 12:16 PM, Tom Lane wrote:
> tgl> Having said that, one thing that I find fishy is that it's not clear
> tgl> where the admin privilege for a role originates. After "CREATE ROLE
> tgl> alice", alice has no members, ther
1 - 100 of 17502 matches
Mail list logo
