Re: TABLE tab completion
On 29 May 2018 at 07:28, Vik Fearing wrote: > The tab completion for the TABLE command includes indexes but that's a > bug. Attached is a trivial patch to fix it. Looks correct to me. You lose tab completion for "TABLE pg_toast.pg_toast_xyz" but that seems reasonable. If people want to query toast tables I'm sure they'll manage.
\d t: ERROR: XX000: cache lookup failed for relation
Resending to -hackers
https://www.postgresql.org/message-id/20180527022401.GA20949%40telsasoft.com
Is that considered an actionable problem?
Encountered consistently while trying to reproduce the vacuum full
pg_statistic/toast_2619 bug; while running a loop around VAC FULL and more in
another session:
[1]- Running { time sh -ec 'while :; do psql --port 5678
postgres -qc "VACUUM FULL pg_toast.pg_toast_2619"; psql --port 5678 postgres
-qc "VACUUM FULL pg_statistic"; done'; date; } &
[2]+ Running time while :; do
psql postgres --port 5678 -c "INSERT INTO t SELECT i FROM
generate_series(1,99) i"; sleep 1; for a in `seq 999`;
do
psql postgres --port 5678 -c "ALTER TABLE t ALTER i TYPE int USING
i::int"; sleep 1; psql postgres --port 5678 -c "ALTER TABLE t ALTER i TYPE
bigint"; sleep 1;
done; psql postgres --port 5678 -c "TRUNCATE t"; sleep 1;
done &
$ psql --port 5678 postgres -x
psql (11beta1)
...
postgres=# \set VERBOSITY verbose
postgres=# \d t
ERROR: XX000: cache lookup failed for relation 8096742
LOCATION: flatten_reloptions, ruleutils.c:11065
Justin
Few cosmetic suggestions for commit 16828d5c (Fast Alter Table Add Column...)
Some assorted comments:
1.
-When a column is added with ADD COLUMN, all existing
-rows in the table are initialized with the column's default value
-(NULL if no DEFAULT clause is specified).
-If there is no DEFAULT clause, this is merely a
metadata
-change and does not require any immediate update of the table's data;
-the added NULL values are supplied on readout, instead.
+When a column is added with ADD COLUMN and a
+non-volatile DEFAULT is specified, the default is
+evaluated at the time of the statement and the result stored in the
+table's metadata. That value will be used for the column for all
existing
+rows. If no DEFAULT is specified, NULL is used. In
+neither case is a rewrite of the table required.
/the result stored/the result is stored
2.
+/*
+ * Structure used to represent value to be used when the attribute is not
+ * present at all in a tuple, i.e. when the column was created after the
tuple
+ */
+
+typedef struct attrMissing
+{
+ boolammissingPresent; /* true if non-NULL missing value
exists */
+ Datum ammissing; /* value when attribute is missing */
+} AttrMissing;
+
a. Extra space (empty line) between structure and comments seems
unnecessary.
b. The names of structure members seem little difficult to understand if
you and or others also think so, can we rename them to something like
(missingPresent, missingVal) or (attmissingPresent, attmissingVal) or
something similar.
Patch to address 1 and 2a is attached. What do you think about 2b?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
cosmetic_changes_fast_addcol_v1.patch
Description: Binary data
Re: why partition pruning doesn't work?
Jeff Janes writes: > On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane wrote: >> It's worth questioning whether this is a bug fix or an improvement. >> If the latter, it probably ought to wait for v12. > If explaining the change requires reference to tokens from the source code, > rather than something an end user could understand, I'd argue it is a bug > fix rather than an improvement. Well, the difference between volatile, stable and immutable functions is well-documented, so I don't think that's a great argument. If there's some aspect of this behavior that's not predictable from understanding which class the partition key expression falls into, then I could agree that's a bug. regards, tom lane
Re: why partition pruning doesn't work?
On Sat, Jun 2, 2018 at 5:16 PM, Jeff Janes wrote: > On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane wrote: >> >> >> I agree though that it seems strange to special-case SQLValueFunction >> rather than any-stable-expression. As long as the evaluation happens >> at executor start (i.e. with the query's run-time snapshot) it should >> be reasonable to simplify any stable expression. >> >> It's worth questioning whether this is a bug fix or an improvement. >> If the latter, it probably ought to wait for v12. > > > If explaining the change requires reference to tokens from the source code, > rather than something an end user could understand, I'd argue it is a bug > fix rather than an improvement. If we going to implement stable expression folding before the actual execution starts, that's a feature in itself. So, it's V12 material. Partition pruning will use that feature. I don't think we should make partition pruning work with stable expressions in some ad-hoc way in V11 and the some future release (mostly V12) implements it on top of stable expression folding feature. So my vote for making it work in V12. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
Re: I'd like to discuss scaleout at PGCon
On Sat, Jun 2, 2018 at 4:05 AM, Simon Riggs wrote: > On 1 June 2018 at 16:56, Ashutosh Bapat > wrote: >> On Fri, Jun 1, 2018 at 11:10 AM, Simon Riggs wrote: >>> >>> Using a central coordinator also allows multi-node transaction >>> control, global deadlock detection etc.. >> >> But that becomes an SPOF and then we have to configure a standby for >> that. I am not saying that that's a bad design but it's not very good >> for many work-loads. But it would be good if we could avoid any >> "central server" in this configuration. >> >>> >>> And that is why both XL and "FDW approach" rely on a central coordinator. >> >> I don't think we ever specified that "FDW approach" "relies" on a >> central coordinator. One could configure and setup a cluster with >> multiple coordinators using FDWs. > > Yes, of course. You're just misunderstanding me. I'm talking about a > query coordinator "role". There can be many coordinator components and > they can be spread out in variours ways, but for any one SQL query > there needs to be one coordinator node. Not a SPOF. In your earlier mail, which is included above, you mentioned central coordinator for multi-node transaction control and global deadlock detection. That doesn't sound like a "query coordinator role". It sounds more like GTM, which is an SPOF. Anyway I am happy to clarify that "FDW approach" relies on a query coordinator, the server which faces the client. But I don't think we have decided how would the transaction management and deadlock detection work in the shared nothing cluster of PostgreSQL servers. There was discussion in developer unconference this year, but I was not part of that as I was holding another session the same time. May be somebody who attended that session can post a summary here or provide a link to the summary written elsewhere. > >>> >>> FDWs alone are not enough. It is clear that some more tight coupling >>> is required to get things to work well. For example, supporting SQL >>> query plans that allow for redistribution of data for joins. >> >> I think partitioning + FDW provide basic infrastructure for >> distributing data, planning queries working with such data. We need >> more glue to support node management, cluster configuration. So, I >> agree with your statement. But I think it was clear from the beginning >> that we need more than FDW and partitioning. > > No, it wasn't clear. But I'm glad to hear it. It might actually work then. Good to see some agreement. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
Re: pg_config.h.win32 missing a set of flags from pg_config.h.in added in v11 development
Heikki Linnakangas writes: > On 02/06/18 17:09, Tom Lane wrote: >> More concerning is that RHEL6 is on 1.0.1e: > I was only thinking of requiring 1.0.2 on Windows. Ah. Personally, I don't care about that case, but maybe somebody else wants to speak for it? regards, tom lane
Re: Keeping temporary tables in shared buffers
Hi Amit On Mon, May 28, 2018 at 4:25 AM, Amit Kapila wrote: > > This is one way, but I think there are other choices as well. We can > identify and flush all the dirty (local) buffers for the relation > being accessed parallelly. Now, once the parallel operation is > started, we won't allow performing any write operation on them. It We talked about this in person in Ottawa and it was great meeting you! To summarize, the above proposal to continue using local buffers for temp tables is a step forward, however, it enables only certain kinds of queries to be parallelized for temp tables. E.g. queries changing a temp table in any way cannot be parallelized due to the restriction of no writes during parallel operation. > > Yeah, I think cases, where we need to drop temp relations, will become > costlier as they have to traverse all the shared buffers instead of > just local buffers. > This is a valid concern. The idea of using a radix tree of block numbers as proposed by Andres [1] is worth pursuing. Cost of identifying and dropping shared buffers belonging to a relation using radix tree would be reduced to O(log n). Asim [1] https://www.postgresql.org/message-id/20150912201941.GA8311%40alap3.anarazel.de
Re: why partition pruning doesn't work?
On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane wrote: > > I agree though that it seems strange to special-case SQLValueFunction > rather than any-stable-expression. As long as the evaluation happens > at executor start (i.e. with the query's run-time snapshot) it should > be reasonable to simplify any stable expression. > > It's worth questioning whether this is a bug fix or an improvement. > If the latter, it probably ought to wait for v12. > If explaining the change requires reference to tokens from the source code, rather than something an end user could understand, I'd argue it is a bug fix rather than an improvement. Cheers, Jeff
Re: pg_config.h.win32 missing a set of flags from pg_config.h.in added in v11 development
On 02/06/18 17:09, Tom Lane wrote: Michael Paquier writes: ... Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the minimal version of OpenSSL supported to 1.0.2, which is something I would not feel much sorry about either like Heikki, as I have heard of many vendors maintaining OpenSSL past versions on Linux, but not yet on Windows. It is easy to be wrong when it comes to any company policies though. I have assorted pet dinosaurs using 0.9.8x or 0.9.8y, but I'm not sure that any of those still represent credible real-world cases. More concerning is that RHEL6 is on 1.0.1e: I was only thinking of requiring 1.0.2 on Windows. On other platforms, the configure tests work fine, and there's no problem supporting older versions. You just won't get tls-server-end-point channel binding support on older versions. - Heikki
Re: Constraint documentation
=?UTF-8?Q?L=C3=A6titia_Avrot?= writes: > ... By looking at the constraint documentation page, we found out there was > nothing about it. So we decided to write a first version of a patch. Hi Lætitia! Please add this thread to the open commitfest to make sure we don't forget about it. (The open -fest is dated 2018-09, but it's likely we'll try to process some of it in July instead.) regards, tom lane
Re: pg_config.h.win32 missing a set of flags from pg_config.h.in added in v11 development
Michael Paquier writes: > Navigating through the logs of the buildfarm, it is actually not really > easy to find out which version of OpenSSL a build is using at compile > time. Perhaps we would want first to report this information? +1 if we can figure a way to do it. ISTR having looked for a way and not found a good one. The obvious answer is "ssh -V", but that could report a library version that's different from what we're linking to --- and indeed *would*, on several of my buildfarm animals, because I point them to the appropriate openssl version with --with-includes and --with-libs, neither of which touch PATH. > ... Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the > minimal version of OpenSSL supported to 1.0.2, which is something I > would not feel much sorry about either like Heikki, as I have heard of > many vendors maintaining OpenSSL past versions on Linux, but not yet on > Windows. It is easy to be wrong when it comes to any company policies > though. I have assorted pet dinosaurs using 0.9.8x or 0.9.8y, but I'm not sure that any of those still represent credible real-world cases. More concerning is that RHEL6 is on 1.0.1e: $ ssh -V OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 That's definitely still a live platform. regards, tom lane
Constraint documentation
Hi, Patrick Francelle and I encountered this situation where there was a check constraint on a table using a function to enforce a constraint across two different tables. When using pg_dump to dump structure and data we found out we couldn't restore it because tables weren't dumped in the right order regarding that constraint. Then, we found out this thread https://www.postgresql.org/message-id/11619.1077803699%40sss.pgh.pa.us where Tom explained how "check constraint were not intended to handle cross-table checks" and how you should use a trigger instead. If you look at modeling databases books, you'll actually find someting similar. By looking at the constraint documentation page, we found out there was nothing about it. So we decided to write a first version of a patch. You will find it enclosed. Here are some informations about it : Project : postgresql Branch : master Applying, compilation and test : I applied it successfully. It compiles sucessfully and I tested it on my laptop Platform-specific : there shouldn't be any platform specific item Regression tests : regression tests are not available for documentation Documentation : We don't document documentation source code Performance impact : none Choices I made and why : I choose to include a trigger link to help users go to the accurate documentation section. I also choose to add it as a note so it's more visible (but I'm open minded on that matter) Adresses a todo item : no Please let me tell me know if I missed something. I'm waiting for feedbacks to improve that patch. Cheers, Lætitia -- *Think! Do you really need to print this email ? * *There is no Planet B.* diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 2cd0b8a..dfe00a5 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -403,6 +403,17 @@ CREATE TABLE products ( ensure that a column does not contain null values, the not-null constraint described in the next section can be used. + + + + Check constraint were not designed to enforce business rules across tables. + Avoid using check constraints with function accessing to other tables and + prefer triggers instead (please refer to for + more information about triggers). PostgreSQL won't prevent you + from doing so, but be aware you might encounter difficulties to restore + dumps (generated with pg_dump or pg_dumpall) if you do. + +
Re: [HACKERS] GnuTLS support
On 08/03/18 14:13, Peter Eisentraut wrote: There are two failures in the SSL tests that I cannot explain. The tests are for some rather obscure configurations, so the changed behaviors are not obviously wrong, perhaps legitimate implementation differences. But someone wrote those tests with a purpose (probably), so we should have some kind of explanation for the regressions. I applied this over commit 4e0c743c18 (because this doesn't compile against current master, needs rebasing), and ran "make check" in src/test/ssl. All the tests passed. I'm using GnuTLS version 3.5.8. What failures did you see? - Heikki
Re: New committers announced at PGCon 2018
Awesome! Michael On Sat, Jun 2, 2018 at 6:06 AM, Haroon . wrote: > Congratulations everyone! Indeed great achievement. > > Regards, > Haroon > > On Sat, Jun 2, 2018, 02:05 Tom Lane wrote: > >> The core team is pleased to announce the appointment of seven >> new Postgres committers: >> >> Etsuro Fujita >> Peter Geoghegan >> Amit Kapila >> Alexander Korotkov >> Thomas Munro >> Michael Paquier >> Tomas Vondra >> >> Congratulations to all! >> >> regards, tom lane >> >>
Re: pg_config.h.win32 missing a set of flags from pg_config.h.in added in v11 development
On Sat, Jun 02, 2018 at 01:24:41PM -0400, Tom Lane wrote: > Heikki Linnakangas writes: >> But yeah, clearly those are missing from pg_config.h.win32 at the >> moment. It's not actually clear to me, when that file is (supposed to >> be) updated. Are you supposed to remember to update it, whenever you >> update pg_config.h.in? Or does someone update it with the results from >> some canonical MinGW buildfarm member before the release? > > AFAIK you have to update it manually; I've never seen anyone attempt > to rebuild it as per your second hypothesis. There are bits of it > that configure definitely could not produce. c9e1ad7f for example, which is the last thing I could come up with. Navigating through the logs of the buildfarm, it is actually not really easy to find out which version of OpenSSL a build is using at compile time. Perhaps we would want first to report this information? SSLeay_version is here for configure, while we could use a call to "openssl version" for the MSVC scripts. Actually, it seems that to me that SSL_OP_NO_COMPRESSION should also be added.. Making HAVE_X509_GET_SIGNATURE_NID a hard requirement bumps the minimal version of OpenSSL supported to 1.0.2, which is something I would not feel much sorry about either like Heikki, as I have heard of many vendors maintaining OpenSSL past versions on Linux, but not yet on Windows. It is easy to be wrong when it comes to any company policies though. -- Michael signature.asc Description: PGP signature
Re: pg_config.h.win32 missing a set of flags from pg_config.h.in added in v11 development
On Sat, Jun 02, 2018 at 01:19:41PM -0400, Heikki Linnakangas wrote: > I wouldn't be too sorry to just bump our minimum requirements for Windows, > in v11. Assuming that recent-enough versions of OpenLSAP and OpenSSL are > readily available on Windows. s/OpenLSAP/OpenLDAP/. It may be better to look at what the installers of EDB do then for this purpose... I don't have a Windows VM at hand now to install or decompress this MSI, but my guess is that they use the LTS version of 1.0.2. > I think on Windows, you typically bundle the > .dlls with the PostgreSQL binaries, so it would be natural to bundle the > latest available libraries. Any sane Windows build would link to its dependent DLLs dynamically, meaning that you usually need a copy of the DLLs in both bin/ and lib/ as libpq also needs to be able to load them and those need to be on the same path as the library loaded (My Windows-bundling skills in this area are far from being top-notch, but I got bitten by such things in the past.) > And in the unlikely case that you'd want to use > older ones, you could still modify pg_config.h.win32 manually. That makes the life of installer maintainers a bit harder than necessary though. One idea to simplify things could be to introduce an extra, optional file whose contents are copied at the bottom of pg_config.h automatically. I am not sure that this is worth the pain, just mentioning the possibility. -- Michael signature.asc Description: PGP signature
Re: [GSoC] create type questions
> "Charles" == Charles Cui writes: Charles> Hi Tom, Charles>Thanks for your comments, I do forget create type shell. Charles> But even if I add this line still does not work. Charles> Here is the commit that can demo my bug ( Charles> https://github.com/charles-cui/pg_thrift/commit/8b43f3e2172f4a1b4e61211f7d76b061a90c38f7 Charles> ) Charles> To see it, download the repo and do make install && make installcheck. Charles> It cannot return a bytea as expected. Your output function isn't doing anything, and in particular it's not returning any value (just dropping off the end), so as soon as pg tries to output a query result containing a thrift_binary value, it either outputs garbage or crashes. -- Andrew (irc:RhodiumToad)
Re: SCRAM with channel binding downgrade attack
On 28/05/18 15:08, Michael Paquier wrote:
On Mon, May 28, 2018 at 12:26:37PM +0300, Heikki Linnakangas wrote:
Sounds good.
Okay. Done this way as attached. If the backend forces anything else
than SCRAM then the client gets an immediate error if channel binding is
required, without waiting for the password prompt.
Thanks! The comments and error messages need some copy-editing:
/*
* Select the mechanism to use. Pick SCRAM-SHA-256-PLUS over
anything
* else if a channel binding mode is not 'disable'. Pick
SCRAM-SHA-256
* if nothing else has already been picked. If we add more
mechanisms, a
* more refined priority mechanism might become necessary.
*/
"else if a channel binding mode is not 'disable'" sounds a bit awkward.
A double negative. (Also, "a" -> "the")
+ /*
+* If client is willing to enforce the use the channel binding but
+* it has not been previously selected, because it was either not
+* published by the server or could not be selected, then complain
+* back. If SSL is not used for this connection, still complain
+* similarly, as the client may want channel binding but forgot
+* to set it up to do so which could be the case with sslmode=prefer
+* for example. This protects from any kind of downgrade attacks
+* from rogue servers attempting to bypass channel binding.
+*/
Instead of "is willing to enforce the use the channel binding", perhaps
simply "requires channel binding".
+ printfPQExpBuffer(>errorMessage,
+libpq_gettext("channel binding required for SASL authentication but no valid
mechanism could be selected\n"));
Channel binding is a property of SCRAM authentication specifically, it's
not applicable to other SASL mechanisms. So I'd suggest something like:
"server does not support channel binding, and
channel_binding_mode=require was used"
+ /*
+* Complain if channel binding mechanism is chosen but no channel
+* binding type is defined.
+*/
+ if (strcmp(selected_mechanism, SCRAM_SHA_256_PLUS_NAME) == 0 &&
+ conn->scram_channel_binding_type == NULL)
+ {
+ printfPQExpBuffer(>errorMessage,
+ libpq_gettext("SASL authentication
mechanism using channel binding supported but no channel binding type defined\n"));
+ goto error;
+ }
It's not immediately clear to me from the error message or the comment,
when this error is thrown. Can this even happen?
+ /*
+* Before processing any message, perform security-related sanity
+* checks. If the client is willing to perform channel binding with
+* SCRAM authentication, only a subset of messages can be used so
+* as there is no transmission of any password data or such.
+*/
I'd suggest something like:
"If SCRAM with channel binding is required, refuse all other
authentication methods. Requiring channel binding implies that the
client doesn't trust the server, until the SCRAM authentication is
completed, so it's important that we don't divulge the plaintext
password, or perform some weaker authentication, even if the server asks
for it. In all other authentication methods, it's currently assumed that
the client trusts the server, either implicitly or because the SSL
certificate was already verified during the SSL handshake."
+ printfPQExpBuffer(>errorMessage,
+libpq_gettext("channel binding required for authentication but invalid protocol
used\n"));
If I understand correctly, you get this error, e.g. if you have
"password" or "sspi" in pg_hba.conf, and the client uses
"channel_binding_mode=require". "Invalid protocol" doesn't sound right
for that. Perhaps "channel binding required, but the server requested %s
authentication". Is it possible to have an error hint here? Perhaps add
"HINT: change the authentication method to scram-sha-256 in the server's
pg_hba.conf file".
- Heikki
Re: [GSoC] create type questions
Hi Tom, Thanks for your comments, I do forget create type shell. But even if I add this line still does not work. Here is the commit that can demo my bug ( https://github.com/charles-cui/pg_thrift/commit/8b43f3e2172f4a1b4e61211f7d76b061a90c38f7 ) To see it, download the repo and do make install && make installcheck. It cannot return a bytea as expected. Thanks Charles! 2018-06-01 18:28 GMT-07:00 Tom Lane : > Charles Cui writes: > >I have a new type defined like this > > CREATE TYPE thrift_binary ( > > INPUT = thrift_binary_in, > > OUTPUT = thrift_binary_out, > > LIKE = bytea > > ); > > > in thrift_binary_in, it accepts cstring and returns thrift_binary. > > OK, that's what it should do. > > > And in > > this function I returned a bytea because the create type tells the system > > thrift_binary and bytea are the same. > > Sure, PG_RETURN_BYTEA_P() would work in the C code. I think it might be > worth inventing a macro PG_RETURN_THRIFT_BINARY_P that's a thin wrapper > around that, just for clarity's sake, but it doesn't matter functionally. > > > However, the test passes only when I > > explicitly tell thrift_binary_in to return a bytea (change the return > type > > from thrift_binary to bytea), and it does not work when returns > > thrift_binary. > > What do you mean by "the test passes" (or doesn't pass)? What do you > mean by "tell thrift_binary_in to return a bytea"? You just said you > were already doing that. > > This works for me: > > regression=# create type thrift_binary; > CREATE TYPE > regression=# create function thrift_binary_in(cstring) returns > thrift_binary > regression-# strict immutable language internal as 'byteain'; > NOTICE: return type thrift_binary is only a shell > CREATE FUNCTION > regression=# create function thrift_binary_out(thrift_binary) returns > cstring > regression-# strict immutable language internal as 'byteaout'; > NOTICE: argument type thrift_binary is only a shell > CREATE FUNCTION > regression=# CREATE TYPE thrift_binary ( > regression(# INPUT = thrift_binary_in, > regression(# OUTPUT = thrift_binary_out, > regression(# LIKE = bytea > regression(# ); > CREATE TYPE > > I cheated here by pointing to byteain/byteaout instead of C functions > that'd actually do what you want, but CREATE TYPE doesn't know that. > > I suspect you may have forgotten the initial dummy creation of > thrift_binary as a "shell type". > > regards, tom lane >
Re: New committers announced at PGCon 2018
Congratulations everyone! Indeed great achievement. Regards, Haroon On Sat, Jun 2, 2018, 02:05 Tom Lane wrote: > The core team is pleased to announce the appointment of seven > new Postgres committers: > > Etsuro Fujita > Peter Geoghegan > Amit Kapila > Alexander Korotkov > Thomas Munro > Michael Paquier > Tomas Vondra > > Congratulations to all! > > regards, tom lane > >
Re: New committers announced at PGCon 2018
Congratulations Everyone!!! Thanks. -- Regards, Neha Sharma On Sat, Jun 2, 2018 at 12:12 PM, Ashutosh Sharma wrote: > Congrats everyone and special congratulations to Amit for becoming the > first Indian PostgreSQL committer !! > > On Sat, Jun 2, 2018 at 9:40 AM, Nikolay Samokhvalov > wrote: > >> сб, 2 июня 2018 г. в 1:10, Teodor Sigaev : >> >>> >>> > Etsuro Fujita >>> > Peter Geoghegan >>> > Amit Kapila >>> > Alexander Korotkov >>> > Thomas Munro >>> > Michael Paquier >>> > Tomas Vondra >>> > >>> > Congratulations to all! >>> >>> +7! >> >> >> +7, >> >> and +2 to you and Oleg with progress in building your Postgres team >> >> Nikolay >> >>> >
Re: I'd like to discuss scaleout at PGCon
On 1 June 2018 at 16:56, Ashutosh Bapat wrote: > On Fri, Jun 1, 2018 at 11:10 AM, Simon Riggs wrote: >> >> Using a central coordinator also allows multi-node transaction >> control, global deadlock detection etc.. > > But that becomes an SPOF and then we have to configure a standby for > that. I am not saying that that's a bad design but it's not very good > for many work-loads. But it would be good if we could avoid any > "central server" in this configuration. > >> >> And that is why both XL and "FDW approach" rely on a central coordinator. > > I don't think we ever specified that "FDW approach" "relies" on a > central coordinator. One could configure and setup a cluster with > multiple coordinators using FDWs. Yes, of course. You're just misunderstanding me. I'm talking about a query coordinator "role". There can be many coordinator components and they can be spread out in variours ways, but for any one SQL query there needs to be one coordinator node. Not a SPOF. >> >> FDWs alone are not enough. It is clear that some more tight coupling >> is required to get things to work well. For example, supporting SQL >> query plans that allow for redistribution of data for joins. > > I think partitioning + FDW provide basic infrastructure for > distributing data, planning queries working with such data. We need > more glue to support node management, cluster configuration. So, I > agree with your statement. But I think it was clear from the beginning > that we need more than FDW and partitioning. No, it wasn't clear. But I'm glad to hear it. It might actually work then. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: New committers announced at PGCon 2018
Congrats everyone and special congratulations to Amit for becoming the first Indian PostgreSQL committer !! On Sat, Jun 2, 2018 at 9:40 AM, Nikolay Samokhvalov wrote: > сб, 2 июня 2018 г. в 1:10, Teodor Sigaev : > >> >> > Etsuro Fujita >> > Peter Geoghegan >> > Amit Kapila >> > Alexander Korotkov >> > Thomas Munro >> > Michael Paquier >> > Tomas Vondra >> > >> > Congratulations to all! >> >> +7! > > > +7, > > and +2 to you and Oleg with progress in building your Postgres team > > Nikolay > >>
