Allow users of simplehash.h to perform direct deletions
Previously simplehash.h only exposed a method to perform a hash table
delete using the hash table key. This meant that the delete function had
to perform a hash lookup in order to find the entry to delete. Here we
add a new function so that
Add upper boundary tests for timestamp and timestamptz types
The existing regression tests only tested the lower boundary of the
range supported by the timestamp and timestamptz types because "The
upper boundary differs between integer and float timestamps, so no
check". Since this is obsolete, a
Add a xid argument to the filter_prepare callback for output plugins.
Along with gid, this provides a different way to identify the transaction.
The users that use xid in some way to prepare the transactions can use it
to filter prepare transactions. The later commands COMMIT PREPARED or
ROLLBACK
Update obsolete comment.
Back-patch to all supported branches.
Author: Etsuro Fujita
Discussion:
https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/72ceeab9c5ad0a78d1e
Update obsolete comment.
Back-patch to all supported branches.
Author: Etsuro Fujita
Discussion:
https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/bc2797ebb14bae663da1ee7845
Update obsolete comment.
Back-patch to all supported branches.
Author: Etsuro Fujita
Discussion:
https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/c8d7ea5241308682488
Update obsolete comment.
Back-patch to all supported branches.
Author: Etsuro Fujita
Discussion:
https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/cf8384ac8333dea9742
Update obsolete comment.
Back-patch to all supported branches.
Author: Etsuro Fujita
Discussion:
https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com
Branch
--
REL_13_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/78f8b0965a224e650b4
Update obsolete comment.
Back-patch to all supported branches.
Author: Etsuro Fujita
Discussion:
https://postgr.es/m/CAPmGK17DwzaSf%2BB71dhL2apXdtG-OmD6u2AL9Cq2ZmAR0%2BzapQ%40mail.gmail.com
Branch
--
REL_11_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/1b4dd6aaff91d9eb710
On Tue, Mar 30, 2021 at 12:43 AM Robert Haas wrote:
>
> On Mon, Mar 29, 2021 at 6:01 AM Amit Kapila wrote:
> > A naive question about this scheme: What if the worker that acquires
> > the XID writes some row and another worker reads that row before it
> > gets to see the XID information? I think
On Tue, Mar 30, 2021 at 12:59 AM Robert Haas wrote:
>
> On Thu, Mar 25, 2021 at 11:59 PM Amit Kapila wrote:
> > But won't some form of lock is required for each rel entry in the hash
> > table as well for the same duration as is required for rel? Because
> > otherwise, while we are processing the
psql: call clearerr() just before printing
We were never doing clearerr() on the output stream, which results in a
message being printed after each result once an EOF is seen:
could not print result table: Success
This message was added by commit b03436994bcc (in the pg13 era); before
that, the
psql: call clearerr() just before printing
We were never doing clearerr() on the output stream, which results in a
message being printed after each result once an EOF is seen:
could not print result table: Success
This message was added by commit b03436994bcc (in the pg13 era); before
that, the
Adjust design of per-worker parallel seqscan data struct
The design of the data structures which allow storage of the per-worker
memory during parallel seq scans were not ideal. The work done in
56788d215 required an additional data structure to allow workers to
remember the range of pages that ha
Allow matching the DN of a client certificate for authentication
Currently we only recognize the Common Name (CN) of a certificate's
subject to be matched against the user name. Thus certificates with
subjects '/OU=eng/CN=fred' and '/OU=sales/CN=fred' will have the same
connection rights. This pat
On Thu, Mar 25, 2021 at 11:59 PM Amit Kapila wrote:
> But won't some form of lock is required for each rel entry in the hash
> table as well for the same duration as is required for rel? Because
> otherwise, while we are processing the statement or other relations in
> the query, something paralle
On Mon, Mar 29, 2021 at 6:01 AM Amit Kapila wrote:
> A naive question about this scheme: What if the worker that acquires
> the XID writes some row and another worker reads that row before it
> gets to see the XID information? I think it won't treat such a row is
> written by its own transaction.
Clean up date_part tests a bit
Some tests for timestamp and timestamptz were in the date.sql test
file. Move them to their appropriate files, or drop tests cases that
were already present there.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/efcc7572f532ea564fedc6
Add unistr function
This allows decoding a string with Unicode escape sequences. It is
similar to Unicode escape strings, but offers some more flexibility.
Author: Pavel Stehule
Reviewed-by: Asif Rehman
Discussion:
https://www.postgresql.org/message-id/flat/cafj8pra5gnkt+gdvwbvrh2ep451h_mybt+
On Wed, Mar 24, 2021 at 6:18 PM Robert Haas wrote:
>
> On Wed, Mar 24, 2021 at 12:48 AM Andres Freund wrote:
>
> > Although this specific hack doesn't seem too terrible to me. If you
> > execute a parallel insert the likelihood to end up not needing an xid is
> > pretty low. Implementing it concu
20 matches
Mail list logo
