public inbox for [email protected]
help / color / mirror / Atom feedTime to drop old-style (V0) functions?
86+ messages / 8 participants
[nested] [flat]
* Time to drop old-style (V0) functions?
@ 2016-12-08 21:34 Andres Freund <[email protected]>
2016-12-08 21:57 ` Re: Time to drop old-style (V0) functions? Stephen Frost <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
0 siblings, 2 replies; 86+ messages in thread
From: Andres Freund @ 2016-12-08 21:34 UTC (permalink / raw)
To: pgsql-hackers
Hi,
I'm wondering if it's not time for $subject:
- V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
forgotten
- They have us keep weird hacks around just for the sake of testing V0
- they actually cost performance, because we have to zero initialize Datums, even if
the corresponding isnull marker is set.
- they allow to call arbitrary functions pretty easily
I don't see any reason to keep them around. If seriously doubt anybody
is using them seriously in anything but error.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-08 21:57 ` Stephen Frost <[email protected]>
1 sibling, 0 replies; 86+ messages in thread
From: Stephen Frost @ 2016-12-08 21:57 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres, all,
* Andres Freund ([email protected]) wrote:
> I'm wondering if it's not time for $subject:
> - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
> forgotten
> - They have us keep weird hacks around just for the sake of testing V0
> - they actually cost performance, because we have to zero initialize Datums, even if
> the corresponding isnull marker is set.
> - they allow to call arbitrary functions pretty easily
>
> I don't see any reason to keep them around. If seriously doubt anybody
> is using them seriously in anything but error.
+100
Thanks!
Stephen
Attachments:
[application/pgp-signature] signature.asc (819B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-08 22:38 ` Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
1 sibling, 1 reply; 86+ messages in thread
From: Tom Lane @ 2016-12-08 22:38 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres Freund <[email protected]> writes:
> I'm wondering if it's not time for $subject:
> - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
> forgotten
> - They have us keep weird hacks around just for the sake of testing V0
> - they actually cost performance, because we have to zero initialize Datums, even if
> the corresponding isnull marker is set.
> - they allow to call arbitrary functions pretty easily
If by the first point you mean "assume V1 when no info function is found",
I object to that. If you mean you want to require an info function, that
might be OK.
The habit of zero-initializing Datums has got exactly nothing to do with
V0 functions; it's about ensuring consistent results and avoiding
heisenbugs from use of uninitialized memory. I do not think we should
drop it.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
@ 2016-12-08 22:53 ` Andres Freund <[email protected]>
2016-12-08 23:00 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 23:03 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
0 siblings, 3 replies; 86+ messages in thread
From: Andres Freund @ 2016-12-08 22:53 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
> Andres Freund <[email protected]> writes:
> > I'm wondering if it's not time for $subject:
> > - V0 causes confusion / weird crashes when PG_FUNCTION_INFO_V1 was
> > forgotten
> > - They have us keep weird hacks around just for the sake of testing V0
> > - they actually cost performance, because we have to zero initialize Datums, even if
> > the corresponding isnull marker is set.
> > - they allow to call arbitrary functions pretty easily
>
> If by the first point you mean "assume V1 when no info function is found",
> I object to that. If you mean you want to require an info function, that
> might be OK.
I mean throwing an error. Silently assuming V1 seems like a horrible
idea to me. It doesn't seem unlikely that we want to introduce a new
call interface at some point given the runtime cost of the current one,
and that'd just bring back the current problem.
> The habit of zero-initializing Datums has got exactly nothing to do with
> V0 functions; it's about ensuring consistent results and avoiding
> heisenbugs from use of uninitialized memory. I do not think we should
> drop it.
Well, V0 functions don't have a real way to get information about NULL,
and we allow non-strict V0 functions, so?
Regards,
Andres
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-08 23:00 ` Andres Freund <[email protected]>
2 siblings, 0 replies; 86+ messages in thread
From: Andres Freund @ 2016-12-08 23:00 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
On 2016-12-08 14:53:58 -0800, Andres Freund wrote:
> On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
> > The habit of zero-initializing Datums has got exactly nothing to do with
> > V0 functions; it's about ensuring consistent results and avoiding
> > heisenbugs from use of uninitialized memory. I do not think we should
> > drop it.
>
> Well, V0 functions don't have a real way to get information about NULL,
> and we allow non-strict V0 functions, so?
Oh, and the regression tests fail in V0 functions if you drop that.
Andres
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-08 23:03 ` Tom Lane <[email protected]>
2016-12-08 23:08 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2 siblings, 1 reply; 86+ messages in thread
From: Tom Lane @ 2016-12-08 23:03 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: pgsql-hackers
Andres Freund <[email protected]> writes:
> On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
>> The habit of zero-initializing Datums has got exactly nothing to do with
>> V0 functions; it's about ensuring consistent results and avoiding
>> heisenbugs from use of uninitialized memory. I do not think we should
>> drop it.
> Well, V0 functions don't have a real way to get information about NULL,
> and we allow non-strict V0 functions, so?
Non-strict V0 functions are pretty fundamentally broken, although IIRC
there was some hack whereby they could see the isnull marker for their
first argument, which is why we didn't just disallow the case. There was
never any expectation that checking for value == 0 was an appropriate
coding method for detecting nulls, because it couldn't work for
pass-by-value data types.
Again, the point of initializing those values is not to support broken
tests for nullness. It's to ensure consistent behavior in case of
buggy attempts to use null values. It's much like the fact that makeNode
zero-fills new node structs: that's mostly wasted work, if you want to
look at it in a certain way, but it's good for reproducibility.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 23:03 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
@ 2016-12-08 23:08 ` Andres Freund <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Andres Freund @ 2016-12-08 23:08 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
On 2016-12-08 18:03:04 -0500, Tom Lane wrote:
> Andres Freund <[email protected]> writes:
> > On 2016-12-08 17:38:38 -0500, Tom Lane wrote:
> >> The habit of zero-initializing Datums has got exactly nothing to do with
> >> V0 functions; it's about ensuring consistent results and avoiding
> >> heisenbugs from use of uninitialized memory. I do not think we should
> >> drop it.
>
> > Well, V0 functions don't have a real way to get information about NULL,
> > and we allow non-strict V0 functions, so?
>
> Non-strict V0 functions are pretty fundamentally broken, although IIRC
> there was some hack whereby they could see the isnull marker for their
> first argument, which is why we didn't just disallow the case. There was
> never any expectation that checking for value == 0 was an appropriate
> coding method for detecting nulls, because it couldn't work for
> pass-by-value data types.
Well, we have a bunch in our regression tests ;). And I'm not saying
it's *good* that they rely on that, I think it's a reason to drop the
whole V0 interface.
(I also suspect there's a bunch in brin related to this)
> Again, the point of initializing those values is not to support broken
> tests for nullness. It's to ensure consistent behavior in case of
> buggy attempts to use null values.
Well, it also makes such attempts undetectable. I'm not really convinced
that that's such an improvement.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-09 12:52 ` Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2 siblings, 1 reply; 86+ messages in thread
From: Robert Haas @ 2016-12-09 12:52 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers
On Thu, Dec 8, 2016 at 5:53 PM, Andres Freund <[email protected]> wrote:
> I mean throwing an error. Silently assuming V1 seems like a horrible
> idea to me. It doesn't seem unlikely that we want to introduce a new
> call interface at some point given the runtime cost of the current one,
> and that'd just bring back the current problem.
I don't have a problem with getting rid of V0; I think it's an
annoyance. But I think a much more interesting question is how to
redesign this interface. I think V0 actually had the right idea in
passing arguments as C arguments rather than marshaling them in some
other data structure. If the function doesn't need flinfo or context
or collation and takes a fixed number of argument each of which is
either strict or a pass-by-reference data type (where you can use
DatumGetPointer(NULL) to represent a NULL!) and either never returns
NULL or returns a pass-by-reference data type, then you don't need any
of this complicated fcinfo stuff. You can just pass the arguments and
get back the result. That's less work for both the caller (who
doesn't have to stick the arguments into an fcinfo) and the callee
(who doesn't have to fish them back out). In the sortsupport
machinery, we've gone to some lengths to make it possible - at least
in the context of sorts - to get back to something closer to that kind
of interface. But that interface goes to considerable trouble to
achieve that result, making it practical only for bulk operations.
It's kind of ironic, at least IMHO, that the DirectionFunctionCall
macros are anything but direct. Each one is a non-inlined function
call that does a minimum of 8 variable assignments before actually
calling the function.
There obviously has to be some provision for functions that actually
need all the stuff we pass in the V1 calling convention, but there are
a huge number of functions that don't need any of it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
@ 2016-12-19 20:13 ` Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Peter Eisentraut @ 2016-12-19 20:13 UTC (permalink / raw)
To: Robert Haas <[email protected]>; Andres Freund <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers
On 12/9/16 7:52 AM, Robert Haas wrote:
> It's kind of ironic, at least IMHO, that the DirectionFunctionCall
> macros are anything but direct. Each one is a non-inlined function
> call that does a minimum of 8 variable assignments before actually
> calling the function.
If this is a problem (it might be), then we can just make those calls,
er, direct C function calls to different function. For example,
result = DatumGetObjectId(DirectFunctionCall1(oidin,
CStringGetDatum(pro_name_or_oid)));
could just be
result = oidin_internal(pro_name_or_oid);
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
@ 2016-12-19 20:25 ` Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Robert Haas @ 2016-12-19 20:25 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Andres Freund <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On Mon, Dec 19, 2016 at 3:13 PM, Peter Eisentraut
<[email protected]> wrote:
> On 12/9/16 7:52 AM, Robert Haas wrote:
>> It's kind of ironic, at least IMHO, that the DirectionFunctionCall
>> macros are anything but direct. Each one is a non-inlined function
>> call that does a minimum of 8 variable assignments before actually
>> calling the function.
>
> If this is a problem (it might be), then we can just make those calls,
> er, direct C function calls to different function. For example,
>
> result = DatumGetObjectId(DirectFunctionCall1(oidin,
> CStringGetDatum(pro_name_or_oid)));
>
> could just be
>
> result = oidin_internal(pro_name_or_oid);
Yeah, true -- that works for simple cases, and might be beneficial
where you're doing lots and lots of calls in a tight loop.
For the more general problem, I wonder if we should try to figure out
something where we have one calling convention for "simple" functions
(those that little or none of the information in fcinfo and can pretty
much just take their SQL args as C args) and another for "complex"
functions (where we do the full push-ups).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
@ 2016-12-20 08:11 ` Andres Freund <[email protected]>
2016-12-20 08:59 ` Re: Time to drop old-style (V0) functions? Pavel Stehule <[email protected]>
2016-12-20 13:15 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
0 siblings, 2 replies; 86+ messages in thread
From: Andres Freund @ 2016-12-20 08:11 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On 2016-12-19 15:25:42 -0500, Robert Haas wrote:
> On Mon, Dec 19, 2016 at 3:13 PM, Peter Eisentraut
> <[email protected]> wrote:
> > On 12/9/16 7:52 AM, Robert Haas wrote:
> >> It's kind of ironic, at least IMHO, that the DirectionFunctionCall
> >> macros are anything but direct. Each one is a non-inlined function
> >> call that does a minimum of 8 variable assignments before actually
> >> calling the function.
> >
> > If this is a problem (it might be), then we can just make those calls,
> > er, direct C function calls to different function. For example,
> >
> > result = DatumGetObjectId(DirectFunctionCall1(oidin,
> > CStringGetDatum(pro_name_or_oid)));
> >
> > could just be
> >
> > result = oidin_internal(pro_name_or_oid);
>
> Yeah, true -- that works for simple cases, and might be beneficial
> where you're doing lots and lots of calls in a tight loop.
>
> For the more general problem, I wonder if we should try to figure out
> something where we have one calling convention for "simple" functions
> (those that little or none of the information in fcinfo and can pretty
> much just take their SQL args as C args) and another for "complex"
> functions (where we do the full push-ups).
Unfortunately I think so would likely also increase overhead in a bunch
of places, because suddenly we need branches determining which callling
convention is in use. There's a fair amount of places, some of them
performance sensitive, that deal with functions that can get different
number of arguments. Prominently nodeAgg.c's transition functions for
example.
When JITing expressions that doesn't matter, because we avoid doing so
repetitively. But that's not really sufficient imo, non JITed
performance matters a lot too.
There's imo primarily two parts that make our calling convention
expensive:
a) Additional instructions required to push to/from fcinfo->arg[null],
including stack spilling required to have space for the arguments.
b) Increased number of cachelines touched, even for even trivial
functions. We need to read/write to at least five:
1) fcinfo->isnull to reset it
2) fcinfo->arg[0...] to set the argument
3) fcinfo->argnull[0...] to set argnull (separate cacheline)
4) fcinfo->flinfo->fn_addr to get the actual address to call
5) instruction cache miss for the function's contents
We can doctor around this some. A retively easy way to reduce the
overhead of a similar function call interface would be to restructure
things so we have something like:
typedef struct FunctionArg2
{
Datum arg;
bool argnull;
} FunctionArg2;
typedef struct FunctionCallInfoData2
{
/* cached function address from ->flinfo */
PGFunction fn_addr;
/* ptr to lookup info used for this call */
FmgrInfo *flinfo;
/* function must set true if result is NULL */
bool isnull;
/* # arguments actually passed */
short nargs;
/* collation for function to use */
Oid fncollation; /* collation for function to use */
/* pass or return extra info about result */
fmNodePtr resultinfo;
/* array big enough to fit flinfo->fn_nargs */
FunctionArg2 args[FLEXIBLE_ARRAY_MEMBER];
} FunctionCallInfoData2;
That'd mean some code changes because accessing arguments can't be done
quite as now, but it'd be fairly minor. We'd end up with a lot fewer
cache misses for common cases, because there's no need to fetch fn_addr,
and because the first two arg/argnull pairs still fit within the first
cacheline (which they never can in the current interface!).
But we'd still be passing arguments via memory, instead of using
registers.
I think a more efficient variant would make the function signature look
something like:
Datum /* directly returned argument */
pgfunc(
/* extra information about function call */
FunctionCallInfo *fcinfo,
/* bitmap of NULL arguments */
uint64_t nulls,
/* first argument */
Datum arg0,
/* second argument */
Datum arg1,
/* returned NULL */
bool *isnull
);
with additional arguments passed via fcinfo as currently done. Since
most of the performance critical function calls only have two arguments
that should allow to keep usage of fcinfo-> to the cases where we need
the extra information. On 64bit linuxes the above will be entirely in
registers, on 64bit windows isnull would be placed on the stack.
I don't quite see how we could avoid stack usage at all for windows, any
of the above arguments seems important.
There'd be a need for some trickery to make PG_GETARG_DATUM() work
efficiently - afaics the argument numbers passed to PG_GETARG_*() are
always constants, so that shouldn't be too bad.
Regards,
Andres
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-20 08:59 ` Pavel Stehule <[email protected]>
2016-12-20 09:14 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
1 sibling, 1 reply; 86+ messages in thread
From: Pavel Stehule @ 2016-12-20 08:59 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
2016-12-20 9:11 GMT+01:00 Andres Freund <[email protected]>:
> On 2016-12-19 15:25:42 -0500, Robert Haas wrote:
> > On Mon, Dec 19, 2016 at 3:13 PM, Peter Eisentraut
> > <[email protected]> wrote:
> > > On 12/9/16 7:52 AM, Robert Haas wrote:
> > >> It's kind of ironic, at least IMHO, that the DirectionFunctionCall
> > >> macros are anything but direct. Each one is a non-inlined function
> > >> call that does a minimum of 8 variable assignments before actually
> > >> calling the function.
> > >
> > > If this is a problem (it might be), then we can just make those calls,
> > > er, direct C function calls to different function. For example,
> > >
> > > result = DatumGetObjectId(DirectFunctionCall1(oidin,
> > > CStringGetDatum(pro_name_or_oid)));
> > >
> > > could just be
> > >
> > > result = oidin_internal(pro_name_or_oid);
> >
> > Yeah, true -- that works for simple cases, and might be beneficial
> > where you're doing lots and lots of calls in a tight loop.
> >
> > For the more general problem, I wonder if we should try to figure out
> > something where we have one calling convention for "simple" functions
> > (those that little or none of the information in fcinfo and can pretty
> > much just take their SQL args as C args) and another for "complex"
> > functions (where we do the full push-ups).
>
> Unfortunately I think so would likely also increase overhead in a bunch
> of places, because suddenly we need branches determining which callling
> convention is in use. There's a fair amount of places, some of them
> performance sensitive, that deal with functions that can get different
> number of arguments. Prominently nodeAgg.c's transition functions for
> example.
>
> When JITing expressions that doesn't matter, because we avoid doing so
> repetitively. But that's not really sufficient imo, non JITed
> performance matters a lot too.
>
> There's imo primarily two parts that make our calling convention
> expensive:
> a) Additional instructions required to push to/from fcinfo->arg[null],
> including stack spilling required to have space for the arguments.
> b) Increased number of cachelines touched, even for even trivial
> functions. We need to read/write to at least five:
> 1) fcinfo->isnull to reset it
> 2) fcinfo->arg[0...] to set the argument
> 3) fcinfo->argnull[0...] to set argnull (separate cacheline)
> 4) fcinfo->flinfo->fn_addr to get the actual address to call
> 5) instruction cache miss for the function's contents
>
> We can doctor around this some. A retively easy way to reduce the
> overhead of a similar function call interface would be to restructure
> things so we have something like:
>
> typedef struct FunctionArg2
> {
> Datum arg;
> bool argnull;
> } FunctionArg2;
>
> typedef struct FunctionCallInfoData2
> {
> /* cached function address from ->flinfo */
> PGFunction fn_addr;
> /* ptr to lookup info used for this call */
> FmgrInfo *flinfo;
> /* function must set true if result is NULL */
> bool isnull;
> /* # arguments actually passed */
> short nargs;
> /* collation for function to use */
> Oid fncollation; /* collation for function to use */
> /* pass or return extra info about result */
> fmNodePtr resultinfo;
> /* array big enough to fit flinfo->fn_nargs */
> FunctionArg2 args[FLEXIBLE_ARRAY_MEMBER];
> } FunctionCallInfoData2;
>
> That'd mean some code changes because accessing arguments can't be done
> quite as now, but it'd be fairly minor. We'd end up with a lot fewer
> cache misses for common cases, because there's no need to fetch fn_addr,
> and because the first two arg/argnull pairs still fit within the first
> cacheline (which they never can in the current interface!).
>
> But we'd still be passing arguments via memory, instead of using
> registers.
>
> I think a more efficient variant would make the function signature look
> something like:
>
> Datum /* directly returned argument */
> pgfunc(
> /* extra information about function call */
> FunctionCallInfo *fcinfo,
> /* bitmap of NULL arguments */
> uint64_t nulls,
> /* first argument */
> Datum arg0,
> /* second argument */
> Datum arg1,
> /* returned NULL */
> bool *isnull
> );
>
> with additional arguments passed via fcinfo as currently done. Since
> most of the performance critical function calls only have two arguments
> that should allow to keep usage of fcinfo-> to the cases where we need
> the extra information. On 64bit linuxes the above will be entirely in
> registers, on 64bit windows isnull would be placed on the stack.
>
> I don't quite see how we could avoid stack usage at all for windows, any
> of the above arguments seems important.
>
> There'd be a need for some trickery to make PG_GETARG_DATUM() work
> efficiently - afaics the argument numbers passed to PG_GETARG_*() are
> always constants, so that shouldn't be too bad.
>
In this case some benchmark can be very important (and interesting). I am
not sure if faster function execution has significant benefit on Vulcano
like executor.
Regards
Pavel
>
> Regards,
>
> Andres
>
>
> --
> Sent via pgsql-hackers mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 08:59 ` Re: Time to drop old-style (V0) functions? Pavel Stehule <[email protected]>
@ 2016-12-20 09:14 ` Andres Freund <[email protected]>
2016-12-20 09:28 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Andres Freund @ 2016-12-20 09:14 UTC (permalink / raw)
To: Pavel Stehule <[email protected]>; +Cc: Robert Haas <[email protected]>; Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> In this case some benchmark can be very important (and interesting). I am
> not sure if faster function execution has significant benefit on Vulcano
> like executor.
It's fairly to see function calls as significant overhead. In fact, I
moved things *away* from a pure Vulcano style executor, and the benefits
weren't huge, primarily due to expression evaluation overhead (of which
function call overhead is one part). After JITing of expressions, it
becomes even more noticeable, because the overhead of the expression
evaluation is reduced.
I don't quite see why a Vulcano style executor should make function call
overhead meaningless?
Regards,
Andres
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 08:59 ` Re: Time to drop old-style (V0) functions? Pavel Stehule <[email protected]>
2016-12-20 09:14 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-20 09:28 ` Andres Freund <[email protected]>
2016-12-20 09:44 ` Re: Time to drop old-style (V0) functions? Pavel Stehule <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Andres Freund @ 2016-12-20 09:28 UTC (permalink / raw)
To: Pavel Stehule <[email protected]>; +Cc: Robert Haas <[email protected]>; Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On 2016-12-20 01:14:10 -0800, Andres Freund wrote:
> On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> > In this case some benchmark can be very important (and interesting). I am
> > not sure if faster function execution has significant benefit on Vulcano
> > like executor.
>
> It's fairly to see function calls as significant overhead. In fact, I
> moved things *away* from a pure Vulcano style executor, and the benefits
> weren't huge, primarily due to expression evaluation overhead (of which
> function call overhead is one part). After JITing of expressions, it
> becomes even more noticeable, because the overhead of the expression
> evaluation is reduced.
As an example, here's a JITed TPCH Q1 profile:
+ 15.48% postgres postgres [.] slot_deform_tuple
+ 8.42% postgres perf-27760.map [.] evalexpr90
+ 5.98% postgres postgres [.] float8_accum
+ 4.63% postgres postgres [.] slot_getattr
+ 3.69% postgres postgres [.] bpchareq
+ 3.39% postgres postgres [.] heap_getnext
+ 3.22% postgres postgres [.] float8pl
+ 2.86% postgres postgres [.] TupleHashTableMatch.isra.7
+ 2.77% postgres postgres [.] hashbpchar
+ 2.77% postgres postgres [.] float8mul
+ 2.73% postgres postgres [.] ExecAgg
+ 2.40% postgres postgres [.] hash_any
+ 2.34% postgres postgres [.] MemoryContextReset
+ 1.98% postgres postgres [.] pg_detoast_datum_packed
evalexpr90 is the expression that does the aggregate transition
function. float8_accum, bpchareq, float8pl , float8mul, ... are all
function calls, and a good percentage of the overhead in evalexpr90 is
pushing arguments onto fcinfo->arg[nulls].
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 08:59 ` Re: Time to drop old-style (V0) functions? Pavel Stehule <[email protected]>
2016-12-20 09:14 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 09:28 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-20 09:44 ` Pavel Stehule <[email protected]>
2016-12-20 09:58 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Pavel Stehule @ 2016-12-20 09:44 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Robert Haas <[email protected]>; Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
2016-12-20 10:28 GMT+01:00 Andres Freund <[email protected]>:
> On 2016-12-20 01:14:10 -0800, Andres Freund wrote:
> > On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> > > In this case some benchmark can be very important (and interesting). I
> am
> > > not sure if faster function execution has significant benefit on
> Vulcano
> > > like executor.
> >
> > It's fairly to see function calls as significant overhead. In fact, I
> > moved things *away* from a pure Vulcano style executor, and the benefits
> > weren't huge, primarily due to expression evaluation overhead (of which
> > function call overhead is one part). After JITing of expressions, it
> > becomes even more noticeable, because the overhead of the expression
> > evaluation is reduced.
>
For me a Vulcano style is row by row processing. Using JIT or not using has
not significant impact.
Interesting change can be block level processing.
>
> As an example, here's a JITed TPCH Q1 profile:
> + 15.48% postgres postgres [.]
> slot_deform_tuple
> + 8.42% postgres perf-27760.map [.] evalexpr90
> + 5.98% postgres postgres [.] float8_accum
> + 4.63% postgres postgres [.] slot_getattr
> + 3.69% postgres postgres [.] bpchareq
> + 3.39% postgres postgres [.] heap_getnext
> + 3.22% postgres postgres [.] float8pl
> + 2.86% postgres postgres [.]
> TupleHashTableMatch.isra.7
> + 2.77% postgres postgres [.] hashbpchar
> + 2.77% postgres postgres [.] float8mul
> + 2.73% postgres postgres [.] ExecAgg
> + 2.40% postgres postgres [.] hash_any
> + 2.34% postgres postgres [.]
> MemoryContextReset
> + 1.98% postgres postgres [.]
> pg_detoast_datum_packed
>
>
Our bottle neck is row format and row related processing.
> evalexpr90 is the expression that does the aggregate transition
> function. float8_accum, bpchareq, float8pl , float8mul, ... are all
> function calls, and a good percentage of the overhead in evalexpr90 is
> pushing arguments onto fcinfo->arg[nulls].
>
> Greetings,
>
> Andres Freund
>
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 08:59 ` Re: Time to drop old-style (V0) functions? Pavel Stehule <[email protected]>
2016-12-20 09:14 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 09:28 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 09:44 ` Re: Time to drop old-style (V0) functions? Pavel Stehule <[email protected]>
@ 2016-12-20 09:58 ` Andres Freund <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Andres Freund @ 2016-12-20 09:58 UTC (permalink / raw)
To: Pavel Stehule <[email protected]>; +Cc: Robert Haas <[email protected]>; Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On 2016-12-20 10:44:35 +0100, Pavel Stehule wrote:
> 2016-12-20 10:28 GMT+01:00 Andres Freund <[email protected]>:
>
> > On 2016-12-20 01:14:10 -0800, Andres Freund wrote:
> > > On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote:
> > > > In this case some benchmark can be very important (and interesting). I
> > am
> > > > not sure if faster function execution has significant benefit on
> > Vulcano
> > > > like executor.
> > >
> > > It's fairly to see function calls as significant overhead. In fact, I
> > > moved things *away* from a pure Vulcano style executor, and the benefits
> > > weren't huge, primarily due to expression evaluation overhead (of which
> > > function call overhead is one part). After JITing of expressions, it
> > > becomes even more noticeable, because the overhead of the expression
> > > evaluation is reduced.
> >
>
> For me a Vulcano style is row by row processing. Using JIT or not using has
> not significant impact.
>
> Interesting change can be block level processing.
I don't think that's true. The largest bottlenecks atm have relatively
little to do with block level processing. I know, because I went
there. We have so many other bottlenecks that row-by-row processing
vanishes behind them. Without changing the tuple flow, the performance
with either applied or posted patches for TPCH-Q1 already went up by
more than a factor of 2.5.
Anyway, this seems like a side-track discussion, better done in another
thread.
Andres
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-20 13:15 ` Robert Haas <[email protected]>
2016-12-20 13:21 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
1 sibling, 1 reply; 86+ messages in thread
From: Robert Haas @ 2016-12-20 13:15 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund <[email protected]> wrote:
> I think a more efficient variant would make the function signature look
> something like:
>
> Datum /* directly returned argument */
> pgfunc(
> /* extra information about function call */
> FunctionCallInfo *fcinfo,
> /* bitmap of NULL arguments */
> uint64_t nulls,
> /* first argument */
> Datum arg0,
> /* second argument */
> Datum arg1,
> /* returned NULL */
> bool *isnull
> );
Yeah, that's kind of nice. I like the uint64 for nulls, although
FUNC_MAX_ARGS > 64 by default and certainly can be configured that
way. It wouldn't be a problem for any common cases, of course.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:15 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
@ 2016-12-20 13:21 ` Andres Freund <[email protected]>
2016-12-20 13:35 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Andres Freund @ 2016-12-20 13:21 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund <[email protected]> wrote:
> > I think a more efficient variant would make the function signature look
> > something like:
> >
> > Datum /* directly returned argument */
> > pgfunc(
> > /* extra information about function call */
> > FunctionCallInfo *fcinfo,
> > /* bitmap of NULL arguments */
> > uint64_t nulls,
> > /* first argument */
> > Datum arg0,
> > /* second argument */
> > Datum arg1,
> > /* returned NULL */
> > bool *isnull
> > );
>
> Yeah, that's kind of nice. I like the uint64 for nulls, although
> FUNC_MAX_ARGS > 64 by default and certainly can be configured that
> way. It wouldn't be a problem for any common cases, of course.
Well, I suspect we'd have to change that then. Is anybody seriously
interested in supporting FUNC_MAX_ARGS > 64? We don't have to make our
life hard by supporting useless features... I'd even question using
64bit for this on 32bit platforms.
Andres
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:15 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 13:21 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-20 13:35 ` Robert Haas <[email protected]>
2016-12-20 13:44 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Robert Haas @ 2016-12-20 13:35 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On Tue, Dec 20, 2016 at 8:21 AM, Andres Freund <[email protected]> wrote:
> On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
>> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund <[email protected]> wrote:
>> > I think a more efficient variant would make the function signature look
>> > something like:
>> >
>> > Datum /* directly returned argument */
>> > pgfunc(
>> > /* extra information about function call */
>> > FunctionCallInfo *fcinfo,
>> > /* bitmap of NULL arguments */
>> > uint64_t nulls,
>> > /* first argument */
>> > Datum arg0,
>> > /* second argument */
>> > Datum arg1,
>> > /* returned NULL */
>> > bool *isnull
>> > );
>>
>> Yeah, that's kind of nice. I like the uint64 for nulls, although
>> FUNC_MAX_ARGS > 64 by default and certainly can be configured that
>> way. It wouldn't be a problem for any common cases, of course.
>
> Well, I suspect we'd have to change that then. Is anybody seriously
> interested in supporting FUNC_MAX_ARGS > 64? We don't have to make our
> life hard by supporting useless features... I'd even question using
> 64bit for this on 32bit platforms.
Advanced Server uses 256, and we had a customer complain recently that
256 wasn't high enough. So apparently the use case for functions with
ridiculous numbers of arguments isn't exactly 0. For most people it's
not a big problem in practice, but actually I think that it's pretty
lame that we have a limit at all. I mean, there's no reason that we
can't use dynamic allocation here. If we put the first, say, 8
arguments in the FunctionCallInfoData itself and then separately
allocated space any extras, the structure could be a lot smaller
without needing an arbitrary limit on the argument count.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:15 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 13:21 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:35 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
@ 2016-12-20 13:44 ` Andres Freund <[email protected]>
2016-12-20 14:12 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Andres Freund @ 2016-12-20 13:44 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On 2016-12-20 08:35:05 -0500, Robert Haas wrote:
> On Tue, Dec 20, 2016 at 8:21 AM, Andres Freund <[email protected]> wrote:
> > On 2016-12-20 08:15:07 -0500, Robert Haas wrote:
> >> On Tue, Dec 20, 2016 at 3:11 AM, Andres Freund <[email protected]> wrote:
> >> > I think a more efficient variant would make the function signature look
> >> > something like:
> >> >
> >> > Datum /* directly returned argument */
> >> > pgfunc(
> >> > /* extra information about function call */
> >> > FunctionCallInfo *fcinfo,
> >> > /* bitmap of NULL arguments */
> >> > uint64_t nulls,
> >> > /* first argument */
> >> > Datum arg0,
> >> > /* second argument */
> >> > Datum arg1,
> >> > /* returned NULL */
> >> > bool *isnull
> >> > );
> >>
> >> Yeah, that's kind of nice. I like the uint64 for nulls, although
> >> FUNC_MAX_ARGS > 64 by default and certainly can be configured that
> >> way. It wouldn't be a problem for any common cases, of course.
> >
> > Well, I suspect we'd have to change that then. Is anybody seriously
> > interested in supporting FUNC_MAX_ARGS > 64? We don't have to make our
> > life hard by supporting useless features... I'd even question using
> > 64bit for this on 32bit platforms.
>
> Advanced Server uses 256, and we had a customer complain recently that
> 256 wasn't high enough. So apparently the use case for functions with
> ridiculous numbers of arguments isn't exactly 0.
Well, there's a cost/benefit analysis involved here, as in a lot of
other places. There's a lot of things one can conceive a use-case for,
doesn't mean it's worth catering for all of them.
> I mean, there's no reason that we can't use dynamic allocation here.
> If we put the first, say, 8 arguments in the FunctionCallInfoData
> itself and then separately allocated space any extras, the structure
> could be a lot smaller without needing an arbitrary limit on the
> argument count.
Except that that'll mean additional overhead during evaluation of
function arguments, an overhead that everyone will have to pay. Suddenly
you need two loops that fill in arguments, depending on their
argument-number (i.e. additional branches in a thight spot). And not
being able to pass the null bitmap via an register argument also costs
everyone.
Andres
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:15 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 13:21 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:35 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 13:44 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
@ 2016-12-20 14:12 ` Robert Haas <[email protected]>
2016-12-20 15:04 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Robert Haas @ 2016-12-20 14:12 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Tom Lane <[email protected]>; pgsql-hackers
On Tue, Dec 20, 2016 at 8:44 AM, Andres Freund <[email protected]> wrote:
>> Advanced Server uses 256, and we had a customer complain recently that
>> 256 wasn't high enough. So apparently the use case for functions with
>> ridiculous numbers of arguments isn't exactly 0.
>
> Well, there's a cost/benefit analysis involved here, as in a lot of
> other places. There's a lot of things one can conceive a use-case for,
> doesn't mean it's worth catering for all of them.
Clearly true.
>> I mean, there's no reason that we can't use dynamic allocation here.
>> If we put the first, say, 8 arguments in the FunctionCallInfoData
>> itself and then separately allocated space any extras, the structure
>> could be a lot smaller without needing an arbitrary limit on the
>> argument count.
>
> Except that that'll mean additional overhead during evaluation of
> function arguments, an overhead that everyone will have to pay. Suddenly
> you need two loops that fill in arguments, depending on their
> argument-number (i.e. additional branches in a thight spot). And not
> being able to pass the null bitmap via an register argument also costs
> everyone.
Well, I'm hoping there is a way to have a fast-path and a slow-path
without slowing things down too much. You're proposing something like
that anyway, because you're proposing to put the first two arguments
in actual function arguments and the rest someplace else. I wouldn't
be surprised if 99% of function calls had 2 arguments or less because
most people probably call functions mostly or entirely as operators
and even user-defined functions don't necessarily have lots of
arguments. But we wouldn't propose restricting all function calls to
2 arguments just so +(int4, int4) can be fast. There's clearly got to
be a slow path for calls with more than 2 arguments and, if that's the
case, I don't see why there can't be a really-slow path, perhaps
guarded by unlikely(), for cases involving more than 8 or 16 or
whatever. I find it really hard to believe that in 2016 that we can't
find a way to make simple things fast and complicated things possible.
Saying we can't make SQL-callable functions with large number of
arguments work feels to me like saying that we have to go back to
8-character filenames with 3-character extensions for efficiency - in
the 1980s, that argument might have held some water, but nobody buys
it any more. Human time is worth more than computer time, and humans
save time when programs don't impose inconveniently-small limits.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Time to drop old-style (V0) functions?
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 22:38 ` Re: Time to drop old-style (V0) functions? Tom Lane <[email protected]>
2016-12-08 22:53 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-09 12:52 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-19 20:13 ` Re: Time to drop old-style (V0) functions? Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 08:11 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:15 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 13:21 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 13:35 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
2016-12-20 13:44 ` Re: Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-20 14:12 ` Re: Time to drop old-style (V0) functions? Robert Haas <[email protected]>
@ 2016-12-20 15:04 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Tom Lane @ 2016-12-20 15:04 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Andres Freund <[email protected]>; Peter Eisentraut <[email protected]>; pgsql-hackers
Robert Haas <[email protected]> writes:
> Well, I'm hoping there is a way to have a fast-path and a slow-path
> without slowing things down too much.
Seems like this discussion has veered way off into the weeds.
I suggest we confine it to the stated topic; if you want to discuss
ways to optimize V1 protocol (or invent a V2, which some of this
sounds like it would need), that should be a distinct thread.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v18 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7c06afd3ea..11f5ef9372 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--5I6of5zJg18YgZEa
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v18-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v32 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index e58efce5865..b5c1befe627 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27495,7 +27495,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--Bne5rrxQd65beI7a
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v32-0002-Add-tests-on-pg_ls_dir-before-changing-it.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v24 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 507bc1a668..9c0ad7a334 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25904,7 +25904,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--mPTHnM80CEnHQ2WJ
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v24-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v19 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b7c450ea29..9f47745c5a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25881,7 +25881,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--S0GG+JvAI2G0KxBG
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v19-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v12 02/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 4c0ea5ab3f..ace95fe661 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -21527,7 +21527,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--wIc/V6YLA2QdyfT4
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v12-0003-Document-historic-behavior-about-hiding-director.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v20 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 959f6a1c2f..7ef8c7a847 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25911,7 +25911,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--Z1Z8UV8BNhgCynIS
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v20-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v14 1/8] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index fc4d7f0f78..2c6142a0e0 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -21528,7 +21528,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--Kynn+LdAwU9N+JqL
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v14-0002-Add-tests-on-pg_ls_dir-before-changing-it.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v22 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7ef2ec9972..1b67ef4be8 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25917,7 +25917,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--d6Gm4EdcadzBjdND
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v22-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v36 1/7] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7b652460a18..933118203f4 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -28661,6 +28661,10 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
platforms only), file creation time stamp (Windows only), and a flag
indicating if it is a directory.
</para>
+ <para>
+ If filename is a link, this function returns information about the file
+ or directory the link refers to.
+ </para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
--
2.17.1
--4ybNbZnZ8tziJ7D6
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v36-0002-Add-tests-before-changing-pg_ls_.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v13 1/8] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index fc4d7f0f78..2c6142a0e0 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -21528,7 +21528,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--E0h0CbphJD8hN+Gf
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v13-0002-Add-tests-exercising-pg_ls_tmpdir.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v28 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 0606b6a9aa..aa0dcde886 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27018,7 +27018,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--vk/v8fjDPiDepTtA
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v28-0002-Add-tests-on-pg_ls_dir-before-changing-it.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v34 01/15] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 8a802fb2253..0be4743e3ed 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27618,7 +27618,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.1
--smOfPzt+Qjm5bNGJ
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v34-0002-Add-tests-before-changing-pg_ls_.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v25 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index df29af6371..7cafdb9107 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25897,7 +25897,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--SBikYMzjhZGK9d4p
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v25-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v21 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 959f6a1c2f..7ef8c7a847 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25911,7 +25911,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--Tcb1KvpfnM4LxW2s
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v21-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v35 1/7] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 4001cb2bda5..d01aeec9f88 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27631,6 +27631,10 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
platforms only), file creation time stamp (Windows only), and a flag
indicating if it is a directory.
</para>
+ <para>
+ If filename is a link, this function returns information about the file
+ or directory the link refers to.
+ </para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
--
2.17.1
--olLTNZSltDMg5Vbm
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v35-0002-Add-tests-before-changing-pg_ls_.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v31 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 74d3087a72..d36479d86d 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27410,7 +27410,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--qZVVwWJgpX9Jzs7f
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v31-0002-Add-tests-on-pg_ls_dir-before-changing-it.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v23 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7b1dc264f6..f068260188 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25908,7 +25908,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--mhjHhnbe5PrRcwjY
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v23-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v27 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index c6a45d9e55..977b75a531 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -26990,7 +26990,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--19uQFt6ulqmgNgg1
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v27-0002-Add-tests-on-pg_ls_dir-before-changing-it.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v37 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6e0425cb3dc..d958c3e74ac 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27700,6 +27700,10 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
platforms only), file creation time stamp (Windows only), and a flag
indicating if it is a directory.
</para>
+ <para>
+ If filename is a link, this function returns information about the file
+ or directory the link refers to.
+ </para>
<para>
This function is restricted to superusers by default, but other users
can be granted EXECUTE to run the function.
--
2.25.1
--Pk/CTwBz1VvfPIDp
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v37-0002-Add-tests-before-changing-pg_ls_.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v30 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 6388385edc..7a830f0684 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27004,7 +27004,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--ZwgA9U+XZDXt4+m+
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v30-0002-Add-tests-on-pg_ls_dir-before-changing-it.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v26 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 2707e757ca..806a7b8a9a 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -26559,7 +26559,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--yKkOmjQZXRsvHRX8
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v26-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v33 01/11] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 0ee6974f1c6..d32b414e04f 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -27563,7 +27563,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.1
--9CzcV6dAFIr7O1Ie
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v33-0002-Add-tests-before-changing-pg_ls_.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v16 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 96ea57eedd..9b885102da 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25486,7 +25486,8 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
size, last accessed time stamp, last modified time stamp,
last file status change time stamp (Unix platforms only),
file creation time stamp (Windows only), and a <type>boolean</type>
- indicating if it is a directory. Typical usages include:
+ indicating if it is a directory (or a symbolic link to a directory).
+ Typical usages include:
<programlisting>
SELECT * FROM pg_stat_file('filename');
SELECT (pg_stat_file('filename')).modification;
--
2.17.0
--2FkSFaIQeDFoAt0B
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v16-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* [PATCH v17 01/10] Document historic behavior of links to directories..
@ 2020-03-16 19:12 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Justin Pryzby @ 2020-03-16 19:12 UTC (permalink / raw)
Backpatch to 9.5: pg_stat_file
---
doc/src/sgml/func.sgml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index d9b3598977..e0d1eff6b5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25861,7 +25861,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8');
Returns a record containing the file's size, last access time stamp,
last modification time stamp, last file status change time stamp (Unix
platforms only), file creation time stamp (Windows only), and a flag
- indicating if it is a directory.
+ indicating if it is a directory (or a symbolic link to a directory).
</para>
<para>
This function is restricted to superusers by default, but other users
--
2.17.0
--4LFBTxd4L5NLO6ly
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v17-0002-pg_stat_file-and-pg_ls_dir_-to-use-lstat.patch"
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Bypassing cursors in postgres_fdw to enable parallel plans
@ 2025-01-14 17:33 Robert Haas <[email protected]>
2025-01-17 12:03 ` Re: Bypassing cursors in postgres_fdw to enable parallel plans Rafia Sabih <[email protected]>
0 siblings, 1 reply; 86+ messages in thread
From: Robert Haas @ 2025-01-14 17:33 UTC (permalink / raw)
To: Rafia Sabih <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Mon, Jan 6, 2025 at 3:52 AM Rafia Sabih <[email protected]> wrote:
> Now, to overcome this limitation, I have worked on this idea (suggested by my colleague Bernd Helmle) of bypassing the cursors. The way it works is as follows,
> there is a new GUC introduced postgres_fdw.use_cursor, which when unset uses the mode without the cursor. Now, it uses PQsetChunkedRowsMode in create_cursor when non-cursor mode is used. The size of the chunk is the same as the fetch_size. Now in fetch_more_data, when non-cursor mode is used, pgfdw_get_next_result is used to get the chunk in PGresult and processed in the same manner as before.
>
> Now, the issue comes when there are simultaneous queries, which is the case with the join queries where all the tables involved in the join are at the local server. Because in that case we have multiple cursors opened at the same time and without a cursor mechanism we do not have any information or any other structure to know what to fetch from which query. To handle that case, we have a flag only_query, which is unset as soon as we have assigned the cursor_number >= 2, in postgresBeginForeignScan. Now, in fetch_more data, when we find out that only_query is unset, then we fetch all the data for the query and store it in a Tuplestore. These tuples are then transferred to the fsstate->tuples and then processed as usual.
>
> So yes there is a performance drawback in the case of simultaneous queries, however, the ability to use parallel plans is really an added advantage for the users. Plus, we can keep things as before by this new GUC -- use_cursor, in case we are losing more for some workloads. So, in short I feel hopeful that this could be a good idea and a good time to improve postgres_fdw.
Hi,
I think it might have been nice to credit me in this post, since I
made some relevant suggestions here off-list, in particular the idea
of using a Tuplestore when there are multiple queries running. But I
don't think this patch quite implements what I suggested. Here, you
have a flag only_query which gets set to true at some point in time
and thereafter remains true for the lifetime of a session. That means,
I think, that all future queries will use the tuplestore even though
there might not be multiple queries running any more. which doesn't
seem like what we want. And, actually, this looks like it will be set
as soon as you reach the second query in the same transaction, even if
the two queries don't overlap. I think what you want to do is test
whether, at the point where we would need to issue a new query,
whether an existing query is already running. If not, move that
query's remaining results into a Tuplestore so you can issue the new
query.
I'm not sure what the best way to implement that is, exactly. Perhaps
fsstate->conn_state needs to store some more details about the
connection, but that's just a guess. I don't think a global variable
is what you want. Not only is that session-lifetime, but it applies
globally to every connection to every server. You want to test
something that is specific to one connection to one server, so it
needs to be part of a data structure that is scoped that way.
I think you'll want to figure out a good way to test this patch. I
don't know if we need or can reasonably have automated test cases for
this new functionality, but you at least want to have a good way to do
manual testing, so that you can show that the tuplestore is used in
cases where it's necessary and not otherwise. I'm not yet sure whether
this patch needs automated test cases or whether they can reasonably
be written, but you at least want to have a good procedure for manual
validation so that you can verify that the Tuplestore is used in all
the cases where it needs to be and, hopefully, no others.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 86+ messages in thread
* Re: Bypassing cursors in postgres_fdw to enable parallel plans
2025-01-14 17:33 Re: Bypassing cursors in postgres_fdw to enable parallel plans Robert Haas <[email protected]>
@ 2025-01-17 12:03 ` Rafia Sabih <[email protected]>
0 siblings, 0 replies; 86+ messages in thread
From: Rafia Sabih @ 2025-01-17 12:03 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Tue, 14 Jan 2025 at 18:33, Robert Haas <[email protected]> wrote:
> On Mon, Jan 6, 2025 at 3:52 AM Rafia Sabih <[email protected]>
> wrote:
> > Now, to overcome this limitation, I have worked on this idea (suggested
> by my colleague Bernd Helmle) of bypassing the cursors. The way it works is
> as follows,
> > there is a new GUC introduced postgres_fdw.use_cursor, which when unset
> uses the mode without the cursor. Now, it uses PQsetChunkedRowsMode in
> create_cursor when non-cursor mode is used. The size of the chunk is the
> same as the fetch_size. Now in fetch_more_data, when non-cursor mode is
> used, pgfdw_get_next_result is used to get the chunk in PGresult and
> processed in the same manner as before.
> >
> > Now, the issue comes when there are simultaneous queries, which is the
> case with the join queries where all the tables involved in the join are at
> the local server. Because in that case we have multiple cursors opened at
> the same time and without a cursor mechanism we do not have any information
> or any other structure to know what to fetch from which query. To handle
> that case, we have a flag only_query, which is unset as soon as we have
> assigned the cursor_number >= 2, in postgresBeginForeignScan. Now, in
> fetch_more data, when we find out that only_query is unset, then we fetch
> all the data for the query and store it in a Tuplestore. These tuples are
> then transferred to the fsstate->tuples and then processed as usual.
> >
> > So yes there is a performance drawback in the case of simultaneous
> queries, however, the ability to use parallel plans is really an added
> advantage for the users. Plus, we can keep things as before by this new GUC
> -- use_cursor, in case we are losing more for some workloads. So, in short
> I feel hopeful that this could be a good idea and a good time to improve
> postgres_fdw.
>
> Hi,
>
> I think it might have been nice to credit me in this post, since I
> made some relevant suggestions here off-list, in particular the idea
> of using a Tuplestore when there are multiple queries running. But I
> don't think this patch quite implements what I suggested. Here, you
> have a flag only_query which gets set to true at some point in time
> and thereafter remains true for the lifetime of a session. That means,
> I think, that all future queries will use the tuplestore even though
> there might not be multiple queries running any more. which doesn't
> seem like what we want. And, actually, this looks like it will be set
> as soon as you reach the second query in the same transaction, even if
> the two queries don't overlap. I think what you want to do is test
> whether, at the point where we would need to issue a new query,
> whether an existing query is already running. If not, move that
> query's remaining results into a Tuplestore so you can issue the new
> query.
>
> I'm not sure what the best way to implement that is, exactly. Perhaps
> fsstate->conn_state needs to store some more details about the
> connection, but that's just a guess. I don't think a global variable
> is what you want. Not only is that session-lifetime, but it applies
> globally to every connection to every server. You want to test
> something that is specific to one connection to one server, so it
> needs to be part of a data structure that is scoped that way.
>
> I think you'll want to figure out a good way to test this patch. I
> don't know if we need or can reasonably have automated test cases for
> this new functionality, but you at least want to have a good way to do
> manual testing, so that you can show that the tuplestore is used in
> cases where it's necessary and not otherwise. I'm not yet sure whether
> this patch needs automated test cases or whether they can reasonably
> be written, but you at least want to have a good procedure for manual
> validation so that you can verify that the Tuplestore is used in all
> the cases where it needs to be and, hopefully, no others.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>
Indeed you are right.
Firstly, accept my apologies for not mentioning you in credits for this
work. Thanks a lot for your efforts, discussions with you were helpful in
shaping this patch and bringing it to this level.
Next, yes the last version was using tuplestore for queries within the same
transaction after the second query. To overcome this, I came across this
method to identify if there is any other simultaneous query running with
the current query; now there is an int variable num_queries which is
incremented at every call of postgresBeginForeignScan and decremented at
every call of postgresEndForeignScan. This way, if there are simultaneous
queries running we get the value of num_queries greater than 1. Now, we
check the value of num_queries and use tuplestore only when num_queries is
greater than 1. So, basically the understanding here is that if
postgresBeginForeignScan is called and before the call of
postgresEndForeignScan if another call to postgresBeginForeignScan is made,
then these are simultaneous queries.
I couldn't really find any automated method of testing this, but did it
manually by debugging and/or printing log statements in
postgresBeginForeingScan, postgresEndForeignScan, and fetch_more_data to
confirm indeed there are simultaneous queries, and only they are using
tuplestore. So, the case of simultaneous queries I found was the join
query. Because, there it creates the cursor for one side of the join and
retrieves the first tuples for it and then creates the next cursor for the
other side of join and keeps on reading all the tuples for that query and
then it comes back to first cursor and retrieves all the tuples for that
one. Similarly, it works for the queries with n number of tables in join,
basically what I found is if there are n tables in the join there will be n
open cursors at a time and then they will be closed one by one in the
descending order of the cursor_number. I will think more on the topic of
testing this and will try to come up with a script (in the best case) to
confirm the use of tuplestore in required cases only, or atleast with a set
of steps to do so.
For the regular testing of this feature, I think a regression test with
this new GUC postgres_fdw.use_cursor set to false and running all the
existing tests of postgres_fdw should suffice. What do you think? However,
at the moment when non-cursor mode is used, regression tests are failing.
Some queries require order by because order is changed in non-cursor mode,
but some require more complex changes, I am working on them.
In this version of the patch I have added only the changes mentioned above
and not the regression test modification.
--
Regards,
Rafia Sabih
CYBERTEC PostgreSQL International GmbH
Attachments:
[application/octet-stream] v2-0001-Add-a-fetch-mechanism-without-cursors.patch (14.7K, ../../CA+FpmFerinRL9LRY9B2FQzQc3Ba1qtj=vH1e2tVR6vBj1TaSYA@mail.gmail.com/3-v2-0001-Add-a-fetch-mechanism-without-cursors.patch)
download | inline diff:
From 096a5e03f4f8ebbe5e10ef9373f83dcd5edc1b78 Mon Sep 17 00:00:00 2001
From: Rafia Sabih <[email protected]>
Date: Fri, 17 Jan 2025 12:50:19 +0100
Subject: [PATCH] Add a fetch mechanism without cursors
This adds a GUC to enable/ disable cursor mode in postgres_fdw.
The GUC is called postgres_fdw.use_cursor. When it is set, everything
works as it is now. However, there is a limitation to the current
mechanism, it is unable to use parallel plans at local side because
of the use of cursors. Now, if a user wants to overcome this, then
one can unset the abovementioned GUC. In non-cursor mode cursors are
not used and hence the parallel plans can be used at the local side.
In non-cursor mode fetch_size is used to as is.
A caveat with the non-cursor mode is that when simultaneous queries are
fired at the local side, i.e. more than one cursor is opened at a time,
then we use Tuplestore, so there might be some memory related performance
degradation only in those cases.
Original idea: Bernd Helmle
Key suggestions: Robert Haas
---
contrib/postgres_fdw/connection.c | 7 +
contrib/postgres_fdw/option.c | 17 +++
contrib/postgres_fdw/postgres_fdw.c | 227 +++++++++++++++++++++-------
contrib/postgres_fdw/postgres_fdw.h | 2 +
4 files changed, 197 insertions(+), 56 deletions(-)
diff --git a/contrib/postgres_fdw/connection.c b/contrib/postgres_fdw/connection.c
index 202e7e583b3..acd6bfe9b4b 100644
--- a/contrib/postgres_fdw/connection.c
+++ b/contrib/postgres_fdw/connection.c
@@ -877,6 +877,13 @@ pgfdw_get_result(PGconn *conn)
return libpqsrv_get_result_last(conn, pgfdw_we_get_result);
}
+PGresult *
+pgfdw_get_next_result(PGconn *conn)
+{
+ return libpqsrv_get_result(conn, pgfdw_we_get_result);
+}
+
+
/*
* Report an error we got from the remote server.
*
diff --git a/contrib/postgres_fdw/option.c b/contrib/postgres_fdw/option.c
index 12aed4054fa..bc3d5c46286 100644
--- a/contrib/postgres_fdw/option.c
+++ b/contrib/postgres_fdw/option.c
@@ -49,6 +49,7 @@ static PQconninfoOption *libpq_options;
* GUC parameters
*/
char *pgfdw_application_name = NULL;
+bool pgfdw_use_cursor = true;
/*
* Helper functions
@@ -585,5 +586,21 @@ _PG_init(void)
NULL,
NULL);
+ /*
+ * If use_cursor is set to false, then the new way of fetching is used, which allows for the
+ * use of parallel plans at the local side. In the cursor mode, parallel plans could not be
+ * used.
+ */
+ DefineCustomBoolVariable("postgres_fdw.use_cursor",
+ "If set uses the cursor, otherwise fetches without cursor",
+ NULL,
+ &pgfdw_use_cursor,
+ true,
+ PGC_USERSET,
+ 0,
+ NULL,
+ NULL,
+ NULL);
+
MarkGUCPrefixReserved("postgres_fdw");
}
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index b92e2a0fc9f..11097958625 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -21,6 +21,7 @@
#include "commands/defrem.h"
#include "commands/explain.h"
#include "executor/execAsync.h"
+#include "executor/executor.h"
#include "foreign/fdwapi.h"
#include "funcapi.h"
#include "miscadmin.h"
@@ -542,6 +543,7 @@ static void merge_fdw_options(PgFdwRelationInfo *fpinfo,
const PgFdwRelationInfo *fpinfo_i);
static int get_batch_size_option(Relation rel);
+static int num_queries = 0; /* Only to be used in the non cursor mode */
/*
* Foreign-data wrapper handler function: return a struct with pointers
@@ -1544,6 +1546,10 @@ postgresBeginForeignScan(ForeignScanState *node, int eflags)
/* Get private info created by planner functions. */
fsstate->query = strVal(list_nth(fsplan->fdw_private,
FdwScanPrivateSelectSql));
+
+ /* We need to know if there are simultaneous queries running. */
+ num_queries++;
+
fsstate->retrieved_attrs = (List *) list_nth(fsplan->fdw_private,
FdwScanPrivateRetrievedAttrs);
fsstate->fetch_size = intVal(list_nth(fsplan->fdw_private,
@@ -1673,7 +1679,7 @@ postgresReScanForeignScan(ForeignScanState *node)
* case. If we've only fetched zero or one batch, we needn't even rewind
* the cursor, just rescan what we have.
*/
- if (node->ss.ps.chgParam != NULL)
+ if (node->ss.ps.chgParam != NULL && pgfdw_use_cursor)
{
fsstate->cursor_exists = false;
snprintf(sql, sizeof(sql), "CLOSE c%u",
@@ -1684,7 +1690,7 @@ postgresReScanForeignScan(ForeignScanState *node)
if (PQserverVersion(fsstate->conn) < 150000)
snprintf(sql, sizeof(sql), "MOVE BACKWARD ALL IN c%u",
fsstate->cursor_number);
- else
+ else if (pgfdw_use_cursor)
{
fsstate->cursor_exists = false;
snprintf(sql, sizeof(sql), "CLOSE c%u",
@@ -1737,6 +1743,9 @@ postgresEndForeignScan(ForeignScanState *node)
ReleaseConnection(fsstate->conn);
fsstate->conn = NULL;
+ /* To know if there are simulataneous queries running. */
+ num_queries--;
+
/* MemoryContexts will be deleted automatically. */
}
@@ -3733,7 +3742,7 @@ create_cursor(ForeignScanState *node)
const char **values = fsstate->param_values;
PGconn *conn = fsstate->conn;
StringInfoData buf;
- PGresult *res;
+ PGresult *res = NULL;
/* First, process a pending asynchronous request, if any. */
if (fsstate->conn_state->pendingAreq)
@@ -3758,36 +3767,53 @@ create_cursor(ForeignScanState *node)
MemoryContextSwitchTo(oldcontext);
}
- /* Construct the DECLARE CURSOR command */
initStringInfo(&buf);
- appendStringInfo(&buf, "DECLARE c%u CURSOR FOR\n%s",
- fsstate->cursor_number, fsstate->query);
- /*
- * Notice that we pass NULL for paramTypes, thus forcing the remote server
- * to infer types for all parameters. Since we explicitly cast every
- * parameter (see deparse.c), the "inference" is trivial and will produce
- * the desired result. This allows us to avoid assuming that the remote
- * server has the same OIDs we do for the parameters' types.
- */
- if (!PQsendQueryParams(conn, buf.data, numParams,
- NULL, values, NULL, NULL, 0))
- pgfdw_report_error(ERROR, NULL, conn, false, buf.data);
+ if (pgfdw_use_cursor)
+ {
+ /* Construct the DECLARE CURSOR command */
+ appendStringInfo(&buf, "DECLARE c%u CURSOR FOR\n%s",
+ fsstate->cursor_number, fsstate->query);
+
+ /*
+ * Notice that we pass NULL for paramTypes, thus forcing the remote server
+ * to infer types for all parameters. Since we explicitly cast every
+ * parameter (see deparse.c), the "inference" is trivial and will produce
+ * the desired result. This allows us to avoid assuming that the remote
+ * server has the same OIDs we do for the parameters' types.
+ */
+ if (!PQsendQueryParams(conn, buf.data, numParams,
+ NULL, values, NULL, NULL, 0))
+ pgfdw_report_error(ERROR, NULL, conn, false, buf.data);
+
+ /*
+ * Get the result, and check for success.
+ *
+ * We don't use a PG_TRY block here, so be careful not to throw error
+ * without releasing the PGresult.
+ */
+ res = pgfdw_get_result(conn);
+ if (PQresultStatus(res) != PGRES_COMMAND_OK)
+ pgfdw_report_error(ERROR, res, conn, true, fsstate->query);
+ }
+ else
+ {
+ /* Fetch without cursors */
+ appendStringInfo(&buf, "%s", fsstate->query);
+
+ if (!PQsendQueryParams(conn, buf.data, numParams,
+ NULL, values, NULL, NULL, 0))
+ pgfdw_report_error(ERROR, NULL, conn, false, buf.data);
+
+ /* Call for Chunked rows mode with same size of chunk as the fetch size */
+ if (!PQsetChunkedRowsMode(conn, fsstate->fetch_size))
+ pgfdw_report_error(ERROR, NULL, conn, false, buf.data);
+ }
- /*
- * Get the result, and check for success.
- *
- * We don't use a PG_TRY block here, so be careful not to throw error
- * without releasing the PGresult.
- */
- res = pgfdw_get_result(conn);
- if (PQresultStatus(res) != PGRES_COMMAND_OK)
- pgfdw_report_error(ERROR, res, conn, true, fsstate->query);
PQclear(res);
/* Mark the cursor as created, and show no tuples have been retrieved */
- fsstate->cursor_exists = true;
- fsstate->tuples = NULL;
+ fsstate->cursor_exists = true; // We need this even for non-cursor mode.
fsstate->num_tuples = 0;
fsstate->next_tuple = 0;
fsstate->fetch_ct_2 = 0;
@@ -3806,6 +3832,7 @@ fetch_more_data(ForeignScanState *node)
PgFdwScanState *fsstate = (PgFdwScanState *) node->fdw_state;
PGresult *volatile res = NULL;
MemoryContext oldcontext;
+ bool already_done = false;
/*
* We'll store the tuples in the batch_cxt. First, flush the previous
@@ -3820,7 +3847,7 @@ fetch_more_data(ForeignScanState *node)
{
PGconn *conn = fsstate->conn;
int numrows;
- int i;
+ int i = 0;
if (fsstate->async_capable)
{
@@ -3838,7 +3865,7 @@ fetch_more_data(ForeignScanState *node)
/* Reset per-connection state */
fsstate->conn_state->pendingAreq = NULL;
}
- else
+ else if (pgfdw_use_cursor)
{
char sql[64];
@@ -3851,32 +3878,113 @@ fetch_more_data(ForeignScanState *node)
if (PQresultStatus(res) != PGRES_TUPLES_OK)
pgfdw_report_error(ERROR, res, conn, false, fsstate->query);
}
+ else
+ {
+ /* Non-cursor mode uses PQSetChunkedRowsMode during create_cursor, so just get the result here. */
+ res = pgfdw_get_next_result(conn);
- /* Convert the data into HeapTuples */
- numrows = PQntuples(res);
- fsstate->tuples = (HeapTuple *) palloc0(numrows * sizeof(HeapTuple));
- fsstate->num_tuples = numrows;
- fsstate->next_tuple = 0;
+ if (res == NULL)
+ break;
- for (i = 0; i < numrows; i++)
+ else if (PQresultStatus(res) == PGRES_FATAL_ERROR)
+ pgfdw_report_error(ERROR, res, conn, false, fsstate->query);
+ else if (PQresultStatus(res) == PGRES_TUPLES_CHUNK)
+ {
+ int total = 0;
+ if (num_queries > 1)
+ {
+ /*
+ * When this is not the only query running, we extract all the tuples
+ * in one go and store them in tuplestore.
+ * Since it is using PQSetChunkedRowsMode, we get only the fsstate->fetch_size
+ * tuples in one run, so keep on executing till we get NULL in PGresult.
+ */
+ Tuplestorestate *tuplestore = tuplestore_begin_heap(false, true, work_mem);
+ TupleTableSlot *slot = MakeSingleTupleTableSlot(fsstate->tupdesc, &TTSOpsMinimalTuple);
+ HeapTuple temp_tuple = (HeapTuple) palloc0(sizeof(HeapTuple));
+
+ i = 0;
+ for (;;)
+ {
+ CHECK_FOR_INTERRUPTS();
+ numrows = PQntuples(res);
+
+ /* Convert the data into HeapTuples */
+ Assert(IsA(node->ss.ps.plan, ForeignScan));
+ for (i = 0; i < numrows; i++)
+ {
+ temp_tuple = make_tuple_from_result_row(res, i,
+ fsstate->rel,
+ fsstate->attinmeta,
+ fsstate->retrieved_attrs,
+ node,
+ fsstate->temp_cxt);
+ tuplestore_puttuple(tuplestore, temp_tuple);
+ total++;
+ }
+ res = pgfdw_get_next_result(conn);
+
+ if (res == NULL)
+ break;
+
+ else if (PQresultStatus(res) == PGRES_TUPLES_OK)
+ {
+ while (res!= NULL)
+ res = pgfdw_get_next_result(conn);
+ break;
+ }
+ else if (PQresultStatus(res) == PGRES_FATAL_ERROR)
+ pgfdw_report_error(ERROR, res, conn, false, fsstate->query);
+ }
+ if (total > 0)
+ {
+ already_done = true;
+ numrows = total;
+ fsstate->tuples = (HeapTuple *) palloc0(numrows * sizeof(HeapTuple));
+ fsstate->num_tuples = numrows;
+ fsstate->next_tuple = 0;
+ for (i = 0; i < numrows; i++)
+ {
+ while (tuplestore_gettupleslot(tuplestore, true, true, slot))
+ fsstate->tuples[i++] = ExecFetchSlotHeapTuple(slot, true, NULL);
+ }
+ }
+ /* EOF is reached because when we are storing all tuples to the tuplestore. */
+ fsstate->eof_reached = true;
+ pfree(temp_tuple);
+ ExecDropSingleTupleTableSlot(slot);
+ tuplestore_end(tuplestore);
+ }
+ }
+ }
+ if (!already_done)
{
- Assert(IsA(node->ss.ps.plan, ForeignScan));
-
- fsstate->tuples[i] =
- make_tuple_from_result_row(res, i,
- fsstate->rel,
- fsstate->attinmeta,
- fsstate->retrieved_attrs,
- node,
- fsstate->temp_cxt);
+ /* Convert the data into HeapTuples */
+ numrows = PQntuples(res);
+ fsstate->tuples = (HeapTuple *) palloc0(numrows * sizeof(HeapTuple));
+ fsstate->num_tuples = numrows;
+ fsstate->next_tuple = 0;
+
+ for (i = 0; i < numrows; i++)
+ {
+ Assert(IsA(node->ss.ps.plan, ForeignScan));
+
+ fsstate->tuples[i] =
+ make_tuple_from_result_row(res, i,
+ fsstate->rel,
+ fsstate->attinmeta,
+ fsstate->retrieved_attrs,
+ node,
+ fsstate->temp_cxt);
+ }
+
+ /* Must be EOF if we didn't get as many tuples as we asked for. */
+ fsstate->eof_reached = (numrows < fsstate->fetch_size);
}
/* Update fetch_ct_2 */
if (fsstate->fetch_ct_2 < 2)
fsstate->fetch_ct_2++;
-
- /* Must be EOF if we didn't get as many tuples as we asked for. */
- fsstate->eof_reached = (numrows < fsstate->fetch_size);
}
PG_FINALLY();
{
@@ -3955,16 +4063,23 @@ close_cursor(PGconn *conn, unsigned int cursor_number,
char sql[64];
PGresult *res;
- snprintf(sql, sizeof(sql), "CLOSE c%u", cursor_number);
+ if (pgfdw_use_cursor)
+ {
+ snprintf(sql, sizeof(sql), "CLOSE c%u", cursor_number);
- /*
- * We don't use a PG_TRY block here, so be careful not to throw error
- * without releasing the PGresult.
- */
- res = pgfdw_exec_query(conn, sql, conn_state);
- if (PQresultStatus(res) != PGRES_COMMAND_OK)
- pgfdw_report_error(ERROR, res, conn, true, sql);
- PQclear(res);
+ /*
+ * We don't use a PG_TRY block here, so be careful not to throw error
+ * without releasing the PGresult.
+ */
+ res = pgfdw_exec_query(conn, sql, conn_state);
+ if (PQresultStatus(res) != PGRES_COMMAND_OK)
+ pgfdw_report_error(ERROR, res, conn, true, sql);
+ PQclear(res);
+ }
+ else
+ {
+ while (pgfdw_get_result(conn) != NULL) {}
+ }
}
/*
diff --git a/contrib/postgres_fdw/postgres_fdw.h b/contrib/postgres_fdw/postgres_fdw.h
index 81358f3bde7..f52900b30cd 100644
--- a/contrib/postgres_fdw/postgres_fdw.h
+++ b/contrib/postgres_fdw/postgres_fdw.h
@@ -164,6 +164,7 @@ extern unsigned int GetCursorNumber(PGconn *conn);
extern unsigned int GetPrepStmtNumber(PGconn *conn);
extern void do_sql_command(PGconn *conn, const char *sql);
extern PGresult *pgfdw_get_result(PGconn *conn);
+extern PGresult *pgfdw_get_next_result(PGconn *conn);
extern PGresult *pgfdw_exec_query(PGconn *conn, const char *query,
PgFdwConnState *state);
extern void pgfdw_report_error(int elevel, PGresult *res, PGconn *conn,
@@ -177,6 +178,7 @@ extern List *ExtractExtensionList(const char *extensionsString,
bool warnOnMissing);
extern char *process_pgfdw_appname(const char *appname);
extern char *pgfdw_application_name;
+extern bool pgfdw_use_cursor;
/* in deparse.c */
extern void classifyConditions(PlannerInfo *root,
--
2.39.5 (Apple Git-154)
^ permalink raw reply [nested|flat] 86+ messages in thread
end of thread, other threads:[~2025-01-17 12:03 UTC | newest]
Thread overview: 86+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-12-08 21:34 Time to drop old-style (V0) functions? Andres Freund <[email protected]>
2016-12-08 21:57 ` Stephen Frost <[email protected]>
2016-12-08 22:38 ` Tom Lane <[email protected]>
2016-12-08 22:53 ` Andres Freund <[email protected]>
2016-12-08 23:00 ` Andres Freund <[email protected]>
2016-12-08 23:03 ` Tom Lane <[email protected]>
2016-12-08 23:08 ` Andres Freund <[email protected]>
2016-12-09 12:52 ` Robert Haas <[email protected]>
2016-12-19 20:13 ` Peter Eisentraut <[email protected]>
2016-12-19 20:25 ` Robert Haas <[email protected]>
2016-12-20 08:11 ` Andres Freund <[email protected]>
2016-12-20 08:59 ` Pavel Stehule <[email protected]>
2016-12-20 09:14 ` Andres Freund <[email protected]>
2016-12-20 09:28 ` Andres Freund <[email protected]>
2016-12-20 09:44 ` Pavel Stehule <[email protected]>
2016-12-20 09:58 ` Andres Freund <[email protected]>
2016-12-20 13:15 ` Robert Haas <[email protected]>
2016-12-20 13:21 ` Andres Freund <[email protected]>
2016-12-20 13:35 ` Robert Haas <[email protected]>
2016-12-20 13:44 ` Andres Freund <[email protected]>
2016-12-20 14:12 ` Robert Haas <[email protected]>
2016-12-20 15:04 ` Tom Lane <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v18 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v32 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v24 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v19 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v12 02/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v20 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v14 1/8] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v22 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v36 1/7] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v13 1/8] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v28 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v34 01/15] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v25 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v21 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v35 1/7] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v31 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v23 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v27 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v37 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v30 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v26 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v33 01/11] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v16 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2020-03-16 19:12 [PATCH v17 01/10] Document historic behavior of links to directories.. Justin Pryzby <[email protected]>
2025-01-14 17:33 Re: Bypassing cursors in postgres_fdw to enable parallel plans Robert Haas <[email protected]>
2025-01-17 12:03 ` Re: Bypassing cursors in postgres_fdw to enable parallel plans Rafia Sabih <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox