Re: LDAP authentication slow
On Thu, May 31, 2018 at 8:23 AM, C GG wrote: In the meantime, I did what I promised Adrian Klaver I would do and I added > the AD servers to the /etc/hosts file. That had an immediate and dramatic > effect on the performance. That confirms (at least to me) that DNS > resolution was playing a large part in the slowdown. I'm going to > experiment with running a local DNS caching server to see if that will give > the same effect. > I had this problem at one site, and with the same solution. As best as I could tell, Windows was not using DNS as the main way of resolving hostnames. (People assure me that NetBIOS and WINS are almost completely dead, but WireShark tells a different tail--I don't recall the exact name, but it was certainly something other than DNS). So the fact that AD's built in DNS sucks was not a problem for Windows users, which means there was no impetus on the Windows admin to fix it. And the delay on resolution was always 5 seconds plus a very small handful of milliseconds. So it was clearly some kind of designed throttling or timeout, there is no way random congestion could get you so close to 5.00 every time. If we had greater depth of talent on the Windows side, surely we could have fixed the DNS issue. But with greater of talent, we would have been using Kerberos in the first place, like Stephen wants us to. Cheers, Jeff
Re: Long running DDL statements blocking all queries
On Thu, May 31, 2018 at 9:19 AM, Ashu Pachauri wrote: > There was too much noise in the pg_stat_activity output, so I did not post > it. I'll collect the output again and post. > > But, when I checked in pg_stat_activity, PID 18317 is the session that's > running the ALTER statement and it was showing up as "active". So, it's not > blocked by anything, but the fact that the ALTER statement is long running > and it's blocking the operations that are not even on the same table for > the entire duration it's running is troubling. > > I think what you really need to know here is what lock it was holding which was blocking everyone. That information won't be found in the pg_stat_activity. It will be found in pg_locks, but the specific query you ran on that view did not display the columns with that information. You need to include all the columns in the output which you used to join the two pg_locks together. Yes, it will be voluminous, and most of them will not be relevant, but you don't know which ones are relevant until after you see the output. Cheers, Jeff
Re: Code of Conduct plan
Two years ago, there was considerable discussion about creating a Code of Conduct for the Postgres community, as a result of which the core team announced a plan to create an exploration committee to draft a CoC [1]. That process has taken far longer than expected, but the committee has not been idle. They worked through many comments and many drafts to produce a version that seems acceptable in the view of the core team. This final(?) draft can be found at https://wiki.postgresql.org/wiki/Code_of_Conduct We are now asking for a final round of community comments. Please send any public comments to the pgsql-general list (only). If you wish to make a private comment, you may send it to c...@postgresql.org. The initial membership of the CoC committee will be announced separately, but shortly. Unless there are substantial objections, or nontrivial changes as a result of this round of comments, we anticipate making the CoC official as of July 1 2018. regards, tom lane [1] https://www.postgresql.org/message-id/56a8516b.8000...@agliodbs.com
Re: notes from transition to relkind='p'
On 06/01/2018 03:14 PM, Justin Pryzby wrote: Before I forget any more, this is a brain of issues/considerations/concerns with our (partial) transition to partitioned tables over the last ~9 months. I believe these are all documented behaviors, but could be seen by users as a gratuitious/unexpected change or rough edge and the differences could perhaps be mitigated. I realize there's maybe no good time or way to change most of these, but maybe the list will be helpful to somebody in avoiding unexpected transitional issues. It is not clear from above what you are transitioning from. From comments below you seem to be transitioning to the new syntax in version 10 as shown here: https://www.postgresql.org/docs/10/static/release-10.html#id-1.11.6.9.3 " E.5.3.4. Utility Commands Add table partitioning syntax that automatically creates partition constraints and handles routing of tuple insertions and updates (Amit Langote) The syntax supports range and list partitioning. " Is that the case? More comments in line below. . DROP TABLE on a parent no longer fails without CASCADE (dependencies of relkind='p' are deptype='a' "soft" dependencies) 8b4d582d279d784616c228be58af1e39aa430402 . ANALYZE relkind_p also updates stats of child (whereas ANALYZE relkind_r only updates stats for parent); it's unclear if there's any reason why it wasn't always done this way(?). I end up having to conditionize processing based on relkind. 3c3bb99330aa9b4c2f6258bfa0265d806bf365c3 Because there is a clear partition dependency in the declarative partitioning scheme. In the INHERIT scheme(which I assume is what you are talking about) the partitioning is optional. . The docs say: if detaching/re-attach a partition, should first ADD CHECK to avoid a slow ATTACH operation. Perhaps DETACHing a partition could implicitly CREATE a constraint which is usable when reATTACHing? I personally would not like that. If I wanted to maintain the partition constraint I would keep the table in the partition. If I was DETACHing it then it would be to get rid of it or have it exist as a stand alone table. If I where to keep it deciding what constraints to maintain should be up to me. . relkind_p has no entry in pg_stat_user_tables (last_analyze, etc). Maybe the view could do the needed CASE ... (SELECT min() FROM pg_inherits JOIN psut) . ALTER TABLE ATTACH requires specifying bounds: Maybe it sounds naive to suggest one would want to avoid that; but consider: we ended up adding both shell and python logic to parse the table name to allow detaching and reattaching partitions. I think it'd be a nice if the bounds were inferred if there was a single constraint on the partition key. The above I am not sure how you envision that working, especially the inferring the key part. Having the program guess at what I want a partition to be constrained by is something I would need fully explained to me. . ALTER TABLE ATTACH has reversed order of child vs parent relative to NO/INHERIT. Makes sense to me as they show the direction of operation. ATTACH is hooking a child table onto the parent table. INHERIT is a child table pulling from a parent table. . And actually, having both ALTER TABLE DE/TACH vs NO/INHERIT is itself messy: we ended up having branches (both shell and python) to handle both cases (at least for a transitional period, but probably we'll need to continue handling both into the indeterminate future). Well they are two different cases, so I am not sure they could be combined. Cheers, Justin -- Adrian Klaver adrian.kla...@aklaver.com
Re: Code of Conduct plan
Is there some archive of the discussion that brought on this effort and the considerations of the committee itself? I wish I had seen the earlier announcements in 2016 as I would have definitely participated. Another more specific factual question - have there been incidents within the active Postgresql community where behaviour by individuals who are participants in the community have conducted themselves in a manner that brought on the actual need for such a code of conduct to exist in the first place? I'm curious about the specific impetus that brought about Postgresql's efforts to consider one. I've read the other comments in the general list but I'm more interested in the specifics motivations and efforts by the CoC committee. thanks, -- Ben Scherrey On Mon, Jun 4, 2018 at 1:29 AM, Tom Lane wrote: > Two years ago, there was considerable discussion about creating a > Code of Conduct for the Postgres community, as a result of which > the core team announced a plan to create an exploration committee > to draft a CoC [1]. That process has taken far longer than expected, > but the committee has not been idle. They worked through many comments > and many drafts to produce a version that seems acceptable in the view > of the core team. This final(?) draft can be found at > > https://wiki.postgresql.org/wiki/Code_of_Conduct > > We are now asking for a final round of community comments. > Please send any public comments to the pgsql-general list (only). > If you wish to make a private comment, you may send it to > c...@postgresql.org. > > The initial membership of the CoC committee will be announced separately, > but shortly. > > Unless there are substantial objections, or nontrivial changes as a result > of this round of comments, we anticipate making the CoC official as of > July 1 2018. > > regards, tom lane > > [1] https://www.postgresql.org/message-id/56a8516b.8000...@agliodbs.com > >
Re: Code of Conduct plan
On 06/03/2018 11:29 AM, Tom Lane wrote: Two years ago, there was considerable discussion about creating a Code of Conduct for the Postgres community, as a result of which the core team announced a plan to create an exploration committee to draft a CoC [1]. That process has taken far longer than expected, but the committee has not been idle. They worked through many comments and many drafts to produce a version that seems acceptable in the view of the core team. This final(?) draft can be found at https://wiki.postgresql.org/wiki/Code_of_Conduct We are now asking for a final round of community comments. Please send any public comments to the pgsql-general list (only). If you wish to make a private comment, you may send it to c...@postgresql.org. The initial membership of the CoC committee will be announced separately, but shortly. Unless there are substantial objections, or nontrivial changes as a result of this round of comments, we anticipate making the CoC official as of July 1 2018. My comments: 1) Reiterate my contention that this is a solution is search of problem. Still it looks like it is going forward, so see below. 2) "... engaging in behavior that may bring the PostgreSQL project into disrepute, ..." This to me is overly broad and pulls in actions that may happen outside the community. Those if they are actually an issue should be handled where they occur not here. 3) "... members must be sensitive to conduct that may be considered offensive by fellow members and must refrain from engaging in such conduct. " Again overly broad, especially given the hypersensitivity of people these days. I have found that it is enough to disagree with someone to have it called offensive. This section should be removed as proscribed behavior is called out in detail in the paragraphs above it. regards, tom lane [1] https://www.postgresql.org/message-id/56a8516b.8000...@agliodbs.com -- Adrian Klaver adrian.kla...@aklaver.com
Re: Code of Conduct plan
Benjamin Scherrey writes: > Is there some archive of the discussion that brought on this effort and the > considerations of the committee itself? I wish I had seen the earlier > announcements in 2016 as I would have definitely participated. If you poke around in our mailing list archives for early 2016 (Jan/Feb), you'll find a number of threads about it. Mostly on the -general list, IIRC. > Another more specific factual question - have there been incidents within > the active Postgresql community where behaviour by individuals who are > participants in the community have conducted themselves in a manner that > brought on the actual need for such a code of conduct to exist in the first > place? I believe there were a couple of unfortunate incidents at conferences. Now, conferences are generally expected to have their own CoCs and enforce them themselves; this CoC is meant more to cover on-line interactions. You could argue that we shouldn't create such a CoC until something bad happens on-line; but I'd prefer to think that having a CoC might prevent that from ever happening at all, which is surely better. In any case, we went over all these sorts of arguments at excruciating length in 2016. It's quite clear to the core team that a majority of the community wants a CoC. I don't think any useful purpose will be served by re-litigating that point. regards, tom lane
Re: Code of Conduct plan
Tom Lane wrote: Two years ago, there was considerable discussion about creating a Code of Conduct for the Postgres community... We are now asking for a final round of community comments... I really like that this was included: "Any allegations that prove not to be substantiated...will be viewed as a serious community offense and a violation of this Code of Conduct." Good attempt to prevent the CoC being used as vindictive weaponry. I also like that you kept is short. -- B
Re: LDAP authentication slow
Jeff Janes writes: > On Thu, May 31, 2018 at 8:23 AM, C GG wrote: > > In the meantime, I did what I promised Adrian Klaver I would do and I added >> the AD servers to the /etc/hosts file. That had an immediate and dramatic >> effect on the performance. That confirms (at least to me) that DNS >> resolution was playing a large part in the slowdown. I'm going to >> experiment with running a local DNS caching server to see if that will give >> the same effect. >> > > I had this problem at one site, and with the same solution. As best as I > could tell, Windows was not using DNS as the main way of resolving > hostnames. (People assure me that NetBIOS and WINS are almost completely > dead, but WireShark tells a different tail--I don't recall the exact name, > but it was certainly something other than DNS). So the fact that AD's > built in DNS sucks was not a problem for Windows users, which means there > was no impetus on the Windows admin to fix it. And the delay on resolution > was always 5 seconds plus a very small handful of milliseconds. So it was > clearly some kind of designed throttling or timeout, there is no way random > congestion could get you so close to 5.00 every time. > We had particular problems with a specific client. In the end, it turned out that this client used a DNS resolve library which, unlike most other libraries, did not use local DNS cache. Every name lookup involved a full DNS resolution process. Temporary solution was to use IP addresses until admins/devs could work out how to fix the client or find a more robust solution where address isn't 'hard coded'. At the time, the admins responsible for managing the DNS were getting frustrated as their service was being blamed for a local client problem. Key take away, this stuff can be complex to diagnose and a systematic evidence based investigation is often required - problem is, that takes time and is seldom welcomed. -- Tim Cross
Re: Code of Conduct plan
On 06/03/2018 02:47 PM, Tom Lane wrote: Benjamin Scherrey writes: Is there some archive of the discussion that brought on this effort and the considerations of the committee itself? I wish I had seen the earlier announcements in 2016 as I would have definitely participated. If you poke around in our mailing list archives for early 2016 (Jan/Feb), you'll find a number of threads about it. Mostly on the -general list, IIRC. Another more specific factual question - have there been incidents within the active Postgresql community where behaviour by individuals who are participants in the community have conducted themselves in a manner that brought on the actual need for such a code of conduct to exist in the first place? I believe there were a couple of unfortunate incidents at conferences. Now, conferences are generally expected to have their own CoCs and enforce them themselves; this CoC is meant more to cover on-line interactions. You could argue that we shouldn't create such a CoC until something bad happens on-line; but I'd prefer to think that having a CoC might prevent that from ever happening at all, which is surely better. In any case, we went over all these sorts of arguments at excruciating length in 2016. It's quite clear to the core team that a majority of the community wants a CoC. I don't think any useful purpose will be Since there was never a community vote taken I am not sure how it was determined there was a majority in favor. From what I remember of the online discussion the opinion was evenly split on the need for a CoC. served by re-litigating that point. regards, tom lane -- Adrian Klaver adrian.kla...@aklaver.com
Re: Code of Conduct plan
On 06/03/2018 04:54 PM, Berend Tober wrote: Tom Lane wrote: Two years ago, there was considerable discussion about creating a Code of Conduct for the Postgres community... We are now asking for a final round of community comments... I really like that this was included: "Any allegations that prove not to be substantiated...will be viewed as a serious community offense and a violation of this Code of Conduct." Good attempt to prevent the CoC being used as vindictive weaponry. But a futile attempt: "A lie can travel half way around the world while the truth is putting on its shoes." -- Angular momentum makes the world go 'round.
Re: Code of Conduct plan
On 04/06/18 07:32, Adrian Klaver wrote: On 06/03/2018 11:29 AM, Tom Lane wrote: Two years ago, there was considerable discussion about creating a Code of Conduct for the Postgres community, as a result of which the core team announced a plan to create an exploration committee to draft a CoC [1]. That process has taken far longer than expected, but the committee has not been idle. They worked through many comments and many drafts to produce a version that seems acceptable in the view of the core team. This final(?) draft can be found at https://wiki.postgresql.org/wiki/Code_of_Conduct We are now asking for a final round of community comments. Please send any public comments to the pgsql-general list (only). If you wish to make a private comment, you may send it to c...@postgresql.org. The initial membership of the CoC committee will be announced separately, but shortly. Unless there are substantial objections, or nontrivial changes as a result of this round of comments, we anticipate making the CoC official as of July 1 2018. My comments: 1) Reiterate my contention that this is a solution is search of problem. Still it looks like it is going forward, so see below. 2) "... engaging in behavior that may bring the PostgreSQL project into disrepute, ..." This to me is overly broad and pulls in actions that may happen outside the community. Those if they are actually an issue should be handled where they occur not here. 3) "... members must be sensitive to conduct that may be considered offensive by fellow members and must refrain from engaging in such conduct. " Again overly broad, especially given the hypersensitivity of people these days. I have found that it is enough to disagree with someone to have it called offensive. This section should be removed as proscribed behavior is called out in detail in the paragraphs above it. I might possibly say that "I'm the master in this area" when talking to someone on a technical subject. In the sense that I'm better at that particular skill, but some hypersensitive American could get their knickers in a twist (notice, that in this context, no gender is implied -- also in using that that expression "get their knickers in a twist" could offend some snowflake) claiming that I'm suggesting that whoever I'm talking to is my slave! I heard of an American university that doesn't want people to use the term master, like in an MSc, because of the history of slavery. I've used the expressions "sacrifice a willing virgin" and "offering my first born to the gods" as ways to ensure success of resolving a technical issue. The people I say that to, know what I mean -- and they implicitly know that I'm not seriously suggesting such conduct. Yet, if I wrote that publicly, it is conceivable that someone might object! There are a lot of words and phrases that are okay in some cultures, but may be offensive in others -- even within the ame country. Consider a past advertising campaign in Australia to sell government Bonds. They used two very common hand gestures that are very Australian. Bond sales dropped. On investigation, they found the bonds were mainly bought by old Greek people, who found the gestures obscene. The gestures? Thumbs up, and the okay gesture formed by touching the thumb with the next finger -- nothing sexually suggestive to most Australians, but traditional Greeks found them offensive. You should look at the hoohaa over what Linus Torvalds says. I've read several of his posts and seen videos were he has been less than polite. But I know when he is coming from. If Linus was rude to me, I would be chuffed, because than I'd know I was good enough for him to reply to me, but that either I could have done better or that Linus was wrong. For example see the email exchange with the infamous Sarah Sharp https://lkml.org/lkml/2013/7/15/407. At the 2015 Australian Linux Conference, I watched as Sarah harangued Linus for over twenty minutes, Linus kept calm and polite throughout. So common words and phrases could be offensive to some people. Sometimes people just need to let of stream. You could end up with people being excessively polite to show their displeasure. Come across the expression "icely polite" -- it was a way of showing contempt while denying the victim any excuse for a deadly duel! Which would lead to the issue that people wouldn't always know if the politeness was real, or if it was intended to show disdain. Be very careful in attempting to codify 'correct' behaviour! Cheers, Gavin regards, tom lane [1] https://www.postgresql.org/message-id/56a8516b.8000...@agliodbs.com
Re: Code of Conduct plan
On Jun 3, 2018, at 16:08 , Gavin Flower wrote: > > Be very careful in attempting to codify 'correct' behaviour! +1 this is a distraction.
Re: Code of Conduct plan
Some people are not paying attention and are sending code-of-conduct comments to all lists, not just pgsql-general, but -hackers and -advocacy too. I've seen 3 of these so far today. This is a reminder to please send the comments to pgsql-general only. -- Darren Duncan On 2018-06-03 11:29 AM, Tom Lane wrote: We are now asking for a final round of community comments. Please send any public comments to the pgsql-general list (only). If you wish to make a private comment, you may send it to c...@postgresql.org.
Re: Code of Conduct plan
> On Jun 3, 2018, at 7:08 PM, Gavin Flower > wrote: > > On 04/06/18 07:32, Adrian Klaver wrote: >> On 06/03/2018 11:29 AM, Tom Lane wrote: >>> Two years ago, there was considerable discussion about creating a >>> Code of Conduct for the Postgres community, as a result of which >>> the core team announced a plan to create an exploration committee >>> to draft a CoC [1]. That process has taken far longer than expected, >>> but the committee has not been idle. They worked through many comments >>> and many drafts to produce a version that seems acceptable in the view >>> of the core team. This final(?) draft can be found at >>> >>> https://wiki.postgresql.org/wiki/Code_of_Conduct >>> >>> We are now asking for a final round of community comments. >>> Please send any public comments to the pgsql-general list (only). >>> If you wish to make a private comment, you may send it to >>> c...@postgresql.org. >>> >>> The initial membership of the CoC committee will be announced separately, >>> but shortly. >>> >>> Unless there are substantial objections, or nontrivial changes as a result >>> of this round of comments, we anticipate making the CoC official as of >>> July 1 2018. >> >> My comments: >> >> 1) Reiterate my contention that this is a solution is search of problem. >> Still it looks like it is going forward, so see below. >> >> 2) "... engaging in behavior that may bring the PostgreSQL project into >> disrepute, ..." >> This to me is overly broad and pulls in actions that may happen outside the >> community. Those if they are actually an issue should be handled where they >> occur not here. >> >> 3) "... members must be sensitive to conduct that may be considered >> offensive by fellow members and must refrain from engaging in such conduct. " >> Again overly broad, especially given the hypersensitivity of people these >> days. I have found that it is enough to disagree with someone to have it >> called offensive. This section should be removed as proscribed behavior is >> called out in detail in the paragraphs above it. > [truncated] > Be very careful in attempting to codify 'correct' behaviour! I believe the main goal of the CoC is the opposite: it’s to ensure that people do feel welcome to participate in the PostgreSQL community and that if they are unfortunately subject to an incident that they have a safe means of reporting it versus codifying what is “correct." There is also a committee around the CoC and why there will be multiple individuals on the committee, so that way any complaints can be fairly researched, discussed, and resolved. There are also several checks and balances with the enforcement of the CoC that should help ensure that any complaints are handled as fairly as possible. Anyway, a big +1 to the effort of everyone who worked on the CoC for the past several years. From feedback in other forums through the years, I know it does make a difference to have a code of conduct in terms of helping people to feel more welcome and knowing that there is an avenue for them to voice feedback in the case of an unfortunate incident. Jonathan
Re: Code of Conduct plan
On Sun, 03 Jun 2018 17:47:58 -0400, Tom Lane wrote: >Benjamin Scherrey writes: > >> Another more specific factual question - have there been incidents within >> the active Postgresql community where behaviour by individuals who are >> participants in the community have conducted themselves in a manner that >> brought on the actual need for such a code of conduct to exist in the first >> place? > >I believe there were a couple of unfortunate incidents at conferences. >Now, conferences are generally expected to have their own CoCs and enforce >them themselves; this CoC is meant more to cover on-line interactions. >You could argue that we shouldn't create such a CoC until something bad >happens on-line; but I'd prefer to think that having a CoC might prevent >that from ever happening at all, which is surely better. Unfortunately, conduct codes generally aren't worth the paper they are written on. People who are inclined to behave badly towards others in the 1st place will do so regardless of any code or any consequences of violating the code. The only thing a conduct code really accomplishes is to make some subset of the signers feel good about themselves. Actions are more important than words. YMMV. >In any case, we went over all these sorts of arguments at excruciating >length in 2016. It's quite clear to the core team that a majority of >the community wants a CoC. I don't think any useful purpose will be >served by re-litigating that point. > > regards, tom lane I remember that thread, but I don't remember any vote being taken. And the participants in the thread were self-selected for interest in the topic, so any consensus there is not necessarily reflective of the community at large. I am completely in favor of civil discourse and behavior, but I am not in favor of unenforcible red tape. Just my 2 cents. George
Re: [HACKERS] Code of Conduct plan
On Sunday, June 3, 2018, George Neuner wrote: > On Sun, 03 Jun 2018 17:47:58 -0400, Tom Lane > wrote: > > >Benjamin Scherrey writes: > > > >> Another more specific factual question - have there been incidents > within > >> the active Postgresql community where behaviour by individuals who are > >> participants in the community have conducted themselves in a manner that > >> brought on the actual need for such a code of conduct to exist in the > first > >> place? > > > >I believe there were a couple of unfortunate incidents at conferences. > >Now, conferences are generally expected to have their own CoCs and enforce > >them themselves; this CoC is meant more to cover on-line interactions. > >You could argue that we shouldn't create such a CoC until something bad > >happens on-line; but I'd prefer to think that having a CoC might prevent > >that from ever happening at all, which is surely better. > > Unfortunately, conduct codes generally aren't worth the paper they are > written on. People who are inclined to behave badly towards others in > the 1st place will do so regardless of any code or any consequences of > violating the code. I would say that such a generalization is itself of dubious value. The only thing a conduct code really accomplishes is to make some > subset of the signers feel good about themselves. Actions are more > important than words. It communicates that this community has a policing force, which itself is non-obvious and thus worth communicating, and provides that force guidelines for action. > >In any case, we went over all these sorts of arguments at excruciating > >length in 2016. It's quite clear to the core team that a majority of > >the community wants a CoC. I don't think any useful purpose will be > >served by re-litigating that point. > > > > regards, tom lane > > I remember that thread, but I don't remember any vote being taken. And > the participants in the thread were self-selected for interest in the > topic, so any consensus there is not necessarily reflective of the > community at large. That's pretty much par for the public dynamic of this community. And, as noted above, such a policy doesn't need the community at-large's approval: it's a document that constrains those that wrote it. > I am completely in favor of civil discourse and behavior, but I am not > in favor of unenforcible red tape. > The core team does have enforcement tools at its disposal. They are at least being open about the circumstances and extents under which they would leverage those tools. David J.
Re: VBA to connect to postgresql from MS Access
Thank you Adrian,
in answer to response in link:
This connection string is not working for me.
Ma macro is:
Public Sub InitConnect()
>
>
>> On Error GoTo ErrHandler
>
>
>> Dim dbCurrent As DAO.Database
>
> Dim qdf As DAO.QueryDef
>
> Dim rst As DAO.Recordset
>
> Dim cnn As Object
>
>
>
> Set cnn = CreateObject("Adodb.Connection")
>
>
>> sConnString = "DRIVER={PostgreSQL
>> Unicode(x64)};DATABASE=AccessTest;SERVER=localhost;PORT=5432;UID=postgres;PWD=1234;"
>
>
>
> cnn.Open sConnString
>
>
>
> Set dbCurrent = DBEngine(0)(0)
>
> Set qdf = dbCurrent.CreateQueryDef("")
>
>
>
> With qdf
>
> .Connect = sConnString
>
> .SQL = "select CURRENT_USER;"
>
> Set rst = .OpenRecordset(dbOpenSnapshot, dbSQLPassThrough)
>
> End With
>
>'' InitConnect = True
>
>
>> ExitProcedure:
>
> On Error Resume Next
>
> Set rst = Nothing
>
> Set qdf = Nothing
>
> Set dbCurrent = Nothing
>
> Exit Sub
>
> ErrHandler:
>
> ''InitConnect = False
>
> MsgBox Err.Description & " (" & Err.Number & ") encountered", _
>
> vbOKOnly + vbCritical, "InitConnect"
>
> Resume ExitProcedure
>
> Resume
>
> End Sub
>
>
And my conf file is in attachment.
Only this strange DSN less conn string is working:
ODBC;DSN=PostgreSQL35W;DATABASE=AccessTest;SERVER=localhost;
> PORT=5432;*CA=d;A7=100;B0=255;B1=8190;BI=0;C2=;CX=1c305008b;A1=7.4*
Why?
Best,
Jacek
2018-06-02 20:52 GMT+02:00 Adrian Klaver :
> On 06/02/2018 11:15 AM, Łukasz Jarych wrote:
>
>> Anyone?
>>
>
> https://www.postgresql.org/message-id/1527872841.3939.24.cam
> el%40bret.machinemanagement.com
>
>
>> Jacek
>>
>> 2018-06-01 14:21 GMT+02:00 Łukasz Jarych > jarys...@gmail.com>>:
>>
>> Hi Guys,
>>
>> When i have linked table based on DSN odbc connection to postgresql ,
>> i am going to :
>>
>> VBA editor, in immediate window inputing:
>>
>> ?CurrentDb.TableDefs("TableName").Connect
>> i have very strange connection string:
>>
>> ODBC;DSN=PostgreSQL35W;DATABASE=AccessTest;SERVER=localhost;
>> PORT=5432;*CA=d;A7=100;B0=255;B1=8190;BI=0;C2=;CX=1c305008b;A1=7.4*
>>
>>
>>
>> When i was searching code for this in internet i found only:
>>
>> DRIVER={PostgreSQL Unicode(x64)};DATABASE=AccessT
>> est;SERVER=localhost;PORT=5432;UID=postgres;PWD=1234;"
>>
>> but this is not working, why? I do not know what these CA, BO, BI
>> strange paramaters.
>>
>> I want to use VBA to relink all tables and use DSN less connection
>> string.
>>
>> Please help,
>> Best,
>> Jacek
>>
>>
>>
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
postgresql.conf
Description: Binary data
RE: Question on disk contention
Hi Melvin From: Melvin Davidson [mailto:melvin6...@gmail.com] Sent: Donnerstag, 31. Mai 2018 15:53 To: Charles Clavadetscher Cc: pgsql-generallists.postgresql.org Subject: Re: Question on disk contention On Thu, May 31, 2018 at 1:13 AM, Charles Clavadetscher mailto:clavadetsc...@swisspug.org> > wrote: Hi Melvin As an answer to a previous post you wrote: "Also, your main problem is that when you have two exact same queries executing at the same time, they will cause contention in the disk, and neither one will make much progress." Could you elaborate a little more on the meaning of "contention in the disk"? What is it that happens? Thank you and have a good day. Regards Charles >Could you elaborate a little more on the meaning of "contention in the disk"? >What is it that happens? To simplify, you have two users/jobs, both wanting the exact same information. So the system instructs the disk to get that information from the disk, which causes the disk head to "seek" to the position of the first eligible row and continues positioning to other eligible rows. Now the job is not exclusive, so the system temporarily switches to the other job, which causes the disk to go back to the first row and work from there. The switching back and forth continues, so that instead of one job finishing quickly, they both have to take turns waiting for needed information. That takes a lot longer, Try this, Select a table that has a lot of rows, ideally 1M+. Then start a query with a WHERE clause and see how long it takes. Then submit the same query from 5 separate connections simultaneously and see how long that takes. Thank you very much for your answer. Regards Charles -- Melvin Davidson Maj. Database & Exploration Specialist Universe Exploration Command – UXC Employment by invitation only!
