On Mon, Jul 1, 2019 at 10:05 PM Alvaro Herrera wrote:
>
> Do we have an actual patch here?
>
We have a patch, but it needs some more work like finding similar
places and change all of them at the same time and then change the
tests to adapt the same.
--
With Regards,
Amit Kapila.
EnterpriseDB:
On 2019-Jul-05, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 05:00:42PM -0400, Bruce Momjian wrote:
> > On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> > > Oh, is that the idea? I was kinda assuming that the data was kept
> > > as-stored in shared buffers, ie. it would be
On Tue, Jun 25, 2019 at 02:28:00PM +0200, Peter Eisentraut wrote:
> On 2019-06-17 11:23, Antonin Houska wrote:
> > I'm thinking how to teach postmaster to accept FEBE protocol connections
> > temporarily, just to receive the key. The user applications like pg_ctl,
> > initdb or pg_upgrade would
On Fri, Jul 5, 2019 at 7:39 PM Robert Haas wrote:
>
> On Tue, Jun 25, 2019 at 4:00 PM Amit Kapila wrote:
> > Fair enough. I have implemented it based on next_retry_at and use
> > constant time 10s for the next retry. I have used define instead of a
> > GUC as all the other constants for
Masahiko Sawada writes:
> I think the following functions are mistakenly left in the header
> file. So attached patch removes them.
> dsa_startup()
> TransactionIdAbort()
> renameatt_type()
Agreed, these are referenced nowhere. I pushed the patch.
> I realized that TransactionIdAbort is
On Fri, Jul 5, 2019 at 04:10:04PM -0400, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 03:46:28PM -0400, Alvaro Herrera wrote:
> > On 2019-Jul-05, Bruce Momjian wrote:
> >
> > > What people really want with more-granular-than-cluster encryption is
> > > the ability to supply their passphrase
Hi Surafel,
On Mon, Jul 01, 2019 at 08:48:27PM +0300, Surafel Temesgen wrote:
Hello,
we use atoi for user argument processing in same place which return zero
for both invalid input and input value zero. In most case its ok because we
error out with appropriate error message for input zero but
On Fri, Jul 5, 2019 at 05:00:42PM -0400, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> > On 2019-Jul-05, Bruce Momjian wrote:
> >
> > > Uh, well, you have the WAL record, and you want to write it to an 8k
> > > page. You have to read the 8k page from
First of all, it's pretty difficult to follow the discussion when it's
not clear what's the original message and what's the response. E-mail
clients generally indent the original message with '>' or someting like
that, but your client does not do that (which is pretty silly). And
copying the
I might be missing something, but it seems like you intend to replace
the SQL grammar we have with something else. It's not clear to me what
would be the point of doing that, and it definitely looks like a huge
amount of work - e.g. we don't have any support for switching between
two distinct
On Fri, Jul 05, 2019 at 12:38:02PM -0400, Tom Lane wrote:
> I wrote:
> > David Fetter writes:
> >> [ v7-0001-Add-warn-to-psql.patch ]
>
> > I took a look at this. I have no quibble with the proposed feature,
> > and the implementation is certainly simple enough. But I'm unconvinced
> > about
On Fri, Jul 5, 2019 at 05:00:42PM -0400, Bruce Momjian wrote:
> On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> > On 2019-Jul-05, Bruce Momjian wrote:
> >
> > > Uh, well, you have the WAL record, and you want to write it to an 8k
> > > page. You have to read the 8k page from
On Sat, Jul 6, 2019 at 1:07 AM Peter Eisentraut
wrote:
> On 2019-07-05 14:06, Thomas Munro wrote:
> > +#ifndef HAVE_EXPLICIT_BZERO
> > +#define explicit_bzero(b, len) memset(b, 0, len)
> > +#endif
> >
> > I noticed some other libraries use memset through a function pointer
> > or at least define
On Fri, Jul 5, 2019 at 04:24:54PM -0400, Alvaro Herrera wrote:
> On 2019-Jul-05, Bruce Momjian wrote:
>
> > Uh, well, you have the WAL record, and you want to write it to an 8k
> > page. You have to read the 8k page from disk into shared buffers, and
> > you have to decrypt the 8k page to do
On 2019-Jul-05, Bruce Momjian wrote:
> Uh, well, you have the WAL record, and you want to write it to an 8k
> page. You have to read the 8k page from disk into shared buffers, and
> you have to decrypt the 8k page to do that, right? We aren't going to
> store 8k pages encrypted in shared
On Fri, Jul 05, 2019 at 03:38:28PM -0400, Bruce Momjian wrote:
On Sun, Jun 16, 2019 at 03:57:46PM -0400, Stephen Frost wrote:
Greetings,
* Bruce Momjian (br...@momjian.us) wrote:
> On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> > On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > > On
On Mon, Jul 1, 2019 at 3:54 AM Thomas Munro wrote:
> [ new patches ]
I took a look at 0012 today, Amit's patch for extending the binary
heap machinery, and 0013, Amit's patch for "Infrastructure to register
and fetch undo action requests."
I don't think that binaryheap_allocate_shm() is a good
On Fri, Jul 5, 2019 at 03:46:28PM -0400, Alvaro Herrera wrote:
> On 2019-Jul-05, Bruce Momjian wrote:
>
> > What people really want with more-granular-than-cluster encryption is
> > the ability to supply their passphrase key _when_ they want to access
> > their data, and then leave and be sure
On 2019-Jul-05, Stephen Frost wrote:
> I had been specifically thinking of tablespaces because we might be able
> to do something exactly along these lines- keep which tablespace the
> data is in directly in the WAL (and not encrypted), but then have the
> data itself be encrypted, and with the
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2019-Jul-05, Bruce Momjian wrote:
>
> > What people really want with more-granular-than-cluster encryption is
> > the ability to supply their passphrase key _when_ they want to access
> > their data, and then leave and be sure
On 2019-Jul-05, Bruce Momjian wrote:
> What people really want with more-granular-than-cluster encryption is
> the ability to supply their passphrase key _when_ they want to access
> their data, and then leave and be sure their data is secure from
> decryption. That will not be possible since
On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> On 6/15/19 9:28 PM, Bruce Momjian wrote:
> > There are no known non-exhaustive plaintext attacks on AES:
> >
> >
> > https://crypto.stackexchange.com/questions/1512/why-is-aes-resistant-to-known-plaintext-attacks
>
> Even that
On Sun, Jun 16, 2019 at 03:57:46PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Sun, Jun 16, 2019 at 12:42:55PM -0400, Joe Conway wrote:
> > > On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > > > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway
Peter Eisentraut writes:
> rebased patch attached, no functionality changes
I poked at this a bit, and soon found that it fails check-world,
because the isolationtester binary is built with an rpath that
only works if it's part of the temp install tree, which it ain't.
On Thu, Jul 4, 2019 at 11:44 AM Alvaro Herrera wrote:
> I think that the functionality in your patch is already integrated in
> Paul's patch for temporal PK/FK elsewhere ... is that correct, or is
> this patch orthogonal to that work?
Hi Vik, I wasn't aware that you had moved your work over to
On Thu, Jul 4, 2019 at 05:06:09PM -0700, Peter Geoghegan wrote:
> This result is very impressive. We'll need to revisit what the right
> trade-off is for the compression scheme, which Heikki had some
> thoughts on when we left off 3 years ago, but that should be a lot
> easier now. I am very
On Fri, Jul 05, 2019 at 07:55:15AM +, Tom Mercha wrote:
Dear Hackers
I am interested in implementing my own Domain Specific Language (DSL)
using PostgreSQL internals. Originally, the plan was not to use
PostgreSQL and I had developed a grammar and used ANTLRv4 for parser
work and general
Tomas Vondra 于2019年7月5日周五 上午1:46写道：
> I've done a bit of testing and benchmaring on this patch today, and
> there's a bug somewhere, making it look like there are corrupted data.
>
> What I'm seeing is this:
>
> CREATE TABLE t (a text);
>
> -- attached is data for one row
> COPY t FROM
On Fri, Jul 5, 2019 at 10:57 AM Paul A Jungwirth
wrote:
> I take it that a multirange contains of *disjoint* ranges,
*consists* of. :-)
On Fri, Jul 5, 2019 at 10:45 AM David Fetter wrote:
> If I understand the cases correctly, the combination of covering_range
> and multi_range types covers all cases. To recap, covering_range_agg
> assigns a weight, possibly 0, to each non-overlapping sub-range. A
> cast from covering_range to
On Fri, Jul 05, 2019 at 09:58:02AM -0700, Paul A Jungwirth wrote:
> On Mon, Jul 1, 2019 at 3:38 PM Jeff Davis wrote:
> >
> > For getting into core though, it should be a more complete set of
> > related operations. The patch is implicitly introducing the concept of
> > a "multirange" (in this
On Mon, Jul 1, 2019 at 3:38 PM Jeff Davis wrote:
>
> The patch is implicitly introducing the concept of
> a "multirange" (in this case, an array of ranges),
I meant to say before: this patch always returns a sorted array, and I
think a multirange should always act as if sorted when we stringify
On 2019-Jul-05, Tom Lane wrote:
> FWIW, I don't think there's a need for every catversion on the back branch
> to look older than any catversion on HEAD. The requirement so far as the
> core code is concerned is only for non-equality. Now, extension code does
> often do something like "if
On Fri, Jul 5, 2019 at 6:16 PM Peter Eisentraut
wrote:
>
> On 2019-07-02 10:30, Julien Rouhaud wrote:
> > That's a great idea, and would make the parallelism in reindexdb much
> > simpler. There's however a downside, as users won't have a way to
> > benefit from index filtering until they
On Fri, Jul 5, 2019 at 4:31 AM Pavel Stehule wrote:
> The first issue is unstable regress tests - there is a problem with opr_sanity
I would prefer to avoid needing to add anything to opr_sanity really.
A multirange would let me achieve that I think. But otherwise I'll add
the ordering. Thanks!
On Fri, Jul 5, 2019 at 12:32 PM David Fetter wrote:
> Folks,
>
> Corey Huinker put together the documentation for this proposed
> feature. Does this seem like a reasonable way to do it?
>
>
In doing that work, it became clear that the command was serving two
masters:
1. A desire to see the
Peter Eisentraut writes:
> On 2019-07-05 01:33, Noah Misch wrote:
>> I just saw this proposal. The undefined behavior in question is strictly
>> academic. These changes do remove the need for new users to discover
>> -fno-sanitize=nonnull-attribute, but they make the code longer and no
>>
Tomas Vondra writes:
> I've pushed the REL_12_STABLE backpatches too, now. I've ended up using
> 201907031 and 201907032 - those values precede the first catversion bump
> in master (201907041), so the back branch looks "older". And there's a
> bit of slack for additional bumps (if the unlikely
On Thu, Jul 4, 2019 at 11:34 AM Alvaro Herrera wrote:
>
> I noticed that this patch has a // comment about it segfaulting. Did
> you ever figure that out? Is the resulting code the one you intend as
> final?
Thanks for the review! I haven't revisited it but I'll see if I can
track it down. I
On Fri, Jul 05, 2019 at 06:14:31PM +0200, Peter Eisentraut wrote:
> On 2019-07-05 01:33, Noah Misch wrote:
> > I just saw this proposal. The undefined behavior in question is strictly
> > academic. These changes do remove the need for new users to discover
> > -fno-sanitize=nonnull-attribute,
On Mon, Jul 1, 2019 at 3:38 PM Jeff Davis wrote:
>
> For getting into core though, it should be a more complete set of
> related operations. The patch is implicitly introducing the concept of
> a "multirange" (in this case, an array of ranges), but it's not making
> the concept whole.
>
> What
On Fri, 2019-07-05 at 07:58 +0200, Pavel Stehule wrote:
> The question is naming - should be this agg function named
> "range_agg", and multi range agg "multirange_agg"? Personally, I have
> not a problem with range_agg, and I have not a problem so it is based
> on union operation. It is true so
Fabien COELHO writes:
> I agree that using TAP test if another simpler option is available is not
> a good move.
> However, in the current state, as soon as there is some variation a test
> is removed and coverage is lost, but they could be kept if the check could
> be against a regexp.
I'm
Please find the rebased patch attached.
Tested like the following.
Provided you're in the postgres checkout and you've run make in
src/test/examples/ and connected to db=postgres:
CREATE SCHEMA testlibpq3;
SET search_path = testlibpq3;
CREATE TABLE test1_(i int4, t text, b bytea);
INSERT INTO
I wrote:
> David Fetter writes:
>> [ v7-0001-Add-warn-to-psql.patch ]
> I took a look at this. I have no quibble with the proposed feature,
> and the implementation is certainly simple enough. But I'm unconvinced
> about the proposed test scaffolding.
I pushed this with the simplified test
> This sanitizer has found real problems in the past. By removing these
> trivial issues we can then set up a build farm animal or similar to
> automatically check for any new issues.
We have done exactly this in postgis with 2 different jobs (gcc and clang)
and, even though it doesn't happen
Folks,
Corey Huinker put together the documentation for this proposed
feature. Does this seem like a reasonable way to do it?
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From
On 2019-07-02 10:45, Julien Rouhaud wrote:
> It just seemed wrong to me to allow a partial processing for something
> that's aimed to prevent corruption. I'd think that if users are
> knowledgeable enough to only reindex a subset of indexes/tables in
> such cases, they can also discard indexes
On 2019-07-02 10:30, Julien Rouhaud wrote:
> That's a great idea, and would make the parallelism in reindexdb much
> simpler. There's however a downside, as users won't have a way to
> benefit from index filtering until they upgrade to this version. OTOH
> glibc 2.28 is already there, and a
On 2019-07-05 01:33, Noah Misch wrote:
> I just saw this proposal. The undefined behavior in question is strictly
> academic. These changes do remove the need for new users to discover
> -fno-sanitize=nonnull-attribute, but they make the code longer and no clearer.
> Given the variety of code
On Fri, Jul 05, 2019 at 10:36:59AM +0200, Tomas Vondra wrote:
On Fri, Jul 5, 2019, 03:28 Tom Lane wrote:
Tomas Vondra writes:
> I was about to push into REL_12_STABLE, when I realized that maybe we
> need to do something about the catversion first. REL_12_STABLE is still
> on 201906161,
Em sex, 5 de jul de 2019 às 07:37, Ronan Dunklau
escreveu:
> We ran into that while using wal2json, which uses the replication id index
> attnames to identify which columns are part of the primary key. If the
> primary key column has been renamed, we end with no information about the
>
On Fri, Jul 05, 2019 at 10:13:25AM -0400, Jeff Janes wrote:
One of the recent mcv commits introduced an unused variable warning.
mcv.c: In function 'statext_mcv_serialize':
mcv.c:914:7: warning: unused variable 'itemlen' [-Wunused-variable]
int itemlen = ITEM_SIZE(dim);
The attached fixes
Thank you for this quick answer, I'll report the bug to wal2json then.
Le ven. 5 juil. 2019 à 16:22, Tom Lane a écrit :
> Ronan Dunklau writes:
> > I've noticed that renaming an indexed column produces inconsistencies in
> > the catalog. Namely, the attname of the attribute of the relation is
Alvaro Herrera writes:
> On 2019-Jul-05, Peter Eisentraut wrote:
>> (There is also precedent for redirecting the extension function to the
>> internal one by changing the SQL-level function definition using CREATE
>> OR REPLACE FUNCTION ... LANGUAGE INTERNAL. But that seems more
>> complicated
Ronan Dunklau writes:
> I've noticed that renaming an indexed column produces inconsistencies in
> the catalog. Namely, the attname of the attribute of the relation is
> properly updated, whereas the attname of the attribute in the index is not,
> and keeps the old value.
If memory serves, we
On 2019-Jul-05, Peter Eisentraut wrote:
> (There is also precedent for redirecting the extension function to the
> internal one by changing the SQL-level function definition using CREATE
> OR REPLACE FUNCTION ... LANGUAGE INTERNAL. But that seems more
> complicated and would require a new
On Fri, Jul 05, 2019 at 03:28:26PM +0300, Nikolay Shaplov wrote:
I am importing recent changes into my reloption patch and came to a question,
I did not find an answer...
vacuum_index_cleanup option exists for both heap and toast relations.
As I understand from documentation index cleanup is
One of the recent mcv commits introduced an unused variable warning.
mcv.c: In function 'statext_mcv_serialize':
mcv.c:914:7: warning: unused variable 'itemlen' [-Wunused-variable]
int itemlen = ITEM_SIZE(dim);
The attached fixes it.
Cheers,
Jeff
mcv_assert_warning.patch
Description:
On Tue, Jun 25, 2019 at 4:00 PM Amit Kapila wrote:
> Fair enough. I have implemented it based on next_retry_at and use
> constant time 10s for the next retry. I have used define instead of a
> GUC as all the other constants for similar things are defined as of
> now. One thing to note is that
On 2019-07-05 14:06, Thomas Munro wrote:
> +#ifndef HAVE_EXPLICIT_BZERO
> +#define explicit_bzero(b, len) memset(b, 0, len)
> +#endif
>
> I noticed some other libraries use memset through a function pointer
> or at least define a function the compiler can't see.
I don't understand what you are
On Fri, Jul 5, 2019 at 12:22 AM Michael Paquier wrote:
>
> On Thu, Jul 04, 2019 at 01:48:24PM -0300, Fabrízio de Royes Mello wrote:
> > On Thu, Jul 4, 2019 at 10:57 AM Robert Haas
wrote:
> >> It would be pretty silly to have one and not the other, regardless of
> >> whether we can think of an
Hello Thomas,
01.07.2019 13:47, Thomas Munro wrote:
>
> A new CF is here and this is in "Needs Review". Would you like to
> provide a rebased patch, or should it really be withdrawn?
The rebased patch is attached, but I still can't find anyone interested
in reviewing it.
So let's withdraw it.
I am importing recent changes into my reloption patch and came to a question,
I did not find an answer...
vacuum_index_cleanup option exists for both heap and toast relations.
As I understand from documentation index cleanup is about is about reporting
access method that some tuples in table
> On 5 Jul 2019, at 11:46, Thomas Munro wrote:
>
> On Fri, Jul 5, 2019 at 6:28 PM Tatsuo Ishii wrote:
>>> The purpose of this patch is to stop the execution of continuous
>>> requests in case of a disconnection from the client.
>>
>> Pgpool-II already does this by sending a parameter status
On Mon, Jun 24, 2019 at 7:57 AM Peter Eisentraut
wrote:
> On 2019-06-23 21:55, Peter Eisentraut wrote:
> > On 2019-06-21 15:25, Tom Lane wrote:
> >> years ago (067a5cdb3). Please use memset() for the substitute instead.
> >
> > OK, done.
+#ifndef HAVE_EXPLICIT_BZERO
+#define explicit_bzero(b,
> The latter is important for similar reasons. JDBC caches prepared
statements internally and if the user changes the search path without using
setSchema or uses a function to change it then internally it would be
necessary to invalidate the cache. Currently if this occurs these
statements fail.
On Fri, Jul 5, 2019 at 5:20 PM Amit Kapila wrote:
>
> On Thu, Jul 4, 2019 at 5:23 PM Amit Kapila wrote:
> >
> > On Mon, Jul 1, 2019 at 1:24 PM Thomas Munro wrote:
> > >
> > > Another small change/review: the function UndoLogGetNextInsertPtr()
> > > previously took a transaction ID, but I'm not
On Thu, Jul 4, 2019 at 5:23 PM Amit Kapila wrote:
>
> On Mon, Jul 1, 2019 at 1:24 PM Thomas Munro wrote:
> >
> > Another small change/review: the function UndoLogGetNextInsertPtr()
> > previously took a transaction ID, but I'm not sure if that made sense,
> > I need to think about it some more.
On 5/7/19 11:00, Peter Eisentraut wrote:
On 2019-07-05 00:08, Jose Luis Tallon wrote:
On 4/7/19 17:30, Alvaro Herrera wrote:
On 2019-Jul-04, Tom Lane wrote:
A possible option 3 is to keep the function in pgcrypto but change
its C code to call the core code.
Updated patch with this change
On 2019-06-23 21:44, Peter Eisentraut wrote:
> On 2019-06-17 18:39, Andres Freund wrote:
>> Basically something like:
>>
>> \gset SELECT my_encodings_are_compatible() AS compatible
>> \if :compatible
>> test;
>> contents;
>> \endif
>
> Cool, that works out quite well. See attached patch. I
čt 4. 7. 2019 v 20:34 odesílatel Alvaro Herrera
napsal:
> I noticed that this patch has a // comment about it segfaulting. Did
> you ever figure that out? Is the resulting code the one you intend as
> final?
>
> Did you make any inroads regarding Jeff Davis' suggestion about
> implementing
On Wed, Jul 3, 2019 at 5:35 AM Tom Lane wrote:
>
> As far as I can see, the point of 0002 is to have just one set of
> flex rules for the various variants of quotecontinue processing.
> That sounds OK, though I'm a bit surprised it makes this much difference
> in the table size. I would suggest
> > On Sat, Jun 22, 2019 at 12:17 PM Floris Van Nee
> > wrote:
> > The following sql statement seems to have incorrect results - some logic in
> > the backwards scan is currently not entirely right.
>
> Thanks for testing! You're right, looks like in the current implementation in
> case of
Hello,
I’ve been testing out the 12 (beta) support for generated columns, mainly in
order to add support for them to the database synchronisation software I
maintain (Kitchen Sync).
So far it looks good compared to the similar functionality on MariaDB and MySQL
(apart from VIRTUAL support
Hello,
I've noticed that renaming an indexed column produces inconsistencies in
the catalog. Namely, the attname of the attribute of the relation is
properly updated, whereas the attname of the attribute in the index is not,
and keeps the old value.
Example:
test # create table test (id int
rebased patch attached, no functionality changes
On 2019-06-27 13:45, Peter Eisentraut wrote:
> On several popular operating systems, we can use relative rpaths, using
> the $ORIGIN placeholder, so that the resulting installation is
> relocatable. Then we also don't need to set LD_LIBRARY_PATH
В письме от понедельник, 1 июля 2019 г. 23:52:13 MSK пользователь Thomas Munro
написал:
> > > This patch does not apply.
> >
> > Oh... Sorry... here goes new version
>
>
> Hi Nikolay,
>
> Could we please have a new rebase?
Sorry, a new reloptions have been introduced, and I need some time
On 2019-07-05 00:08, Jose Luis Tallon wrote:
> On 4/7/19 17:30, Alvaro Herrera wrote:
>> On 2019-Jul-04, Tom Lane wrote:
>>
>>> A possible option 3 is to keep the function in pgcrypto but change
>>> its C code to call the core code.
Updated patch with this change included.
(There is also
On Fri, Jul 5, 2019 at 6:28 PM Tatsuo Ishii wrote:
> > The purpose of this patch is to stop the execution of continuous
> > requests in case of a disconnection from the client.
>
> Pgpool-II already does this by sending a parameter status message to
> the client. It is expected that clients are
On Fri, Jul 5, 2019, 03:28 Tom Lane wrote:
> Tomas Vondra writes:
> > I was about to push into REL_12_STABLE, when I realized that maybe we
> > need to do something about the catversion first. REL_12_STABLE is still
> > on 201906161, while master got to 201907041 thanks to commit
> >
On Fri, Jul 5, 2019 at 6:42 PM Tatsuo Ishii wrote:
> > This seems like a reasonable idea to me. There is no point in running
> > a monster 24 hour OLAP query if your client has gone away. It's using
> > MSG_PEEK which is POSIX, and I can't immediately think of any reason
> > why it's not safe
Dear Hackers
I am interested in implementing my own Domain Specific Language (DSL) using
PostgreSQL internals. Originally, the plan was not to use PostgreSQL and I had
developed a grammar and used ANTLRv4 for parser work and general early
development.
Initially, I was hoping for a scenario
On 2019-05-12 11:02, Fabien COELHO wrote:
> While writing some libpq code, I found it quite irritating that the
> documentation is not navigable, so when a function appears in a
> description of another function and you are interested, there is no direct
> way to find it, you have to go to the
Hello open source administrators and mentors,
Thank you again for your patience. We received over 440 technical writer
applications, so there is quite a lot of enthusiasm from the technical
writing community. Every single organization received multiple technical
writer project proposals!
We have
On 2019-04-12 17:51, Fabien COELHO wrote:
> Hmmm. I obviously agree that PQexec is beyond awkward.
>
> Now I'm not sure how anyone is expected to guess the actual function
> working from the available documentation, and without this knowledge I
> cannot see how to write meaningful code for the
> This seems like a reasonable idea to me. There is no point in running
> a monster 24 hour OLAP query if your client has gone away. It's using
> MSG_PEEK which is POSIX, and I can't immediately think of any reason
> why it's not safe to try to peek at a byte in that socket at any time.
I am
> Regarding apply_scanjoin_target_to_paths in 0001 and 0007, it seems
> like what happens is: we first build an Append path for the topmost
> scan/join rel. That uses paths from the individual relations that
> don't necessarily produce the final scan/join target. Then we mutate
> those
> The purpose of this patch is to stop the execution of continuous
> requests in case of a disconnection from the client.
Pgpool-II already does this by sending a parameter status message to
the client. It is expected that clients are always prepared to receive
the parameter status message. This
On Fri, Jul 5, 2019 at 5:36 PM Thomas Munro wrote:
> On Sat, Feb 9, 2019 at 6:16 AM wrote:
> > The purpose of this patch is to stop the execution of continuous
> > requests in case of a disconnection from the client. In most cases, the
> > client must wait for a response from the server before
90 matches
Mail list logo
