pgsql: Doc: caution against misuse of 'now' and related datetime litera
Doc: caution against misuse of 'now' and related datetime literals. Section 8.5.1.4, which defines these literals, made only a vague reference to the fact that they might be evaluated too soon to be safe in non-interactive contexts. Provide a more explicit caution against misuse. Also, generalize the wording in the related tip in section 9.9.4: while it clearly described this problem, it implied (or really, stated outright) that the problem only applies to table DEFAULT clauses. Per gripe from Tijs van Dam. Back-patch to all supported branches. Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3753e2720a9691d38aa85fe1e641ba55703e2a6f Modified Files -- doc/src/sgml/datatype.sgml | 20 +--- doc/src/sgml/func.sgml | 8 +--- 2 files changed, 22 insertions(+), 6 deletions(-)
pgsql: Doc: caution against misuse of 'now' and related datetime litera
Doc: caution against misuse of 'now' and related datetime literals. Section 8.5.1.4, which defines these literals, made only a vague reference to the fact that they might be evaluated too soon to be safe in non-interactive contexts. Provide a more explicit caution against misuse. Also, generalize the wording in the related tip in section 9.9.4: while it clearly described this problem, it implied (or really, stated outright) that the problem only applies to table DEFAULT clauses. Per gripe from Tijs van Dam. Back-patch to all supported branches. Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d317fd7570ca69553eef9a9ec1825967c2680927 Modified Files -- doc/src/sgml/datatype.sgml | 20 +--- doc/src/sgml/func.sgml | 8 +--- 2 files changed, 22 insertions(+), 6 deletions(-)
pgsql: Doc: caution against misuse of 'now' and related datetime litera
Doc: caution against misuse of 'now' and related datetime literals. Section 8.5.1.4, which defines these literals, made only a vague reference to the fact that they might be evaluated too soon to be safe in non-interactive contexts. Provide a more explicit caution against misuse. Also, generalize the wording in the related tip in section 9.9.4: while it clearly described this problem, it implied (or really, stated outright) that the problem only applies to table DEFAULT clauses. Per gripe from Tijs van Dam. Back-patch to all supported branches. Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3f898c986e39ffe88fb6bbedd71a0b7a0e4d1bc7 Modified Files -- doc/src/sgml/datatype.sgml | 20 +--- doc/src/sgml/func.sgml | 8 +--- 2 files changed, 22 insertions(+), 6 deletions(-)
pgsql: Doc: caution against misuse of 'now' and related datetime litera
Doc: caution against misuse of 'now' and related datetime literals. Section 8.5.1.4, which defines these literals, made only a vague reference to the fact that they might be evaluated too soon to be safe in non-interactive contexts. Provide a more explicit caution against misuse. Also, generalize the wording in the related tip in section 9.9.4: while it clearly described this problem, it implied (or really, stated outright) that the problem only applies to table DEFAULT clauses. Per gripe from Tijs van Dam. Back-patch to all supported branches. Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/133d06f7bbf5fcf24f1fdbf0e013e30446f61abd Modified Files -- doc/src/sgml/datatype.sgml | 20 +--- doc/src/sgml/func.sgml | 8 +--- 2 files changed, 22 insertions(+), 6 deletions(-)
pgsql: Doc: caution against misuse of 'now' and related datetime litera
Doc: caution against misuse of 'now' and related datetime literals. Section 8.5.1.4, which defines these literals, made only a vague reference to the fact that they might be evaluated too soon to be safe in non-interactive contexts. Provide a more explicit caution against misuse. Also, generalize the wording in the related tip in section 9.9.4: while it clearly described this problem, it implied (or really, stated outright) that the problem only applies to table DEFAULT clauses. Per gripe from Tijs van Dam. Back-patch to all supported branches. Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d74ed6fe6e9314d47f0a995227df896b28cea822 Modified Files -- doc/src/sgml/datatype.sgml | 20 +--- doc/src/sgml/func.sgml | 8 +--- 2 files changed, 22 insertions(+), 6 deletions(-)
pgsql: Doc: caution against misuse of 'now' and related datetime litera
Doc: caution against misuse of 'now' and related datetime literals. Section 8.5.1.4, which defines these literals, made only a vague reference to the fact that they might be evaluated too soon to be safe in non-interactive contexts. Provide a more explicit caution against misuse. Also, generalize the wording in the related tip in section 9.9.4: while it clearly described this problem, it implied (or really, stated outright) that the problem only applies to table DEFAULT clauses. Per gripe from Tijs van Dam. Back-patch to all supported branches. Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c1a3188baeda2414a7a7453917d73aa5db511067 Modified Files -- doc/src/sgml/datatype.sgml | 20 +--- doc/src/sgml/func.sgml | 8 +--- 2 files changed, 22 insertions(+), 6 deletions(-)
pgsql: Doc: caution against misuse of 'now' and related datetime litera
Doc: caution against misuse of 'now' and related datetime literals. Section 8.5.1.4, which defines these literals, made only a vague reference to the fact that they might be evaluated too soon to be safe in non-interactive contexts. Provide a more explicit caution against misuse. Also, generalize the wording in the related tip in section 9.9.4: while it clearly described this problem, it implied (or really, stated outright) that the problem only applies to table DEFAULT clauses. Per gripe from Tijs van Dam. Back-patch to all supported branches. Discussion: https://postgr.es/m/c2LuRv9BiRT3bqIo5mMQiVraEXey_25B4vUn0kDqVqilwOEu_iVF1tbtvLnyQK7yDG3PFaz_GxLLPil2SDkj1MCObNRVaac-7j1dVdFERk8=@thalex.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/540849814cdc22ea025777d374ff6705b4d64a0f Modified Files -- doc/src/sgml/datatype.sgml | 20 +--- doc/src/sgml/func.sgml | 8 +--- 2 files changed, 22 insertions(+), 6 deletions(-)
pgsql: In libpq for Windows, call WSAStartup once and WSACleanup not at
In libpq for Windows, call WSAStartup once and WSACleanup not at all. The Windows documentation insists that every WSAStartup call should have a matching WSACleanup call. However, if that ever had actual relevance, it wasn't in this century. Every remotely-modern Windows kernel is capable of cleaning up when a process exits without doing that, and must be so to avoid resource leaks in case of a process crash. Moreover, Postgres backends have done WSAStartup without WSACleanup since commit 4cdf51e64 in 2004, and we've never seen any indication of a problem with that. libpq's habit of doing WSAStartup during connection start and WSACleanup during shutdown is also rather inefficient, since a series of non-overlapping connection requests leads to repeated, quite expensive DLL unload/reload cycles. We document a workaround for that (having the application call WSAStartup for itself), but that's just a kluge. It's also worth noting that it's far from uncommon for applications to exit without doing PQfinish, and we've not heard reports of trouble from that either. However, the real reason for acting on this is that recent experiments by Alexander Lakhin suggest that calling WSACleanup during PQfinish might be triggering the symptom we occasionally see that a process using libpq fails to emit expected stdio output. Therefore, let's change libpq so that it calls WSAStartup only once per process, during the first connection attempt, and never calls WSACleanup at all. While at it, get rid of the only other WSACleanup call in our code tree, in pg_dump/parallel.c; that presumably is equally useless. If this proves to suppress the fairly-common ecpg test failures we see on Windows, I'll back-patch, but for now let's just do it in HEAD and see what happens. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7d00a6b2de8ab1e95e052663064defb0bc3022f6 Modified Files -- doc/src/sgml/libpq.sgml | 15 --- src/bin/pg_dump/parallel.c| 16 +--- src/interfaces/libpq/fe-connect.c | 31 +-- 3 files changed, 18 insertions(+), 44 deletions(-)
