public inbox for [email protected]help / color / mirror / Atom feed
Time 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]> 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:57 Stephen Frost <[email protected]> parent: Andres Freund <[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 22:38 Tom Lane <[email protected]> parent: 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 22:53 Andres Freund <[email protected]> parent: Tom Lane <[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 23:00 Andres Freund <[email protected]> parent: 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 23:03 Tom Lane <[email protected]> parent: 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 23:08 Andres Freund <[email protected]> parent: Tom Lane <[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-09 12:52 Robert Haas <[email protected]> parent: Andres Freund <[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-19 20:13 Peter Eisentraut <[email protected]> parent: 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-19 20:25 Robert Haas <[email protected]> parent: Peter Eisentraut <[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-20 08:11 Andres Freund <[email protected]> parent: 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-20 08:59 Pavel Stehule <[email protected]> parent: 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-20 09:14 Andres Freund <[email protected]> parent: Pavel Stehule <[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-20 09:28 Andres Freund <[email protected]> parent: Andres Freund <[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-20 09:44 Pavel Stehule <[email protected]> parent: 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-20 09:58 Andres Freund <[email protected]> parent: Pavel Stehule <[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-20 13:15 Robert Haas <[email protected]> parent: 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-20 13:21 Andres Freund <[email protected]> parent: 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-20 13:35 Robert Haas <[email protected]> parent: 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-20 13:44 Andres Freund <[email protected]> parent: 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-20 14:12 Robert Haas <[email protected]> parent: Andres Freund <[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-20 15:04 Tom Lane <[email protected]> parent: Robert Haas <[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
* Re: Bypassing cursors in postgres_fdw to enable parallel plans @ 2025-01-14 17:33 Robert Haas <[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-17 12:03 Rafia Sabih <[email protected]> parent: Robert Haas <[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 v36 1/7] 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 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 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 v14 1/8] 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 v23 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 v18 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 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 v26 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 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 v17 01/10] 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 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 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 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 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 v25 01/11] 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 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 v13 1/8] 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 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 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 v37 01/11] 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 v16 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 v35 1/7] 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 v24 01/11] 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