[Origami] Cellular Origami

[Scott Cramer]

This is an exciting discovery!

https://news.stanford.edu/stories/2024/06/the-first-example-of-cellular-origami

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

[Dave Cramer]

On Sat, 25 May 2024 at 06:40, Jelte Fennema-Nio  wrote:

> On Thu, 23 May 2024 at 20:12, Tom Lane  wrote:
> >
> > Jelte Fennema-Nio  writes:
> > > On Fri, 17 May 2024 at 21:24, Robert Haas 
> wrote:
> > >> Perhaps these are all minority positions, but I can't tell you what
> > >> everyone thinks, only what I think.
> >
> > > I'd love to hear some opinions from others on these design choices. So
> > > far it seems like we're the only two that have opinions on this (which
> > > seems hard to believe) and our opinions are clearly conflicting. And
> > > above all I'd like to move forward with this, be it my way or yours
> > > (although I'd prefer my way of course ;) )
> >
> > I got around to looking through this thread in preparation for next
> > week's patch review session.  I have a couple of opinions to offer:
> >
> > 1. Protocol versions suck.  Bumping them is seldom a good answer,
> > and should never be done if you have any finer-grained negotiation
> > mechanism available.  My aversion to this is over thirty years old:
> > I learned that lesson from watching the GIF87-to-GIF89 transition mess.
> > Authors of GIF-writing tools tended to take the easy way out and write
> > "GIF89" in the header whether they were actually using any of the new
> > version's features or not.  This led to an awful lot of pictures that
> > couldn't be read by available GIF-displaying tools, for no good reason
> > whatsoever.  The PNG committee, a couple years later, reacted to that
> > mess by designing PNG to have no version number whatsoever, and yet
> > be extensible in a fine-grained way.  (Basically, a PNG file is made
> > up of labeled chunks.  If a reader doesn't recognize a particular
> > chunk code, it can still tell whether the chunk is "critical" or not,
> > and thereby decide if it must give up or can proceed while ignoring
> > that chunk.)
> >
> > So overall, I have a strong preference for using the _pq_.xxx
> > mechanism instead of a protocol version bump.  I do not believe
> > the latter has any advantage.
>
> I'm not necessarily super opposed to only using the _pq_.xxx
> mechanism.


I find it interesting that up to now nobody has ever used this mechanism.


> I mainly think it's silly to have a protocol version number
> and then never use it. And I feel some of the proposed changes don't
> really benefit from being able to be turned on-and-off by themselves.
> My rule of thumb would be:
> 1. Things that a modern client/pooler would always request: version bump
> 2. Everything else: _pq_.xxx
>

Have to agree, why have a protocol version and then just not use it ?

>
> Of the proposed changes so far on the mailing list the only 2 that
> would fall under 1 imho are:
> 1. The ParameterSet message
> 2. Longer than 32bit secret in BackendKeyData
>
> I also don't think the GIF situation you describe translates fully to
> this discussion. We have active protocol version negotiation, so if a
> server doesn't support protocol 3.1 a client is expected to fall back
> to the 3.0 protocol when communicating.


Also agree. Isn't the point of having a version number to figure out what
features the client wants and subsequently the server can provide?

> Of course you can argue that a
> badly behaved client will fail to connect when it gets a downgrade
> request from the server, but that same argument can be made about a
> server not reporting support for a _pq_.xxx parameter that every
> modern client/pooler requests. So I don't think there's a practical
> difference in the problem you're describing.
>

+1

>
>
>
> But again if I'm alone in this, then I don't
>

I would prefer to see a well defined protocol handshaking mechanism rather
than some strange _pq.xxx dance.

Dave

Re: request for database identifier in the startup packet

[Dave Cramer]

On Thu, 9 May 2024 at 15:39, Robert Haas  wrote:

> On Thu, May 9, 2024 at 3:33 PM Dave Cramer  wrote:
> > On Thu, 9 May 2024 at 15:19, Robert Haas  wrote:
> >> On Thu, May 9, 2024 at 3:14 PM Andres Freund 
> wrote:
> >> > ISTM that you could just as well query the information you'd like
> after
> >> > connecting. And that's going to be a lot more flexible than having to
> have
> >> > precisely the right information in the startup message, and most
> clients not
> >> > needing it.
> >>
> >> I agree with this.
> >>
> > Well other than the extra round trip.
>
> I mean, sure, but we can't avoid that for everyone for everything.
> There might be some way of doing something like this with, for
> example, the infrastructure that was proposed to dynamically add stuff
> to the list of PGC_REPORT GUCs, if the values you need are GUCs
> already, or were made so. But I think it's just not workable to
> unconditionally add a bunch of things to the startup packet. It'll
> just grow and grow.
>

I don't think this is unconditional. These are real world situations where
having this information is useful.
That said, adding them everytime I ask for them would end up growing
uncontrollably. This seems like a decent discussion to have with others.

Dave

Re: request for database identifier in the startup packet

[Dave Cramer]

On Thu, 9 May 2024 at 15:19, Robert Haas  wrote:

> On Thu, May 9, 2024 at 3:14 PM Andres Freund  wrote:
> > ISTM that you could just as well query the information you'd like after
> > connecting. And that's going to be a lot more flexible than having to
> have
> > precisely the right information in the startup message, and most clients
> not
> > needing it.
>
> I agree with this.
>
> Well other than the extra round trip.

Thanks,
Dave

Re: request for database identifier in the startup packet

[Dave Cramer]

Dave Cramer


On Thu, 9 May 2024 at 12:22, Robert Haas  wrote:

> On Thu, May 9, 2024 at 8:06 AM Dave Cramer  wrote:
> > The JDBC driver is currently keeping a per connection cache of types in
> the driver. We are seeing cases where the number of columns is quite high.
> In one case Prevent fetchFieldMetaData() from being run when unnecessary. ·
> Issue #3241 · pgjdbc/pgjdbc (github.com) 2.6 Million columns.
> >
> > If we knew that we were connecting to the same database we could use a
> single cache across connections.
> >
> > I think we would require a server/database identifier in the startup
> message.
>
> I understand the desire to share the cache, but not why that would
> require any kind of change to the wire protocol.
>
> The server identity is actually useful for many things such as knowing
which instance of a cluster you are connected to.
For the cache however we can't use the IP address to determine which server
we are connected to as we could be connected to a pooler.
Knowing exactly which server/database makes it relatively easy to have a
common cache across connections. Getting that in the startup message seems
like a good place

Dave

request for database identifier in the startup packet

[Dave Cramer]

Greetings,

The JDBC driver is currently keeping a per connection cache of types in the
driver. We are seeing cases where the number of columns is quite high. In
one case Prevent fetchFieldMetaData() from being run when unnecessary. ·
Issue #3241 · pgjdbc/pgjdbc (github.com)
<https://github.com/pgjdbc/pgjdbc/issues/3241> 2.6 Million columns.

If we knew that we were connecting to the same database we could use a
single cache across connections.

I think we would require a server/database identifier in the startup
message.

Dave Cramer

Possible to include xid8 in logical replication

[Dave Cramer]

Greetings,

I've been asked by the debezium developers if it is possible to include
xid8 in the logical replication protocol. Are there any previous threads on
this topic?

Any reason why we wouldn't include the epoch ?

Dave Cramer

Bug#1070057: mutter: Severe keyboard input lag/pauses

[Florian Cramer]

Indeed, the update to mutter 46.1 solved the problem. Many thanks!

Florian

Bug#1070057: mutter: Severe keyboard input lag/pauses

[Florian Cramer]

Package: mutter
Version: 46.0-1
Severity: important
X-Debbugs-Cc: flrnc...@gmail.com

Dear Maintainer,

In all programs that rely on mutter and/or Gnome/GTK libraries for keyboard
input, I am experiencing severe keyboard input lag/pauses, sometimes for
several seconds. This might be a problem that only occurs in xorg with the
Nvidia driver, and is identical to what has been described here:
https://gitlab.gnome.org/GNOME/mutter/-/issues/3384


   * What led up to the situation?
Update from Gnome/mutter 45 to Gnomemutter 46.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

The problem occurs in Gnome-Terminal, but also XFCE4-Terminal and LXTerminal.
It can be mitigated by using xterm.



*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mutter depends on:
ii  adwaita-icon-theme46.0-1
ii  gnome-settings-daemon-common  46.0-1
ii  gsettings-desktop-schemas 46.0-1
ii  libc6 2.37-19
ii  libgles2  1.7.0-1+b1
ii  libglib2.0-0t64   2.80.0-7
ii  libmutter-14-046.0-1
ii  libwayland-client01.22.0-2.1+b1
ii  mutter-common 46.0-1
ii  zenity4.0.1-1+b1

mutter recommends no packages.

Versions of packages mutter suggests:
ii  gnome-control-center  1:46.0.1-1
ii  xdg-user-dirs 0.18-1

-- no debconf information

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

[Dave Cramer]

On Mon, 15 Apr 2024 at 15:38, Jelte Fennema-Nio  wrote:

> On Mon, 15 Apr 2024 at 19:43, Robert Haas  wrote:
> >
> > On Sat, Apr 6, 2024 at 6:14 PM Jelte Fennema-Nio  wrote:
> > > I think for clients/drivers, the work would generally be pretty
> > > minimal. For almost all proposed changes, clients can "support" the
> > > protocol version update by simply not using the new features, ...
> >
> > I mean, I agree if a particular protocol version bump does nothing
> > other than signal the presence of some optional, ignorable feature,
> > then it doesn't cause a problem if we force clients to support it. But
> > that seems a bit like saying that eating wild mushrooms is fine
> > because some of them aren't poisonous. The point is that if we roll
> > out two protocol changes, A and B, each of which requires the client
> > to make some change in order to work with the newer protocol version,
> > then using version numbers as the gating mechanism requires that the
> > client can't support the newer of those two changes without also
> > supporting the older one. Using feature flags doesn't impose that
> > constraint, which I think is a plus.
>
> I think we're in agreement here, i.e. it depends on the situation if a
> feature flag or version bump is more appropriate. I think the
> guidelines could be as follows:
> 1. For protocol changes that require "extremely minimal" work from
> clients & poolers: bump the protocol version.
> 2. For "niche" features that require some work from clients and/or
> poolers: use a protocol parameter feature flag.
> 3. For anything in between, let's discuss on the thread for that
> specific protocol change on the tradeoffs.
>

My first thought here is that all of the above is subjective and we will
end up discussing all of the above.
No real argument just an observation.

>
> On Mon, 15 Apr 2024 at 19:52, Robert Haas  wrote:
> > surely it can't be right to use protocol
> > version 3.0 to refer to a bunch of different things. But at the same
> > time, surely we don't want clients to start panicking and bailing out
> > when everything would have been fine.
>
> I feel like the ProtocolVersionNegotiation should make sure people
> don't panic and bail out. And if not, then feature flags won't help
> with this either. Because clients would then still bail out if some
> feature is not supported.
>

I don't think a client should ever bail out. They may not support something
but IMO bailing out is not an option.

Dave

>
>

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

[Dave Cramer]

>
>
> Plus, you've got all of the consequences for non-core drivers, which
> have to both add support for the new wire protocol - if they don't
> want to seem outdated and eventually obsolete - and also test that
> they're still compatible with all supported server versions.
> Connection poolers have the same set of problems. The whole thing is
> almost a hole with no bottom. Keeping up with core changes in this
> area could become a massive undertaking for lots and lots of people,
> some of whom may be the sole maintainer of some important driver that
> now needs a whole bunch of work.
>

We already have this in many places. Headers or functions change and
extensions have to fix their code.
catalog changes force drivers to change their code.
This argument blocks any improvement to the protocol. I don't think it's
unreasonable to expect maintainers to keep up.
We could make it easier by having a specific list for maintainers, but that
doesn't change the work.



> I'm not sure how much it improves things if we imagine adding feature
> flags to the existing protocol versions, rather than whole new
> protocol versions, but at least it cuts down on the assumption that
> adopting new features is mandatory, and that such features are
> cumulative. If a driver wants to support TDE but not protocol
> parameters or protocol parameters but not TDE, who are we to say no?
> If in supporting those things we bump the protocol version to 3.2, and
> then 3.3 fixes a huge performance problem, are drivers going to be
> required to add support for features they don't care about to get the
> performance fixes? I see some benefit in bumping the protocol version
> for major changes, or for changes that we have an important reason to
> make mandatory, or to make previously-optional features for which
> support has become in practical terms universal part of the base
> feature set. But I'm very skeptical of the idea that we should just
> handle as many things as possible via a protocol version bump. We've
> been avoiding protocol version bumps like the plague since forever,
> and swinging all the way to the other extreme doesn't sound like the
> right idea to me.
>

+1 for not swinging too far here. But I don't think it should be a non
starter.
Dave

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

[Dave Cramer]

On Fri, 5 Apr 2024 at 12:09, Jelte Fennema-Nio  wrote:

> On Fri, 5 Apr 2024 at 16:02, Robert Haas  wrote:
> > Often?
> >
> > I kind of hope that the protocol starts to evolve a bit more than it
> > has, but I don't want a continuous stream of changes. That will be
> > very hard to test and verify correctness, and a hassle for drivers to
> > keep up with, and a mess for compatibility.
>
> I definitely think protocol changes require a lot more scrutiny than
> many other things, given their hard/impossible to change nature.
>
> But I do think that we shouldn't be at all averse to the act of
> bumping the protocol version itself. If we have a single small
> protocol change in one release, then imho it's no problem to bump the
> protocol version. Bumping the version should be painless. So we
> shouldn't be inclined to push an already agreed upon protocol change
> to the next release, because there are some more protocol changes in
> the pipeline that won't make it in the current one.
>
> I don't think this would be any harder for drivers to keep up with,
> then if we'd bulk all changes together. If driver developers only want
> to support changes in bulk changes, they can simply choose not to
> support 3.1 at all if they want and wait until 3.2 to support
> everything in bulk then.
>
> > > So, what approach of checking feature support are you envisioning
> > > instead? A function for every feature?
> > > Something like SupportsSetProtocolParameter, that returns an error
> > > message if it's not supported and NULL otherwise. And then add such a
> > > support function for every feature?
> >
> > Yeah, something like that.
> > ...
> >
> > > I'm also not sure why you're saying a user is not entitled to this
> > > information. We already provide users of libpq a way to see the full
> > > Postgres version, and the major protocol version. I think allowing a
> > > user to access this information is only a good thing. But I agree that
> > > providing easy to use feature support functions is a better user
> > > experience in some cases.
> >
> > I guess that's a fair point. But I'm worried that if we expose too
> > much of the internals, we won't be able to change things later.
>
> I'll take a look at redesigning the protocol parameter stuff. To work
> with dedicated functions instead.
>
+1

>
> > I really intended the _pq_ prefix as a way of taking something out of
> > the GUC namespace, not as a part of the GUC namespace that users would
> > see. And I'm reluctant to go back on that. If we want to make
> > pg_protocol.${NAME} mean a wire protocol parameter, well maybe there's
> > something to that idea [insert caveats here]. But doesn't _pq_ look
> > like something that was intended to be internal? That's certainly how
> > I intended it.
>

Is this actually used in practice? If so, how ?

>
> I agree that _pq_ does look internal and doesn't clearly indicate that
> it's a protocol related change. But sadly the _pq_ prefix is the only
> one that doesn't error in startup packets, waiting another 5 years
> until pg_protocol is allowed in the startup packet doesn't seem like a
> reasonable solution either.
>
> How about naming the GUCs pg_protocol.${NAME}, but still requiring the
> _pq_ prefix in the StartupPacket. That way only client libraries would
> have to see this internal prefix and they could remap it someway. I
> see two options for that:
> 1. At the server replace the _pq_ prefix with pg_protocol. So
> _pq_.${NAME} would map to pg_protocol.${name}
> 2. At the server replace the _pq_.pg_protocol prefix with pg_protocol.
> So _pq_.pg_protocol.${NAME} would map to pg_protocol.${name}.
>
> I guess you prefer option 2, because that would still leave lots of
> space to do something with the rest of the _pq_ space, i.e.
> _pq_.magic_pixie_dust can still be used for something different than a
> GUC.
>
> Bikeshedding: I think I prefer protocol.${NAME} over
> pg_protocol.${NAME}, it's shorter and it seems obvious that protocol
> is the postgres protocol in this context.
>
> This should be a fairly simple change to make.
>
> > Wouldn't libpq already know what value it last set? Or is this needed
> > because it doesn't know what the other side's default is?
>
> libpq could/should indeed know this, but for debugging/testing
> purposes it is quite useful to have a facility to read the server side
> value. I think defaults should always be whatever was happening if the
> parameter wasn't specified before, so knowing the server default is
> not something the client needs to worry about (i.e. the default is
> defined as part of the protocol spec).
>
> > Hmm, OK. I guess if the PGC_PROTOCOL flag makes it so that the GUC can
> > only be set using ParameterSet, and it also makes them
> > non-transactional, then it's fine. So to be clear, I can't set these
> > in postgresql.conf, or postgresql.auto.conf, or via ALTER $ANYTHING,
> > or via SET, or in any other way than by sending ParameterStatus
> > messages. And when I send a 

Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

[Dave Cramer]

On Thu, 4 Apr 2024 at 12:45, Jelte Fennema-Nio  wrote:

> On Thu, 4 Apr 2024 at 14:50, Peter Eisentraut 
> wrote:
> > It appears there are several different perspectives about this.  My
> > intuition was that a protocol version change indicates something that we
> > eventually want all client libraries to support.  Whereas protocol
> > extensions are truly opt-in.
> >
> > For example, if we didn't have the ParameterStatus message and someone
> > wanted to add it, then this ought to be a protocol version change, so
> > that we eventually get everyone to adopt it.
> >
> > But, for example, the column encryption feature is not something I'd
> > expect all client libraries to implement, so it can be opt-in.
>
> I think that is a good way of deciding between version bump vs
> protocol extension parameter. But I'd like to make one
> clarification/addition to this logic, if the protocol feature already
> requires opt-in from the client because of how the feature works, then
> there's no need for a protocol extension parameter. e.g. if you're
> column-encryption feature would require the client to send a
> ColumnDecrypt message before the server would exhibit any behaviour
> relating to the column-encryption feature, then the client can simply
> "support" the feature by never sending the ColumnDecrypt message.
> Thus, in such cases a protocol extension parameter would not be
> necessary, even if the feature is considered opt-in.
>
> > (I believe we have added a number of new protocol messages since the
> > beginning of the 3.0 protocol, without any version change, so "new
> > protocol message" might not always be a good example to begin with.)
>
> Personally, I feel like this is something we should change. IMHO, we
> should get to a state where protocol minor version bumps are so
> low-risk that we can do them whenever we add message types. Right now
> there are basically multiple versions of the 3.0 protocol, which is
> very confusing to anyone implementing it. Different servers
> implementing the 3.0 protocol without the NegotiateVersion message is
> a good example of that.
>

Totally agree.


>
> > I fear that if we prefer protocol extensions over version increases,
> > then we'd get a very fragmented landscape of different client libraries
> > supporting different combinations of things.
>
> +1
Dave

> +1
>

Re: incorrect results and different plan with 2 very similar queries

[Dave Cramer]

Dave Cramer


On Wed, 27 Mar 2024 at 17:57, David Rowley  wrote:

> On Thu, 28 Mar 2024 at 10:33, Dave Cramer  wrote:
> > There is a report on the pgjdbc github JDBC Driver shows erratic
> behavior when filtering on CURRENT_DATE · pgjdbc/pgjdbc · Discussion #3184 (
> github.com)
> >
> > Here are the plans.
> >
> > JDBC - Nested Loop (incorrect result)
> >
> > Index Cond: (mutation >= ((CURRENT_DATE -
> '1971-12-31'::date) - 28))
>
> > JDBC - Hash Right (correct result)
> >
> > Recheck Cond: (mutation >= ((CURRENT_DATE -
> '1971-12-31'::date) - 29))
>
> I don't see any version details or queries, but going by the
> conditions above, the queries don't appear to be the same, so
> different results aren't too surprising and not a demonstration that
> there's any sort of bug.
>

Sorry, you are correct. Version is 12.14. Here is the query

SELECT
  p.partseqno_i
, p.partno
, p.partmatch
, pfe.average_price
, pfe.sales_price
, pfe.purch_price
, pfe.average_price_2
, pfe.avg_repair_cost
, pfe.average_price_func
, pfe.fsv
, pfe.fsv_func
, p.status

FROM part p
LEFT JOIN part_fa_entity pfe ON (p.partno = pfe.partno)
WHERE 1=1
AND (p.mutation >= (CURRENT_DATE - '1971-12-31'::date)-27) ORDER BY p.partno

Dave


> David
>

incorrect results and different plan with 2 very similar queries

[Dave Cramer]

fsv, pfe.fsv_func
  Index Cond: ((pfe.partno)::text = (p.partno)::text)
Planning Time: 0.361 ms
Execution Time: 3.157 ms

AppX - Hash Join (correct result)

Sort  (cost=1352.35..1352.94 rows=238 width=83) (actual time=5.361..5.384
rows=345 loops=1)
  Output: p.partseqno_i, p.partno, p.partmatch, pfe.average_price,
pfe.sales_price, pfe.purch_price, pfe.average_price_2, pfe.avg_repair_cost,
pfe.average_price_func, pfe.fsv, pfe.fsv_func, p.status
  Sort Key: p.partno
  Sort Method: quicksort  Memory: 73kB
  ->  Hash Right Join  (cost=472.00..1342.95 rows=238 width=83) (actual
time=0.594..4.669 rows=345 loops=1)
Output: p.partseqno_i, p.partno, p.partmatch, pfe.average_price,
pfe.sales_price, pfe.purch_price, pfe.average_price_2, pfe.avg_repair_cost,
pfe.average_price_func, pfe.fsv, pfe.fsv_func, p.status
Inner Unique: true
Hash Cond: ((pfe.partno)::text = (p.partno)::text)
->  Seq Scan on amos.part_fa_entity pfe  (cost=0.00..837.27
rows=12827 width=65) (actual time=0.006..1.581 rows=12827 loops=1)
  Output: pfe.part_fa_entityno_i, pfe.partno, pfe.entityno_i,
pfe.average_price, pfe.sales_price, pfe.purch_price, pfe.average_price_2,
pfe.avg_repair_cost, pfe.avg_repair_cost_func, pfe.fa_qty,
pfe.fa_open_iv_qty, pfe.fa_start_qty, pfe.fa_start_price,
pfe.fa_start_price_2, pfe.mutation, pfe.mutator, pfe.status,
pfe.mutation_time, pfe.created_by, pfe.created_date,
pfe.average_price_func, pfe.fa_start_price_func, pfe.fsv, pfe.fsv_func
->  Hash  (cost=469.03..469.03 rows=238 width=29) (actual
time=0.564..0.566 rows=345 loops=1)
  Output: p.partseqno_i, p.partno, p.partmatch, p.status
  Buckets: 1024  Batches: 1  Memory Usage: 30kB
  ->  Bitmap Heap Scan on amos.part p  (cost=18.14..469.03
rows=238 width=29) (actual time=0.075..0.488 rows=345 loops=1)
Output: p.partseqno_i, p.partno, p.partmatch, p.status
Recheck Cond: (p.mutation >= ((CURRENT_DATE -
`1971-12-31`::date) - 29))
Heap Blocks: exact=186
->  Bitmap Index Scan on i_42609  (cost=0.00..18.08
rows=238 width=0) (actual time=0.035..0.035 rows=356 loops=1)
  Index Cond: (p.mutation >= ((CURRENT_DATE -
`1971-12-31`::date) - 29))
Planning Time: 0.379 ms
Execution Time: 5.443 ms
<https://github.com/pgjdbc/pgjdbc/discussions/3184>

Dave Cramer

Re: Trying to build x86 version on windows using meson

[Dave Cramer]

Andres,


On Thu, 21 Mar 2024 at 12:51, Andres Freund  wrote:

> Hi,
>
> On 2024-03-21 07:11:23 -0400, Dave Cramer wrote:
> > It seems that attempting to cross-compile on an ARM machine might be
> asking
> > too much as the use cases are pretty limited.
>
> It for sure is if you don't even provide the precise commands and logs of a
> failed run...
>
>
> > So the impetus for this is that folks require 32bit versions of psqlODBC.
> > Unfortunately EDB is no longer distributing a 32 bit windows version.
> >
> > All I really need is a 32bit libpq. This seems like a much smaller lift.
> > Suggestions ?
>
> FWIW, I can cross compile postgres from linux to 32bit windows without an
> issue. If you really just need a 32bit libpq, that might actually be
> easier.
>
> cd /tmp/ && rm -rf /tmp/meson-w32 && m setup --buildtype debug
> -Dcassert=true -Db_pch=true --cross-file
> ~/src/meson/cross/linux-mingw-w64-32bit.txt /tmp/meson-w32 ~/src/postgresql
> && cd /tmp/meson-w32 && ninja
>
> file src/interfaces/libpq/libpq.dll
> src/interfaces/libpq/libpq.dll: PE32 executable (DLL) (console) Intel
> 80386, for MS Windows, 19 sections
>
> You'd need a windows openssl to actually have a useful libpq, but that
> should
> be fairly simple.
>
>
> There are two warnings that I think point to us doing something wrong, but
> they're not affecting libpq:
>
> [1585/1945 42  81%] Linking target src/bin/pgevent/pgevent.dll
> /usr/bin/i686-w64-mingw32-ld: warning: resolving _DllRegisterServer by
> linking to _DllRegisterServer@0
> Use --enable-stdcall-fixup to disable these warnings
> Use --disable-stdcall-fixup to disable these fixups
> /usr/bin/i686-w64-mingw32-ld: warning: resolving _DllUnregisterServer by
> linking to _DllUnregisterServer@0
>
>
>
Attached correct log file

Dave
Build started at 2024-03-21T13:07:08.707715
Main binary: C:\Program Files\Meson\meson.exe
Build Options: '-Dextra_include_dirs=c:\Program Files\OpenSSL-Win64\include' 
-Derrorlogs=True '-Dextra_lib_dirs=c:\Program Files\OpenSSL-win64' 
'-Dprefix=c:\postgres86'
Python system: Windows
The Meson build system
Version: 1.3.1
Source dir: C:\Users\davec\projects\postgresql
Build dir: C:\Users\davec\projects\postgresql\build
Build type: native build
Project name: postgresql
Project version: 17devel
---
Detecting compiler via: `icl ""` -> [WinError 2] The system cannot find the 
file specified
---
Detecting compiler via: `cl /?` -> 0
stdout:
C/C++ COMPILER OPTIONS


  -OPTIMIZATION-

/O1 maximum optimizations (favor space) /O2 maximum optimizations (favor speed)
/Ob inline expansion (default n=0)   /Od disable optimizations (default)
/Og enable global optimization  /Oi[-] enable intrinsic functions
/Os favor code space/Ot favor code speed
/Ox optimizations (favor speed) /Oy[-] enable frame pointer omission 
/favor: select processor to optimize for, one of:
blend - a combination of optimizations for several different x86 processors
ATOM - Intel(R) Atom(TM) processors 

 -CODE GENERATION-

/Gu[-] ensure distinct functions have distinct addresses
/Gw[-] separate global variables for linker
/GF enable read-only string pooling /Gm[-] enable minimal rebuild
/Gy[-] separate functions for linker/GS[-] enable security checks
/GR[-] enable C++ RTTI  /GX[-] enable C++ EH (same as /EHsc)
/guard:cf[-] enable CFG (control flow guard)
/guard:ehcont[-] enable EH continuation metadata (CET)
/EHs enable C++ EH (no SEH exceptions)  /EHa enable C++ EH (w/ SEH exceptions)
/EHc extern "C" defaults to nothrow 
/EHr always generate noexcept runtime termination checks
/fp: choose floating-point model:
contract - consider floating-point contractions when generating code
except[-] - consider floating-point exceptions when generating code
fast - "fast" floating-point model; results are less predictable
precise - "precise" floating-point model; results are predictable
strict - "strict" floating-point model (implies /fp:except)
/Qfast_transcendentals generate inline FP intrinsics even with /fp:except
/Qspectre[-] enable mitigations for CVE 2017-5753
/Qpar[-] enable parallel code generation
/Qpar-report:1 auto-parallelizer diagnostic; indicate parallelized loops
/Qpar-report:2 auto-parallelizer diagnostic; indicate loops not parallelized
/Qvec-report:1 auto-vectorizer diagnostic; indicate vectorized loops
/Qvec-report:2 auto-vectorizer diagnostic; indicate loops not vectorized
/GL[-] enable link-time code generation 
/volatile: choose volatile model:
iso - Acquire/release semantics not guaranteed on volatile accesses
ms  - Acquire/release semantics guaranteed on volatile accesses

Re: Trying to build x86 version on windows using meson

[Dave Cramer]

On Thu, 21 Mar 2024 at 03:56, Peter Eisentraut  wrote:

> On 20.03.24 22:49, Dave Cramer wrote:
> >
> >
> >
> > On Wed, 20 Mar 2024 at 17:11, Andres Freund  > <mailto:and...@anarazel.de>> wrote:
> >
> > Hi,
> >
> > On 2024-03-20 16:14:23 -0400, Dave Cramer wrote:
> >  > I am getting the following error
> >  >
> >  > meson.build:1479:17: ERROR: Can not run test applications in this
> > cross
> >  > environment.
> >  >
> >  > Have configured for amd64_x86
> >  >
> >  > Running `meson setup --wipe build --prefix=c:\postgres86`
> >
> > This is not enough information to debug anything. At the very least
> > we need
> > the exact steps performed to set up the build and
> > meson-logs/meson-log.txt
> >
> > First off this is on an ARM64 machine
> >
> > The last error from meson-log.txt is
> >
> > ...
> > Checking if "c99" compiles: YES
> >
> > meson.build:1479:17: ERROR: Can not run test applications in this cross
> > environment.
> > ...
>
> I have never tried this, but there are instructions for cross-compiling
> with meson: https://mesonbuild.com/Cross-compilation.html


It seems that attempting to cross-compile on an ARM machine might be asking
too much as the use cases are pretty limited.

So the impetus for this is that folks require 32bit versions of psqlODBC.
Unfortunately EDB is no longer distributing a 32 bit windows version.

All I really need is a 32bit libpq. This seems like a much smaller lift.
Suggestions ?

Dave

Trying to build x86 version on windows using meson

[Dave Cramer]

Greetings,

I am getting the following error

meson.build:1479:17: ERROR: Can not run test applications in this cross
environment.

Have configured for amd64_x86

Running `meson setup --wipe build --prefix=c:\postgres86`

The docs say it is possible to build postgres for x86. Are there specific
instructions ?


Dave Cramer

Re: Monetary Data Types Improvement

[Dave Cramer]

On Wed, 20 Mar 2024 at 10:59, Erik Wienhold  wrote:

> On 2024-03-18 23:24 +0100, David Rowley wrote:
> > My vote would go to adding a deprecation notice to that section of the
> > docs.  There's some talk [1] about how we discourage the usage of the
> > money type and that goes on to discuss the possibilities of moving it
> > into a contrib module.
> >
> > My hope would be that deprecation notice would steer most people away
> > from using it and therefore reduce the number of questions about it
> > due to fewer new use cases of it.
> >
> > [1] https://www.postgresql.org/message-id/zxgh74ykj3iwv...@paquier.xyz
>
> +1
>
> Huh, I didn't know that it used to have a deprecation notice at some
> point.  But that note was removed in 8.3:
>
>
> https://www.postgresql.org/message-id/20071009123315.5fb283c1.darcy%40druid.net
>
>
Sadly that was a mistake. Money is not really a useful type.

Dave

Re: query_id, pg_stat_activity, extended query protocol

[Dave Cramer]

>
>
>>
>> FWIW, I'd like to think that we could improve the situation, requiring
>> a mix of calling pgstat_report_query_id() while feeding on some query
>> IDs retrieved from CachedPlanSource->query_list.  I have not in
>> details looked at how much could be achieved, TBH.
>>
>
This just cropped up as a pgjdbc github issue. Seems like something that
should be addressed.

Dave

Re: [RBW] Re: FS: Roadini 50cm

[Ron Cramer]

Sorry for the confusion. By mistake I  ended up submitting two emails: one
with the picture and one with the price. $1300, includes professional
packing by my LBS.  Buyer pays for shipping by Bikeflights.

On Tue, Mar 12, 2024, 2:16 PM Greg J  wrote:

> price?
>
> On Tuesday, March 12, 2024 at 1:15:47 PM UTC-7 Doug H. wrote:
>
>> How was the ride? Looks like it has lots of elevation. How did you like
>> the Roadini?
>> Doug
>>
>> On Tuesday, March 12, 2024 at 1:40:04 PM UTC-4 cramer@gmail.com
>> wrote:
>>
>>> Impulse buy,  built it up last year to ride the Triple Bypass.  Maybe
>>> 250 miles on it. No dents, but a  small chip on the chainstay.
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/f515f7b2-3bed-4310-9e4c-8a8782f3b5b7n%40googlegroups.com
> <https://groups.google.com/d/msgid/rbw-owners-bunch/f515f7b2-3bed-4310-9e4c-8a8782f3b5b7n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5cb0BgFRx0gDV4mcpYq77NFUVO9H7h%2BrXj%3DTe0BmX00qA%40mail.gmail.com.

Re: [RBW] Re: FS: Roadini 50cm

[Ron Cramer]

Great weather this year, we were lucky.  Roadini road wonderful. The only
reason I am selling it is because (as my wife pointed out) it is the
functional equivalent of my Rambouillet. Doh!

On Tue, Mar 12, 2024, 2:15 PM Doug H.  wrote:

> How was the ride? Looks like it has lots of elevation. How did you like
> the Roadini?
> Doug
>
> On Tuesday, March 12, 2024 at 1:40:04 PM UTC-4 cramer@gmail.com wrote:
>
>> Impulse buy,  built it up last year to ride the Triple Bypass.  Maybe 250
>> miles on it. No dents, but a  small chip on the chainstay.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/64f59dce-e4cf-47f7-9b09-abb34b6ccc86n%40googlegroups.com
> <https://groups.google.com/d/msgid/rbw-owners-bunch/64f59dce-e4cf-47f7-9b09-abb34b6ccc86n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5cJw5%2BE-AXVcXqm9PE%2BvA6Em_pXbMfa9r-i%2BfJQvG1N3w%40mail.gmail.com.

[RBW] 50cm Roadini (cont)

[Ron Cramer]

Hit send by accident.  $1300. Buyer pays shipping.

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5fjZ4Vz5_KL0eean9UBDWUfVcWq4rRey2n0DjsY0hT68Q%40mail.gmail.com.

Re: [RBW] Re: FS; 48cm 2012 Sam Hillborne

[Ron Cramer]

Thanks for the clarification.  Sorry for wasting your time.  I'm looking
for cantilever brakes. Good luck with your sale. Happy Trails!

On Sun, Mar 3, 2024, 4:02 PM Tommy Love  wrote:

> I'm not quite sure how this happened, but the link to the photos in my
> original are not of my bike.  I usually use dropbox but linked a google
> drive link and most likely this was user error, sorry for the confusion.
> Proper link below.
> Tommy
>
> https://drive.google.com/drive/folders/1Wneod4wV75VoE_vRXw4Fqq0TSJKWelG-?usp=share_link
>
>
> On Saturday, March 2, 2024 at 10:59:04 AM UTC-8 Tommy Love wrote:
>
>> This Sam Hillborne is in incredible shape for it's age.  Everything is in
>> perfect working condition and cosmetically, it is really nice.  Frame is a
>> 9 outta 10 (have added photos of the only meaningful blems on the frame),
>> all components in great shape, ready to ride.  Geo attached in photos, but
>> quickly;
>> *C-T* = 19"
>> *C-C* = 18.5"
>> *Top tube* = 21.5"
>> *Stand over height* = 29.5"
>>
>> $1800 complete, buyer pays for shipping.  Located in Southern CA
>> Not preferred, but selling frameset only could also be a discussion.
>> Lastly, a trade could be an option as well.  Size 53,54 Rivendell only.
>> Atlantis or older fun rivbike are most interesting to me.
>>
>> *2012 Sam Hillborne Serial M1220577 Made in Taiwan*
>> - Velocity Synergy 650b wheels laced to Velocity hubs, with Maxy Fasty
>> 32mm tires, all in great shape.  Tires have normal wear, but good condition
>> and plenty of life left
>> - Nitto Dirt drop stem with stem mounted shifters
>> - Modolo Q Race drop bars made in Italy, shellac'd & twined.
>> - Tektro RL-720 brake levers, joined to TRP hood levers
>> - Tektro R559 capliper brakes
>> - Elite bottle cages
>> - Velo Orange seat post
>> - Brooks Cambium C17 saddle
>> - Shimano Deore LX crankset
>> - Shimano Deore XT front and rear derailer
>> - MKS Sylvan pedals
>>
>> *PICTURES OF BIKE HERE*
>>
>> https://drive.google.com/drive/folders/1Lcrtaogb4u8tOARV8RzyX6b1gtR0KOfp?usp=share_link
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/8b3e3c4e-affe-4683-9ab1-5bfe8d9e1889n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5c4PVzfHdX4hpZKM4eywo%3DziNrKm_QKmqu8G7SGXGo15g%40mail.gmail.com.

Re: Q: rpki feed failure

[Matthias Cramer via Bird-users]

Hi Elmar

Is using a public RPKI Cache for production networks relay a good idea? 
It's very easy to run your own with eg. Routinator 3000 
https://nlnetlabs.nl/projects/routing/routinator/


Regards

  Matthias

On 29/02/2024 09:48, Elmar K. Bins via Bird-users wrote:

Hi friends,

a probably simple question that I haven't found any documentation about, so...

We're using Cloudflare's RPKI cache from our BIRD instances, but since
yesterday I'm getting an error info in `show protocols`:

rpki1  RPKI   ---up 15:33:17.594 
Cache-Error-No-Data-Available

What does the error message mean? Does the remote side not have data available,
or is this about some local issue?

I'd like to clear this up before I ask Cloudflare...

Thanks,
 Elmar.

Re: When extended query protocol ends?

[Dave Cramer]

Hi Tatsuo,

Actually no need, I figured it out.

I don't have a solution yet though.

Dave Cramer
www.postgres.rocks


On Thu, 15 Feb 2024 at 19:43, Tatsuo Ishii  wrote:

> > Can you ask the OP what they are doing in the startup. I'm trying to
> > replicate their situation.
> > Looks like possibly 'setReadOnly' and 'select version()'
>
> Sure I will. By the way 'select version()' may be issued by Pgpool-II
> itself. In this case it should be 'SELECT version()', not 'select
> version()'.
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
>

Re: When extended query protocol ends?

[Dave Cramer]

On Wed, 14 Feb 2024 at 17:55, Tatsuo Ishii  wrote:

> >>> From [1] I think the JDBC driver sends something like below if
> >>> autosave=always option is specified.
> >>>
> >>> "BEGIN READ ONLY" Parse/Bind/Eexecute (in the extended query protocol)
> >>> "SAVEPOINT PGJDBC_AUTOSAVE" (in the simple query protocol)
> >>>
> >>> It seems the SAVEPOINT is sent without finishing the extended query
> >>> protocol (i.e. without Sync message). Is it possible for the JDBC
> >>> driver to issue a Sync message before sending SAVEPOINT in simple
> >>> query protocol? Or you can send SAVEPOINT using the extended query
> >>> protocol.
> >>>
> >>> [1]
> >>>
> https://www.pgpool.net/pipermail/pgpool-general/2023-December/009051.html
> >>
> >>
> >> Can you ask the OP what version of the driver they are using. From what
> I
> >> can tell we send BEGIN using SimpleQuery.
> >
> > Sure. I will get back once I get the JDBC version.
>
> Here it is:
> > JDBC driver version used:42.5.1 Regards, Karel.
>

Can you ask the OP what they are doing in the startup. I'm trying to
replicate their situation.
Looks like possibly 'setReadOnly' and 'select version()'

Thanks,
Dave

>
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 13 Feb 2024 at 12:52, Andres Freund  wrote:

> Hi,
>
> On 2024-02-13 12:49:33 -0500, Dave Cramer wrote:
> > > I think I might have been on to something - if my human emulation of a
> > > preprocessor isn't wrong, we'd end up with
> > >
> > > #define S_UNLOCK(lock)  \
> > > do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)
> > >
> > > on msvc + arm. And that's entirely insufficient - _ReadWriteBarrier()
> just
> > > limits *compiler* level reordering, not CPU level reordering.  I think
> it's
> > > even insufficient on x86[-64], but it's definitely insufficient on arm.
> > >
> > In fact ReadWriteBarrier has been deprecated _ReadWriteBarrier |
> Microsoft
> > Learn
> > <
> https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170
> >
>
> I'd just ignore that, that's just pushing towards more modern stuff that's
> more applicable to C++ than C.
>
>
> > I did try using atomic_thread_fence as per atomic_thread_fence -
> > cppreference.com
> > <https://en.cppreference.com/w/c/atomic/atomic_thread_fence>
>
> The semantics of atomic_thread_fence are, uh, very odd.  I'd just use
> MemoryBarrier().
>
> #define S_UNLOCK(lock)  \
do { MemoryBarrier(); (*(lock)) = 0; } while (0)

#endif

Has no effect.

I have no idea if that is what you meant that I should do ?

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Mon, 12 Feb 2024 at 16:19, Andres Freund  wrote:

> Hi,
>
> On 2024-02-12 12:50:12 -0800, Andres Freund wrote:
> > On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote:
> > I wonder if this indicates that we are either missing memory barriers
> > somewhere or that the memory barriers we end up with on msvc + arm aren't
> > correct?  Either could explain why the problem doesn't occur when
> building
> > with optimizations.
>
> I think I might have been on to something - if my human emulation of a
> preprocessor isn't wrong, we'd end up with
>
> #define S_UNLOCK(lock)  \
> do { _ReadWriteBarrier(); (*(lock)) = 0; } while (0)
>
> on msvc + arm. And that's entirely insufficient - _ReadWriteBarrier() just
> limits *compiler* level reordering, not CPU level reordering.  I think it's
> even insufficient on x86[-64], but it's definitely insufficient on arm.
>
In fact ReadWriteBarrier has been deprecated _ReadWriteBarrier | Microsoft
Learn
<https://learn.microsoft.com/en-us/cpp/intrinsics/readwritebarrier?view=msvc-170>

I did try using atomic_thread_fence as per atomic_thread_fence -
cppreference.com
<https://en.cppreference.com/w/c/atomic/atomic_thread_fence>


However for some reason including #include 
causes a bunch of compiler errors.

c:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36):
error C2061: syntax error: identifier 'atomic_bool'

Dave

Re: When extended query protocol ends?

[Dave Cramer]

HI Tatsuo,



On Mon, 29 Jan 2024 at 20:15, Tatsuo Ishii  wrote:

> Hello Dave,
>
> > Tatsuo Ishii  writes:
> >> Below is outputs from "pgproto" command coming with Pgpool-II.
> >> (Lines starting "FE" represents a message from frontend to backend.
> >> Lines starting "BE" represents a message from backend to frontend.)
> >
> >> FE=> Parse(stmt="", query="SET extra_float_digits = 3")
> >> FE=> Bind(stmt="", portal="")
> >> FE=> Execute(portal="")
> >> FE=> Parse(stmt="", query="SET extra_float_digits = 3")
> >> FE=> Bind(stmt="", portal="")
> >> FE=> Execute(portal="")
> >> FE=> Query (query="SET extra_float_digits = 3")
> >> <= BE ParseComplete
> >> <= BE BindComplete
> >> <= BE CommandComplete(SET)
> >> <= BE ParseComplete
> >> <= BE BindComplete
> >> <= BE CommandComplete(SET)
> >> <= BE CommandComplete(SET)
> >> <= BE ReadyForQuery(I)
> >> FE=> Terminate
> >
> >> As you can see, two "SET extra_float_digits = 3" is sent in the
> >> extended query protocol, then one "SET extra_float_digits = 3" follows
> >> in the simple query protocol. No sync message is sent. However, I get
> >> ReadyForQuery at the end. It seems the extended query protocol is
> >> ended by a simple query protocol message instead of a sync message.
> >
> >> My question is, is this legal in terms of fronted/backend protocol?
> >
> > I think it's poor practice, at best.  You should end the
> > extended-protocol query cycle before invoking simple query.
>
> From [1] I think the JDBC driver sends something like below if
> autosave=always option is specified.
>
> "BEGIN READ ONLY" Parse/Bind/Eexecute (in the extended query protocol)
> "SAVEPOINT PGJDBC_AUTOSAVE" (in the simple query protocol)
>
> It seems the SAVEPOINT is sent without finishing the extended query
> protocol (i.e. without Sync message). Is it possible for the JDBC
> driver to issue a Sync message before sending SAVEPOINT in simple
> query protocol? Or you can send SAVEPOINT using the extended query
> protocol.
>
> [1]
> https://www.pgpool.net/pipermail/pgpool-general/2023-December/009051.html


Can you ask the OP what version of the driver they are using. From what I
can tell we send BEGIN using SimpleQuery.

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Mon, 12 Feb 2024 at 15:50, Andres Freund  wrote:

> Hi,
>
> On 2024-02-12 13:28:40 -0500, Andrew Dunstan wrote:
> > On 2024-02-12 Mo 11:44, Dave Cramer wrote:
> > > OK, so I have managed to get a debugger attached to postgres.exe when
> it
> > > faults and the fault occurs at
> > >
> https://github.com/postgres/postgres/blob/09eb633e1baa3b7cd7929f3cc77f9c46f63c20b1/src/backend/utils/mmgr/dsa.c#L869
> > > span is pointing to 0x0
> >
> > Further data point. If I select a build type of 'debug' instead of
> > 'debugoptimized' the error disappears.
>
> Oh, this is quite interesting.  Dave, could you post the backtrace?
>

Andres,

I am using Visual Studio as the debugger. Here is what I have.

> postgres.exe!dsa_free(dsa_area * area, unsigned __int64 dp) Line 869 C
  postgres.exe!resize(dshash_table * hash_table, unsigned __int64
new_size_log2) Line 879 C
  postgres.exe!dshash_find_or_insert(dshash_table * hash_table, const void
* key, bool * found) Line 480 C
  postgres.exe!pgstat_get_entry_ref(PgStat_Kind kind, unsigned int dboid,
unsigned int objoid, bool create, bool * created_entry) Line 455 C
  postgres.exe!pgstat_prep_pending_entry(PgStat_Kind kind, unsigned int
dboid, unsigned int objoid, bool * created_entry) Line 1123 C
  [Inline Frame] postgres.exe!pgstat_prep_relation_pending(unsigned int)
Line 904 C
  postgres.exe!pgstat_assoc_relation(RelationData * rel) Line 139 C
  [Inline Frame] postgres.exe!ReadBufferExtended(RelationData *) Line 802 C
  postgres.exe!ReadBuffer(RelationData * reln, unsigned int blockNum) Line
737 C
  postgres.exe!read_seq_tuple(RelationData * rel, int * buf, HeapTupleData
* seqdatatuple) Line 1196 C
  postgres.exe!AlterSequence(ParseState * pstate, AlterSeqStmt * stmt) Line
481 C
  postgres.exe!ProcessUtilitySlow(ParseState * pstate, PlannedStmt * pstmt,
const char * queryString, ProcessUtilityContext context, ParamListInfoData
* params, QueryEnvironment * queryEnv, _DestReceiver * dest,
QueryCompletion * qc) Line 1679 C
  postgres.exe!standard_ProcessUtility(PlannedStmt * pstmt, const char *
queryString, bool readOnlyTree, ProcessUtilityContext context,
ParamListInfoData * params, QueryEnvironment * queryEnv, _DestReceiver *
dest, QueryCompletion * qc) Line 1080 C
  postgres.exe!ProcessUtility(PlannedStmt * pstmt, const char *
queryString, bool readOnlyTree, ProcessUtilityContext context,
ParamListInfoData * params, QueryEnvironment * queryEnv, _DestReceiver *
dest, QueryCompletion * qc) Line 530 C
  postgres.exe!ProcessUtilitySlow(ParseState * pstate, PlannedStmt * pstmt,
const char * queryString, ProcessUtilityContext context, ParamListInfoData
* params, QueryEnvironment * queryEnv, _DestReceiver * dest,
QueryCompletion * qc) Line 1263 C
  postgres.exe!standard_ProcessUtility(PlannedStmt * pstmt, const char *
queryString, bool readOnlyTree, ProcessUtilityContext context,
ParamListInfoData * params, QueryEnvironment * queryEnv, _DestReceiver *
dest, QueryCompletion * qc) Line 1080 C


if there is a better debugger to use, please let me know

Dave



>
> I wonder if this indicates that we are either missing memory barriers
> somewhere or that the memory barriers we end up with on msvc + arm aren't
> correct?  Either could explain why the problem doesn't occur when building
> with optimizations.
>
> Greetings,
>
> Andres Freund
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Mon, 12 Feb 2024 at 09:19, Andrew Dunstan  wrote:

>
> On 2024-02-12 Mo 08:51, Dave Cramer wrote:
>
>
>
> On Sat, 10 Feb 2024 at 13:28, Andrew Dunstan  wrote:
>
>>
>> On 2024-02-10 Sa 12:20, Dave Cramer wrote:
>>
>>
>>
>> On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan  wrote:
>>
>>>
>>> On 2024-02-09 Fr 14:23, Dave Cramer wrote:
>>>
>>>
>>> Dave Cramer
>>> www.postgres.rocks
>>>
>>>
>>> On Fri, 9 Feb 2024 at 07:18, Dave Cramer 
>>>  wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, 9 Feb 2024 at 00:26, Michael Paquier 
>>>> wrote:
>>>>
>>>>> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
>>>>> > Thanks, this patch works and
>>>>> > testing with meson passes.
>>>>>
>>>>> Only with the version posted at [1]?  Interesting, that's the same
>>>>> contents as v8 posted upthread, minus src/tools/ because we don't need
>>>>> to care about them anymore.
>>>>>
>>>>> Andrew, what's happening on the test side?  It does not seem you've
>>>>> mentioned any details about what is going wrong, or I have just missed
>>>>> them.
>>>>>
>>>>> > I'll try the buildfarm next.
>>>>>
>>>>> [1]:
>>>>> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
>>>>
>>>>
>>>> interestingly meson test does not produce any error
>>>> The buildfarm produces the following error for me:
>>>>
>>>> -SELECT relname, attname, coltypes, get_columns_length(coltypes)
>>>> - FROM check_columns
>>>> - WHERE get_columns_length(coltypes) % 8 != 0 OR
>>>> -   'name'::regtype::oid = ANY(coltypes);
>>>> - relname | attname | coltypes | get_columns_length
>>>> --+-+--+
>>>> -(0 rows)
>>>> -
>>>> +server closed the connection unexpectedly
>>>> + This probably means the server terminated abnormally
>>>> + before or while processing the request.
>>>> +connection to server was lost
>>>>
>>>
>>> Actually digging some more, here is the actual error
>>>
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
>>> 11204) was terminated by exception 0xC005
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process
>>> was running: VACUUM;
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
>>> "ntstatus.h" for a description of the hexadecimal value.
>>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any
>>> other active server processes
>>> 2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server
>>> processes terminated; reinitializing
>>> 2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
>>> interrupted; last known up at 2024-02-09 13:31:01 -05
>>>
>>>
>>>
>>>
>>>
>> So how does one debug this ?
>>
>> Also if I `run meson test` I don't see this error. What does the
>> buildfarm do differently?
>>
>>
>> First it does this:
>>
>>
>> meson test -C $pgsql --no-rebuild --suite setup
>>
>>
>> Then it does this (jflag is for the number of jobs):
>>
>>
>> meson test -t $meson_test_timeout $jflag -C $pgsql --logbase checklog
>> --print-errorlogs --no-rebuild --suite regress --test-args=--no-locale
>>
>>
>
> running the above manually produces no errors ??
>
>
>
> Not for me. I get the error I previously reported, It's an access
> violation error.
>
>
> cheers
>
>
> andrew
>

OK, so I have managed to get a debugger attached to postgres.exe when it
faults and the fault occurs at
https://github.com/postgres/postgres/blob/09eb633e1baa3b7cd7929f3cc77f9c46f63c20b1/src/backend/utils/mmgr/dsa.c#L869
span is pointing to 0x0

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Sat, 10 Feb 2024 at 13:28, Andrew Dunstan  wrote:

>
> On 2024-02-10 Sa 12:20, Dave Cramer wrote:
>
>
>
> On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan  wrote:
>
>>
>> On 2024-02-09 Fr 14:23, Dave Cramer wrote:
>>
>>
>> Dave Cramer
>> www.postgres.rocks
>>
>>
>> On Fri, 9 Feb 2024 at 07:18, Dave Cramer 
>>  wrote:
>>
>>>
>>>
>>>
>>>
>>> On Fri, 9 Feb 2024 at 00:26, Michael Paquier 
>>> wrote:
>>>
>>>> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
>>>> > Thanks, this patch works and
>>>> > testing with meson passes.
>>>>
>>>> Only with the version posted at [1]?  Interesting, that's the same
>>>> contents as v8 posted upthread, minus src/tools/ because we don't need
>>>> to care about them anymore.
>>>>
>>>> Andrew, what's happening on the test side?  It does not seem you've
>>>> mentioned any details about what is going wrong, or I have just missed
>>>> them.
>>>>
>>>> > I'll try the buildfarm next.
>>>>
>>>> [1]:
>>>> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
>>>
>>>
>>> interestingly meson test does not produce any error
>>> The buildfarm produces the following error for me:
>>>
>>> -SELECT relname, attname, coltypes, get_columns_length(coltypes)
>>> - FROM check_columns
>>> - WHERE get_columns_length(coltypes) % 8 != 0 OR
>>> -   'name'::regtype::oid = ANY(coltypes);
>>> - relname | attname | coltypes | get_columns_length
>>> --+-+--+
>>> -(0 rows)
>>> -
>>> +server closed the connection unexpectedly
>>> + This probably means the server terminated abnormally
>>> + before or while processing the request.
>>> +connection to server was lost
>>>
>>
>> Actually digging some more, here is the actual error
>>
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
>> 11204) was terminated by exception 0xC005
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process
>> was running: VACUUM;
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
>> "ntstatus.h" for a description of the hexadecimal value.
>> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any
>> other active server processes
>> 2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server processes
>> terminated; reinitializing
>> 2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
>> interrupted; last known up at 2024-02-09 13:31:01 -05
>>
>>
>>
>>
>>
> So how does one debug this ?
>
> Also if I `run meson test` I don't see this error. What does the buildfarm
> do differently?
>
>
> First it does this:
>
>
> meson test -C $pgsql --no-rebuild --suite setup
>
>
> Then it does this (jflag is for the number of jobs):
>
>
> meson test -t $meson_test_timeout $jflag -C $pgsql --logbase checklog
> --print-errorlogs --no-rebuild --suite regress --test-args=--no-locale
>
>

running the above manually produces no errors ??

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan  wrote:

>
> On 2024-02-09 Fr 14:23, Dave Cramer wrote:
>
>
> Dave Cramer
> www.postgres.rocks
>
>
> On Fri, 9 Feb 2024 at 07:18, Dave Cramer 
>  wrote:
>
>>
>>
>>
>>
>> On Fri, 9 Feb 2024 at 00:26, Michael Paquier  wrote:
>>
>>> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
>>> > Thanks, this patch works and
>>> > testing with meson passes.
>>>
>>> Only with the version posted at [1]?  Interesting, that's the same
>>> contents as v8 posted upthread, minus src/tools/ because we don't need
>>> to care about them anymore.
>>>
>>> Andrew, what's happening on the test side?  It does not seem you've
>>> mentioned any details about what is going wrong, or I have just missed
>>> them.
>>>
>>> > I'll try the buildfarm next.
>>>
>>> [1]:
>>> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
>>
>>
>> interestingly meson test does not produce any error
>> The buildfarm produces the following error for me:
>>
>> -SELECT relname, attname, coltypes, get_columns_length(coltypes)
>> - FROM check_columns
>> - WHERE get_columns_length(coltypes) % 8 != 0 OR
>> -   'name'::regtype::oid = ANY(coltypes);
>> - relname | attname | coltypes | get_columns_length
>> --+-+--+
>> -(0 rows)
>> -
>> +server closed the connection unexpectedly
>> + This probably means the server terminated abnormally
>> + before or while processing the request.
>> +connection to server was lost
>>
>
> Actually digging some more, here is the actual error
>
> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
> 11204) was terminated by exception 0xC005
> 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process was
> running: VACUUM;
> 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
> "ntstatus.h" for a description of the hexadecimal value.
> 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any other
> active server processes
> 2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server processes
> terminated; reinitializing
> 2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
> interrupted; last known up at 2024-02-09 13:31:01 -05
>
>
>
>
>
So how does one debug this ?

Also if I `run meson test` I don't see this error. What does the buildfarm
do differently?

Dave

> Yes, this is pretty much what I saw.
>
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Fri, 9 Feb 2024 at 14:36, Andres Freund  wrote:

> Hi,
>
> On 2024-02-09 14:23:46 -0500, Dave Cramer wrote:
> > > interestingly meson test does not produce any error
> > > The buildfarm produces the following error for me:
> > >
> > > -SELECT relname, attname, coltypes, get_columns_length(coltypes)
> > > - FROM check_columns
> > > - WHERE get_columns_length(coltypes) % 8 != 0 OR
> > > -   'name'::regtype::oid = ANY(coltypes);
> > > - relname | attname | coltypes | get_columns_length
> > > --+-+--+
> > > -(0 rows)
> > > -
> > > +server closed the connection unexpectedly
> > > + This probably means the server terminated abnormally
> > > + before or while processing the request.
> > > +connection to server was lost
> > >
> >
> > Actually digging some more, here is the actual error
> >
> > 2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
> > 11204) was terminated by exception 0xC005
> > 2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process was
> > running: VACUUM;
> > 2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
> > "ntstatus.h" for a description of the hexadecimal value.
>
> That's something like a segfault.
>
> One suspicion I have is that src/port/pg_crc32c_armv8_choose.c possibly
> doesn't properly support msvc.  It seems to assume that SIGILL can be
> trapped,
> but that IIRC doesn't work on windows.
>
> I'd check if the problem persists if you change
> cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 1)
> to
> cdata.set('USE_ARMV8_CRC32C_WITH_RUNTIME_CHECK', 0)
>

This results in

FAILED: src/bin/pg_checksums/pg_checksums.exe
src/bin/pg_checksums/pg_checksums.pdb
"link"  /MACHINE:ARM64 /OUT:src/bin/pg_checksums/pg_checksums.exe
src/bin/pg_checksums/pg_checksums.exe.p/win32ver.res
src/bin/pg_checksums/pg_checksums.exe.p/pg_checksums.c.obj "/release"
"/nologo" "/DEBUG" "/PDB:src\bin\pg_checksums\pg_checksums.pdb"
"/INCREMENTAL:NO" "/STACK:4194304" "/NOEXP" "src/fe_utils/libpgfeutils.a"
"src/common/libpgcommon.a" "src/port/libpgport.a" "ws2_32.lib" "ws2_32.lib"
"ws2_32.lib" "ws2_32.lib" "/SUBSYSTEM:CONSOLE" "kernel32.lib" "user32.lib"
"gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib"
"uuid.lib" "comdlg32.lib" "advapi32.lib"
libpgcommon.a(controldata_utils.c.obj) : error LNK2001: unresolved external
symbol pg_comp_crc32c


Dave


>
>
> Also, yikes, that's an ugly way of doing hardware detection. Jumping out
> of a
> signal handler into normal code. Brrr.
>
> Greetings,
>
> Andres Freund
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Fri, 9 Feb 2024 at 07:18, Dave Cramer  wrote:

>
>
>
>
> On Fri, 9 Feb 2024 at 00:26, Michael Paquier  wrote:
>
>> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
>> > Thanks, this patch works and
>> > testing with meson passes.
>>
>> Only with the version posted at [1]?  Interesting, that's the same
>> contents as v8 posted upthread, minus src/tools/ because we don't need
>> to care about them anymore.
>>
>> Andrew, what's happening on the test side?  It does not seem you've
>> mentioned any details about what is going wrong, or I have just missed
>> them.
>>
>> > I'll try the buildfarm next.
>>
>> [1]:
>> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net
>
>
> interestingly meson test does not produce any error
> The buildfarm produces the following error for me:
>
> -SELECT relname, attname, coltypes, get_columns_length(coltypes)
> - FROM check_columns
> - WHERE get_columns_length(coltypes) % 8 != 0 OR
> -   'name'::regtype::oid = ANY(coltypes);
> - relname | attname | coltypes | get_columns_length
> --+-+--+
> -(0 rows)
> -
> +server closed the connection unexpectedly
> + This probably means the server terminated abnormally
> + before or while processing the request.
> +connection to server was lost
>

Actually digging some more, here is the actual error

2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  server process (PID
11204) was terminated by exception 0xC005
2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:  Failed process was
running: VACUUM;
2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:  See C include file
"ntstatus.h" for a description of the hexadecimal value.
2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:  terminating any other
active server processes
2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all server processes
terminated; reinitializing
2024-02-09 13:31:11.034 -05 startup[6152] LOG:  database system was
interrupted; last known up at 2024-02-09 13:31:01 -05


Dave

>
> Dave
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Fri, 9 Feb 2024 at 00:26, Michael Paquier  wrote:

> On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave Cramer wrote:
> > Thanks, this patch works and
> > testing with meson passes.
>
> Only with the version posted at [1]?  Interesting, that's the same
> contents as v8 posted upthread, minus src/tools/ because we don't need
> to care about them anymore.
>
> Andrew, what's happening on the test side?  It does not seem you've
> mentioned any details about what is going wrong, or I have just missed
> them.
>
> > I'll try the buildfarm next.
>
> [1]:
> https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


interestingly meson test does not produce any error
The buildfarm produces the following error for me:

-SELECT relname, attname, coltypes, get_columns_length(coltypes)
- FROM check_columns
- WHERE get_columns_length(coltypes) % 8 != 0 OR
-   'name'::regtype::oid = ANY(coltypes);
- relname | attname | coltypes | get_columns_length
--+-+--+
-(0 rows)
-
+server closed the connection unexpectedly
+ This probably means the server terminated abnormally
+ before or while processing the request.
+connection to server was lost

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Wed, 31 Jan 2024 at 10:21, Andrew Dunstan  wrote:

>
> On 2024-01-30 Tu 17:54, Dave Cramer wrote:
>
>
>
>
> On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan 
> wrote:
>
>>
>> On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>>
>>
>>
>> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan  wrote:
>>
>>>
>>> On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>>>
>>>
>>> Dave Cramer
>>> www.postgres.rocks
>>>
>>>
>>> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan 
>>> wrote:
>>>
>>>>
>>>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>>>
>>>>
>>>>
>>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan 
>>>> wrote:
>>>>
>>>>>
>>>>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>>>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>>>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan 
>>>>> wrote:
>>>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>>>> >>> Yeah, I think the default Developer Command Prompt for VS2022 is
>>>>> set up
>>>>> >>> for x86 builds. AIUI you should start by executing "vcvarsall
>>>>> x64_arm64".
>>>>> >> Yup, now I'm in the same state you are
>>>>> > Wait a minute here.  Based on [1], x64_arm64 means you can use a x64
>>>>> > host and you'll be able to produce ARM64 builds, still these will not
>>>>> > be able to run on the host where they were built.  How much of the
>>>>> > patch posted upthread is required to produce such builds?  Basically
>>>>> > everything from it, I guess, so as build dependencies can be
>>>>> > satisfied?
>>>>> >
>>>>> > [1]:
>>>>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>>>>
>>>>>
>>>>> If you look at the table here x86 and x64 are the only supported host
>>>>> architectures. But that's OK, the x64 binaries will run on arm64 (W11
>>>>> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
>>>>> not have got as far as we have. But you want the x64_arm64 argument to
>>>>> vcvarsall so you will get ARM64 output.
>>>>>
>>>>
>>>> I've rebuilt it using  x64_arm64 and with the attached (very naive
>>>> patch) and I still get an x64 binary :(
>>>>
>>>>
>>>> With this patch I still get a build error, but it's different :-)
>>>>
>>>>
>>>> [1406/2088] "link" @src/backend/postgres.exe.rsp
>>>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>>>> "link" @src/backend/postgres.exe.rsp
>>>>Creating library src\backend\postgres.exe.lib
>>>>
>>>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
>>>> spin_delay referenced in function perform_spin_delay
>>>>
>>>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>>>>
>>>
>>> Did you add the latest lock.patch ?
>>>
>>>
>>>
>>>
>>> I'm a bit confused about exactly what needs to be applied. Can you
>>> supply a complete patch to be applied to a pristine checkout that will let
>>> me build?
>>>
>>>
>>> cheers
>>>
>>
>> See attached.
>>
>>
>>
>> No, that is what is giving me the error shown above (just tried again to
>> be certain). And it's not surprising, as patch 2 #ifdef's out the
>> definition of spin_delay().
>>
>> If you can get a complete build with these patches then I suspect you're
>> not doing a proper ARM64 build.
>>
>
> Okay I will look when I get home in a week
>
>
> I made some progress. The attached is mostly taken from
> <https://postgr.es/m/dbee741f-b9b7-a0d5-1b1b-f9b532bb6...@linaro.org>
> <https://postgr.es/m/dbee741f-b9b7-a0d5-1b1b-f9b532bb6...@linaro.org>
>
> With it applied I was able to get a successful build using the buildfarm
> client. However, there are access violations when running some tests, so
> there is still some work to do, apparently.
>
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>

Thanks, this patch works and
testing with meon passes.

I'll try the buildfarm next.

Dave

Re: When extended query protocol ends?

[Dave Cramer]

On Mon, 29 Jan 2024 at 20:15, Tatsuo Ishii  wrote:

> Hello Dave,
>
> > Tatsuo Ishii  writes:
> >> Below is outputs from "pgproto" command coming with Pgpool-II.
> >> (Lines starting "FE" represents a message from frontend to backend.
> >> Lines starting "BE" represents a message from backend to frontend.)
> >
> >> FE=> Parse(stmt="", query="SET extra_float_digits = 3")
> >> FE=> Bind(stmt="", portal="")
> >> FE=> Execute(portal="")
> >> FE=> Parse(stmt="", query="SET extra_float_digits = 3")
> >> FE=> Bind(stmt="", portal="")
> >> FE=> Execute(portal="")
> >> FE=> Query (query="SET extra_float_digits = 3")
> >> <= BE ParseComplete
> >> <= BE BindComplete
> >> <= BE CommandComplete(SET)
> >> <= BE ParseComplete
> >> <= BE BindComplete
> >> <= BE CommandComplete(SET)
> >> <= BE CommandComplete(SET)
> >> <= BE ReadyForQuery(I)
> >> FE=> Terminate
> >
> >> As you can see, two "SET extra_float_digits = 3" is sent in the
> >> extended query protocol, then one "SET extra_float_digits = 3" follows
> >> in the simple query protocol. No sync message is sent. However, I get
> >> ReadyForQuery at the end. It seems the extended query protocol is
> >> ended by a simple query protocol message instead of a sync message.
> >
> >> My question is, is this legal in terms of fronted/backend protocol?
> >
> > I think it's poor practice, at best.  You should end the
> > extended-protocol query cycle before invoking simple query.
>
> From [1] I think the JDBC driver sends something like below if
> autosave=always option is specified.
>
> "BEGIN READ ONLY" Parse/Bind/Eexecute (in the extended query protocol)
> "SAVEPOINT PGJDBC_AUTOSAVE" (in the simple query protocol)
>
> It seems the SAVEPOINT is sent without finishing the extended query
> protocol (i.e. without Sync message). Is it possible for the JDBC
> driver to issue a Sync message before sending SAVEPOINT in simple
> query protocol? Or you can send SAVEPOINT using the extended query
> protocol.
>
> [1]
> https://www.pgpool.net/pipermail/pgpool-general/2023-December/009051.html
>
>
Hi Tatsuo,

Yes, it would be possible.

Can you create an issue on github? Issues · pgjdbc/pgjdbc (github.com)


Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, Jan 30, 2024 at 4:56 PM Andrew Dunstan  wrote:

>
> On 2024-01-30 Tu 09:50, Dave Cramer wrote:
>
>
>
> On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan  wrote:
>
>>
>> On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>>
>>
>> Dave Cramer
>> www.postgres.rocks
>>
>>
>> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan  wrote:
>>
>>>
>>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>>
>>>
>>>
>>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan 
>>> wrote:
>>>
>>>>
>>>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan 
>>>> wrote:
>>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>>> >>> Yeah, I think the default Developer Command Prompt for VS2022 is
>>>> set up
>>>> >>> for x86 builds. AIUI you should start by executing "vcvarsall
>>>> x64_arm64".
>>>> >> Yup, now I'm in the same state you are
>>>> > Wait a minute here.  Based on [1], x64_arm64 means you can use a x64
>>>> > host and you'll be able to produce ARM64 builds, still these will not
>>>> > be able to run on the host where they were built.  How much of the
>>>> > patch posted upthread is required to produce such builds?  Basically
>>>> > everything from it, I guess, so as build dependencies can be
>>>> > satisfied?
>>>> >
>>>> > [1]:
>>>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>>>
>>>>
>>>> If you look at the table here x86 and x64 are the only supported host
>>>> architectures. But that's OK, the x64 binaries will run on arm64 (W11
>>>> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
>>>> not have got as far as we have. But you want the x64_arm64 argument to
>>>> vcvarsall so you will get ARM64 output.
>>>>
>>>
>>> I've rebuilt it using  x64_arm64 and with the attached (very naive
>>> patch) and I still get an x64 binary :(
>>>
>>>
>>> With this patch I still get a build error, but it's different :-)
>>>
>>>
>>> [1406/2088] "link" @src/backend/postgres.exe.rsp
>>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>>> "link" @src/backend/postgres.exe.rsp
>>>Creating library src\backend\postgres.exe.lib
>>>
>>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
>>> spin_delay referenced in function perform_spin_delay
>>>
>>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>>>
>>
>> Did you add the latest lock.patch ?
>>
>>
>>
>>
>> I'm a bit confused about exactly what needs to be applied. Can you supply
>> a complete patch to be applied to a pristine checkout that will let me
>> build?
>>
>>
>> cheers
>>
>
> See attached.
>
>
>
> No, that is what is giving me the error shown above (just tried again to
> be certain). And it's not surprising, as patch 2 #ifdef's out the
> definition of spin_delay().
>
> If you can get a complete build with these patches then I suspect you're
> not doing a proper ARM64 build.
>
>
Okay I will look when I get home in a week

Dave

>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 30 Jan 2024 at 08:38, Andrew Dunstan  wrote:

>
> On 2024-01-29 Mo 11:20, Dave Cramer wrote:
>
>
> Dave Cramer
> www.postgres.rocks
>
>
> On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan  wrote:
>
>>
>> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>>
>>
>>
>> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  wrote:
>>
>>>
>>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan 
>>> wrote:
>>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>>> >>> Yeah, I think the default Developer Command Prompt for VS2022 is set
>>> up
>>> >>> for x86 builds. AIUI you should start by executing "vcvarsall
>>> x64_arm64".
>>> >> Yup, now I'm in the same state you are
>>> > Wait a minute here.  Based on [1], x64_arm64 means you can use a x64
>>> > host and you'll be able to produce ARM64 builds, still these will not
>>> > be able to run on the host where they were built.  How much of the
>>> > patch posted upthread is required to produce such builds?  Basically
>>> > everything from it, I guess, so as build dependencies can be
>>> > satisfied?
>>> >
>>> > [1]:
>>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>>
>>>
>>> If you look at the table here x86 and x64 are the only supported host
>>> architectures. But that's OK, the x64 binaries will run on arm64 (W11
>>> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
>>> not have got as far as we have. But you want the x64_arm64 argument to
>>> vcvarsall so you will get ARM64 output.
>>>
>>
>> I've rebuilt it using  x64_arm64 and with the attached (very naive patch)
>> and I still get an x64 binary :(
>>
>>
>> With this patch I still get a build error, but it's different :-)
>>
>>
>> [1406/2088] "link" @src/backend/postgres.exe.rsp
>> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
>> "link" @src/backend/postgres.exe.rsp
>>Creating library src\backend\postgres.exe.lib
>>
>> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
>> spin_delay referenced in function perform_spin_delay
>>
>> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>>
>
> Did you add the latest lock.patch ?
>
>
>
>
> I'm a bit confused about exactly what needs to be applied. Can you supply
> a complete patch to be applied to a pristine checkout that will let me
> build?
>
>
> cheers
>

See attached.

Dave


0001-fix-build-for-arm.patch
Description: Binary data


0002-naive-patch-to-fix-locking-for-arm64.patch
Description: Binary data

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Mon, 29 Jan 2024 at 11:16, Andrew Dunstan  wrote:

>
> On 2024-01-26 Fr 09:18, Dave Cramer wrote:
>
>
>
> On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  wrote:
>
>>
>> On 2024-01-25 Th 20:32, Michael Paquier wrote:
>> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
>> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan 
>> wrote:
>> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>> >>> Yeah, I think the default Developer Command Prompt for VS2022 is set
>> up
>> >>> for x86 builds. AIUI you should start by executing "vcvarsall
>> x64_arm64".
>> >> Yup, now I'm in the same state you are
>> > Wait a minute here.  Based on [1], x64_arm64 means you can use a x64
>> > host and you'll be able to produce ARM64 builds, still these will not
>> > be able to run on the host where they were built.  How much of the
>> > patch posted upthread is required to produce such builds?  Basically
>> > everything from it, I guess, so as build dependencies can be
>> > satisfied?
>> >
>> > [1]:
>> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>>
>>
>> If you look at the table here x86 and x64 are the only supported host
>> architectures. But that's OK, the x64 binaries will run on arm64 (W11
>> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
>> not have got as far as we have. But you want the x64_arm64 argument to
>> vcvarsall so you will get ARM64 output.
>>
>
> I've rebuilt it using  x64_arm64 and with the attached (very naive patch)
> and I still get an x64 binary :(
>
>
> With this patch I still get a build error, but it's different :-)
>
>
> [1406/2088] "link" @src/backend/postgres.exe.rsp
> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
> "link" @src/backend/postgres.exe.rsp
>Creating library src\backend\postgres.exe.lib
>
> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
> spin_delay referenced in function perform_spin_delay
>
> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>

Did you add the latest lock.patch ?

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Fri, 26 Jan 2024 at 07:36, Andrew Dunstan  wrote:

>
> On 2024-01-25 Th 20:32, Michael Paquier wrote:
> > On Thu, Jan 25, 2024 at 04:52:30PM -0500, Dave Cramer wrote:
> >> On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan 
> wrote:
> >>> On 2024-01-25 Th 16:17, Dave Cramer wrote:
> >>> Yeah, I think the default Developer Command Prompt for VS2022 is set up
> >>> for x86 builds. AIUI you should start by executing "vcvarsall
> x64_arm64".
> >> Yup, now I'm in the same state you are
> > Wait a minute here.  Based on [1], x64_arm64 means you can use a x64
> > host and you'll be able to produce ARM64 builds, still these will not
> > be able to run on the host where they were built.  How much of the
> > patch posted upthread is required to produce such builds?  Basically
> > everything from it, I guess, so as build dependencies can be
> > satisfied?
> >
> > [1]:
> https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170
>
>
> If you look at the table here x86 and x64 are the only supported host
> architectures. But that's OK, the x64 binaries will run on arm64 (W11
> ARM64 has x64 emulation builtin). If that didn't work Dave and I would
> not have got as far as we have. But you want the x64_arm64 argument to
> vcvarsall so you will get ARM64 output.
>

I've rebuilt it using  x64_arm64 and with the attached (very naive patch)
and I still get an x64 binary :(

>
>


lock.patch
Description: Binary data

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 16:32, Andrew Dunstan  wrote:

>
> On 2024-01-25 Th 16:17, Dave Cramer wrote:
>
>
>
> On Thu, 25 Jan 2024 at 16:04, Anthony Roberts 
> wrote:
>
>> Hi David,
>>
>> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
>>
>> Thanks,
>> Anthony
>>
>
>
> So there is another way, select the file in Windows Explorer and right
> click, in the compatibility tab if the "Windows on ARM" is greyed out it is
> an arm binary.
>
> So far mine are not :(
>
>
> Yeah, I think the default Developer Command Prompt for VS2022 is set up
> for x86 builds. AIUI you should start by executing "vcvarsall x64_arm64".
>

Yup, now I'm in the same state you are

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 16:04, Anthony Roberts 
wrote:

> Hi David,
>
> Unix "file" or "dumpbin /headers" in vcvarsall are your best bets.
>
> Thanks,
> Anthony
>


So there is another way, select the file in Windows Explorer and right
click, in the compatibility tab if the "Windows on ARM" is greyed out it is
an arm binary.

So far mine are not :(

Thanks,

Dave

>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan  wrote:

>
> On 2024-01-24 We 19:02, Michael Paquier wrote:
>
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>
> I managed to get it to build the vcvarsall arch needs to be x64. I need to
> add some options, but the patch above needs to be applied to build it.
>
> Nice.  If I may ask, what kind of host and/or configuration have you
> used to reach a state where the code can be compiled and run tests
> with meson?  If you have found specific steps, it may be a good thing
> to document that on the wiki, say around [1].
>
> Perhaps you have not included TAP?  It may be fine in terms of runtime
> checks and coverage.
>
> [1]: 
> https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
>
>
>
> I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we really
> want to build with x64_arm64, i.e. to generate native arm64 binaries.
> Setting just x64 will not do that, AIUI.
>
> I tried that with the buidfarm, setting that in the config file's call to
> PGBuild::VSenv::getenv().
>
> That upset msvc_gendef.pl, so I added this there to keep it happy:
>
> $arch = 'x86_64' if $arch eq 'aarch64';
>
> After that things went ok until I got this:
>
> [1453/2088] "link" @src/backend/postgres.exe.rsp
> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
> "link" @src/backend/postgres.exe.rsp
>Creating library src\backend\postgres.exe.lib
> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
> _mm_pause referenced in function perform_spin_delay
> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>
>
> I haven't made further progress, but I will return to it in the next day
> or so.
>
> While this will be nice to have, I think it won't really matter until
> there is ARM64 support in released versions of Windows Server. AFAICT they
> still only sell versions for x86_64
>

I've tried it with my patch attached previously and x64_arm64 and it works
fine. builds using the buildfarm as well.

Is there a definitive way to figure out if the binaries are x64_arm64

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 14:31, Andrew Dunstan  wrote:

>
> On 2024-01-25 Th 08:45, Dave Cramer wrote:
>
>
>
>
>
> I tried running my buildfarm using my git repo and my branch, but get the
> following error
> Status Line: 492 bad branch parameter
> Content:
> bad branch parameter fix_arm
>
> Web txn failed with status: 1
>
>
>
> You can't use your own branch with the buildfarm, you need to let it set
> up its own branches.
>

So I guess I have to wait until this patch is merged in ?

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 12:30, Andrew Dunstan  wrote:

>
> On 2024-01-24 We 19:02, Michael Paquier wrote:
>
> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>
> I managed to get it to build the vcvarsall arch needs to be x64. I need to
> add some options, but the patch above needs to be applied to build it.
>
> Nice.  If I may ask, what kind of host and/or configuration have you
> used to reach a state where the code can be compiled and run tests
> with meson?  If you have found specific steps, it may be a good thing
> to document that on the wiki, say around [1].
>
> Perhaps you have not included TAP?  It may be fine in terms of runtime
> checks and coverage.
>
> [1]: 
> https://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto#Running_on_Windows
>
>
>
> I now have an ARM64 machine, so I set up a W11 ARM64 VM. I think we really
> want to build with x64_arm64, i.e. to generate native arm64 binaries.
> Setting just x64 will not do that, AIUI.
>
> I tried that with the buidfarm, setting that in the config file's call to
> PGBuild::VSenv::getenv().
>
> That upset msvc_gendef.pl, so I added this there to keep it happy:
>
> $arch = 'x86_64' if $arch eq 'aarch64';
>
> After that things went ok until I got this:
>
> [1453/2088] "link" @src/backend/postgres.exe.rsp
> FAILED: src/backend/postgres.exe src/backend/postgres.pdb
> "link" @src/backend/postgres.exe.rsp
>Creating library src\backend\postgres.exe.lib
> storage_lmgr_s_lock.c.obj : error LNK2019: unresolved external symbol
> _mm_pause referenced in function perform_spin_delay
> src\backend\postgres.exe : fatal error LNK1120: 1 unresolved externals
>
>
> I haven't made further progress, but I will return to it in the next day
> or so.
>
> While this will be nice to have, I think it won't really matter until
> there is ARM64 support in released versions of Windows Server. AFAICT they
> still only sell versions for x86_64
>

I need it to build clients. The clients need arm64 libraries to link against

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Thu, 25 Jan 2024 at 08:31, Dave Cramer  wrote:

>
>
> On Wed, 24 Jan 2024 at 19:03, Michael Paquier  wrote:
>
>> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
>> > I managed to get it to build the vcvarsall arch needs to be x64. I need
>> to
>> > add some options, but the patch above needs to be applied to build it.
>>
>> Nice.  If I may ask, what kind of host and/or configuration have you
>> used to reach a state where the code can be compiled and run tests
>> with meson?  If you have found specific steps, it may be a good thing
>> to document that on the wiki, say around [1].
>>
>
> I am running a mac-mini M2 with parallels running windows pro 11
> The only thing required is this patch. Running in a native developer
> prompt
>
> meson setup build --prefix=c:\postgres
> cd build
> ninja
> ninja install
> ninja test
>
> all run without errors
> I also have buildfarm running and will run that today
>
> Dave
>
>>
>> Perhaps you have not included TAP?  It may be fine in terms of runtime
>> checks and coverage.
>>
>
> Does TAP have to be explicitly added to the meson build ?
>
> Dave
>


I tried running my buildfarm using my git repo and my branch, but get the
following error
Status Line: 492 bad branch parameter
Content:
bad branch parameter fix_arm

Web txn failed with status: 1

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Wed, 24 Jan 2024 at 19:03, Michael Paquier  wrote:

> On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote:
> > I managed to get it to build the vcvarsall arch needs to be x64. I need
> to
> > add some options, but the patch above needs to be applied to build it.
>
> Nice.  If I may ask, what kind of host and/or configuration have you
> used to reach a state where the code can be compiled and run tests
> with meson?  If you have found specific steps, it may be a good thing
> to document that on the wiki, say around [1].
>

I am running a mac-mini M2 with parallels running windows pro 11
The only thing required is this patch. Running in a native developer
prompt

meson setup build --prefix=c:\postgres
cd build
ninja
ninja install
ninja test

all run without errors
I also have buildfarm running and will run that today

Dave

>
> Perhaps you have not included TAP?  It may be fine in terms of runtime
> checks and coverage.
>

Does TAP have to be explicitly added to the meson build ?

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 23 Jan 2024 at 18:32, Michael Paquier  wrote:

> On Tue, Jan 23, 2024 at 04:13:05PM -0500, Dave Cramer wrote:
> > On Tue, 23 Jan 2024 at 08:46, Dave Cramer 
> wrote:
> >> The attached patch works with v17. I will work on getting a buildfarm
> >> animal up shortly
>
> Thanks for doing that!
>
> > I can build using meson manually, but for some reason building with the
> > buildfarm fails.
> >
> > I'm not sure which files to attach to this to help. Andrew, what files do
> > you need ?
>
> Probably build.ninja and the contents of meson-logs/ would offer
> enough information?
> --
> Michael
>

I managed to get it to build the vcvarsall arch needs to be x64. I need to
add some options, but the patch above needs to be applied to build it.

Dave

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 23 Jan 2024 at 08:46, Dave Cramer  wrote:

>
>
> On Tue, 19 Sept 2023 at 23:48, Michael Paquier 
> wrote:
>
>> On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote:
>> > Was there an explicit request for something there? I was under the
>> > impression that this was all just suggestion/theory at the moment.
>>
>> Yes.  The addition of a buildfarm member registered into the community
>> facilities, so as it is possible to provide back to developers dynamic
>> feedback to the new configuration setup you would like to see
>> supported in PostgreSQL.  This has been mentioned a few times on this
>> thread, around these places:
>>
>> https://www.postgresql.org/message-id/20220322103011.i6z2tuj4hle23wgx@jrouhaud
>>
>> https://www.postgresql.org/message-id/dbd80715-e56b-40eb-84aa-ace70198e...@yesql.se
>>
>> https://www.postgresql.org/message-id/6d1e2719-fa49-42a5-a6ff-0b0072bf6...@yesql.se
>> --
>> Michael
>>
>
> The attached patch works with v17. I will work on getting a buildfarm
> animal up shortly
>
>
I can build using meson manually, but for some reason building with the
buildfarm fails.

I'm not sure which files to attach to this to help. Andrew, what files do
you need ?

Dave

>
>

Re: [PATCH] Add native windows on arm64 support

[Dave Cramer]

On Tue, 19 Sept 2023 at 23:48, Michael Paquier  wrote:

> On Tue, Sep 19, 2023 at 01:35:17PM +0100, Anthony Roberts wrote:
> > Was there an explicit request for something there? I was under the
> > impression that this was all just suggestion/theory at the moment.
>
> Yes.  The addition of a buildfarm member registered into the community
> facilities, so as it is possible to provide back to developers dynamic
> feedback to the new configuration setup you would like to see
> supported in PostgreSQL.  This has been mentioned a few times on this
> thread, around these places:
>
> https://www.postgresql.org/message-id/20220322103011.i6z2tuj4hle23wgx@jrouhaud
>
> https://www.postgresql.org/message-id/dbd80715-e56b-40eb-84aa-ace70198e...@yesql.se
>
> https://www.postgresql.org/message-id/6d1e2719-fa49-42a5-a6ff-0b0072bf6...@yesql.se
> --
> Michael
>

The attached patch works with v17. I will work on getting a buildfarm
animal up shortly


windows_arm_build.patch
Description: Binary data

Re: Password leakage avoidance

[Dave Cramer]

On Wed, 3 Jan 2024 at 08:53, Robert Haas  wrote:

> On Sun, Dec 24, 2023 at 12:06 PM Jonathan S. Katz 
> wrote:
> > We're likely to have new algorithms in the future, as there is a draft
> > RFC for updating the SCRAM hashes, and already some regulatory bodies
> > are looking to deprecate SHA256. My concern with relying on the
> > "encrypted_password" GUC (which is why PQencryptPasswordConn takes
> > "conn") makes it any easier for users to choose the algorithm, or if
> > they need to rely on the server/session setting.
>
> Yeah, I agree. It doesn't make much sense to me to propose that a GUC,
> which is a server-side setting, should control client-side behavior.
>
> Also, +1 for the general idea. I don't think this is a whole answer to
> the problem of passwords appearing in log files because (1) you have
> to be using libpq in order to make use of this


JDBC has it as of yesterday. I would imagine other clients will implement
it.
Dave Cramer

>
>

Re: Password leakage avoidance

[Dave Cramer]

On Wed, 27 Dec 2023 at 16:10, Tom Lane  wrote:

> Joe Conway  writes:
> > On 12/27/23 15:39, Peter Eisentraut wrote:
> >> On 23.12.23 16:13, Joe Conway wrote:
> >>> The attached patch set moves the guts of \password from psql into the
> >>> libpq client side -- PQchangePassword() (patch 0001).
>
> >> I don't follow how you get from the problem statement to this solution.
> >> This proposal doesn't avoid password leakage, does it?
> >> It just provides a different way to phrase the existing solution.
>
> > Yes, a fully built one that is convenient to use, and does not ask
> > everyone to roll their own.
>
> It's convenient for users of libpq, I guess, but it doesn't help
> anyone not writing C code directly atop libpq.  If this is the
> way forward then we need to also press JDBC and other client
> libraries to implement comparable functionality.  That's within
> the realm of sanity surely, and having a well-thought-through
> reference implementation in libpq would help those authors.
> So I don't think this is a strike against the patch; but the answer
> to Peter's question has to be that this is just part of the solution.
>

Already have one in the works for JDBC, actually predates this.
https://github.com/pgjdbc/pgjdbc/pull/3067

Dave

Re: Password leakage avoidance

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Sat, 23 Dec 2023 at 11:00, Tom Lane  wrote:

> Joe Conway  writes:
> > The attached patch set moves the guts of \password from psql into the
> > libpq client side -- PQchangePassword() (patch 0001).
>
> Haven't really read the patch, just looked at the docs, but here's
> a bit of bikeshedding:
>
> * This seems way too eager to promote the use of md5.  Surely the
> default ought to be SCRAM, full stop.  I question whether we even
> need an algorithm parameter.  Perhaps it's a good idea for
> future-proofing, but we could also plan that the function would
> make its own decisions based on noting the server's version.
> (libpq is far more likely to be au courant about what to do than
> the calling application, IMO.)
>

Using the server version has some issues. It's quite possible to encrypt a
user password with md5 when the server version is scram. So if you change
the encryption then pg_hba.conf would have to be updated to allow the user
to log back in.

Dave

Re: [RBW] ISO 51 cm Homer or Sam

[Ron Cramer]

Got one...

On Tue, Dec 19, 2023, 2:28 PM Greg Sonstein  wrote:

> ISO 51 cm Homer or Sam. Pref unused or no marks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/6b236291-a813-4ace-b644-e8365b0a4b91n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5fr-Dp-cNGnaEQwXDi2gJZp9qhvM4mUtnceGyDJey1f4A%40mail.gmail.com.

[CODE4LIB] open position for IIIF Managing Director

[Tom Cramer]

Are you a person who thrives at the intersection of community-based 
initiatives, technology, and the research & cultural heritage sectors? Does the 
idea of working with international leaders in these fields from organizations 
small and large excite you? Are you interested in making an impact?

The International Image Interoperability Framework Consortium 
(IIIF-C) seeks a Managing Director to foster the continued success and growth 
of IIIF, lead delivery of the IIIF strategic plan, and supervise the work of 
other IIIF-C staff members (currently two full time staff).

A position description and instructions on how to apply can be found at 
https://iiif.io/news/2023/12/04/managing-director/

We welcome applicants through January 16, 2024.

- The IIIF-C Executive Committee

IOS Keyboard Commands for iPhone

[Tom Cramer]

Hello,
I have been trying to look for a complete, or at least, a
comprehensive list of Keyboard commands when using the iPhone. I have
a partial list, but I am looking for a full list. I have a Logitech
k380 keyboard that I'm using with my iPhone.
Any help?

-- 
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/CAPr-VTpKKbbewXcGRB7ZaqPjr-LYPSBcjYSE0Qt7gJ1akn0gEw%40mail.gmail.com.

Anomoly from `freebsd-update IDS` in 12.4-RELEASE-p9 - dual entries for /etc/ssh/sshd_config

[Walter Cramer]

When running `freebsd-update IDS` on a few 12.4-RELEASE-p9 systems which 
have local changes in /etc/ssh/sshd_config, I get TWO separate lines of 
output about /etc/ssh/sshd_config:


...

/etc/ssh/sshd_config has SHA256 hash XXX, 
but should have SHA256 hash 
2e201f8c0ca677cc6b6dce2608579ed7d05262dec52b534037bf67fe0601fe68.


/etc/ssh/sshd_config has SHA256 hash XXX, 
but should have SHA256 hash 
eac5adbd9571a12135c3af1c536ace0e8fd58164eec273efa9df37ab7eb941ec.


...

(The two X'ed hashes are the same, and match the sha256 hash of the 
system's customized /etc/ssh/sshd_config.)



Poking around a bit in /usr/src, and my weekly snapshots of that, I found 
both versions of sshd_config -


SHA256 (/usr/src/crypto/openssh/sshd_config) = 
2e201f8c0ca677cc6b6dce2608579ed7d05262dec52b534037bf67fe0601fe68


SHA256 (/usr/.zfs/snapshot/year_week.23w31/src/crypto/openssh/sshd_config) 
= eac5adbd9571a12135c3af1c536ace0e8fd58164eec273efa9df37ab7eb941ec


SHA256 (/usr/.zfs/snapshot/year_week.23w32/src/crypto/openssh/sshd_config) 
= 2e201f8c0ca677cc6b6dce2608579ed7d05262dec52b534037bf67fe0601fe68


`diff` on those two versions of sshd_config yields:

109c109
< #VersionAddendum FreeBSD-20221019
---

#VersionAddendum FreeBSD-20230719


So both versions of sshd_config start with these same lines, which may be 
the root problem:


#   $OpenBSD: sshd_config,v 1.104 2021/07/02 05:11:21 dtucker Exp $
#   $FreeBSD: releng/12.4/crypto/openssh/sshd_config 372681 2022-10-31 
17:19:41Z git2svn

Re: Emitting JSON to file using COPY TO

[Dave Cramer]

On Thu, 7 Dec 2023 at 08:47, David G. Johnston 
wrote:

> On Thursday, December 7, 2023, Daniel Verite 
> wrote:
>
>> Joe Conway wrote:
>>
>> > The attached should fix the CopyOut response to say one column. I.e. it
>> > ought to look something like:
>>
>> Spending more time with the doc I came to the opinion that in this bit
>> of the protocol, in CopyOutResponse (B)
>> ...
>> Int16
>> The number of columns in the data to be copied (denoted N below).
>> ...
>>
>> this number must be the number of columns in the source.
>> That is for COPY table(a,b,c)   the number is 3, independently
>> on whether the result is formatted in text, cvs, json or binary.
>>
>> I think that changing it for json can reasonably be interpreted
>> as a protocol break and we should not do it.
>>
>> The fact that this value does not help parsing the CopyData
>> messages that come next is not a new issue. A reader that
>> doesn't know the field separator and whether it's text or csv
>> cannot parse these messages into fields anyway.
>> But just knowing how much columns there are in the original
>> data might be useful by itself and we don't want to break that.
>
>
> This argument for leaving 3 as the column count makes sense to me.  I
> agree this content is not meant to facilitate interpreting the contents at
> a protocol level.
>

I'd disagree. From my POV if the data comes back as a JSON Array this is
one object and this should be reflected in the column count.

>
>
>>
>>
>> The other question for me is, in the CopyData message, this
>> bit:
>> " Messages sent from the backend will always correspond to single data
>> rows"
>>
>> ISTM that considering that the "[" starting the json array is a
>> "data row" is a stretch.
>> That might be interpreted as a protocol break, depending
>> on how strict the interpretation is.
>>
>
Well technically it is a single row if you send an array.

Regardless, I expect Euler's comment above that JSON lines format is going
to be the preferred format as the client doesn't have to wait for the
entire object before starting to parse.

Dave

>

Re: errors building on windows using meson

[Dave Cramer]

On Thu, 7 Dec 2023 at 14:34, Andres Freund  wrote:

> Hi,
>
> On 2023-12-07 14:16:52 -0500, Dave Cramer wrote:
> > On Thu, 7 Dec 2023 at 13:53, Andres Freund  wrote:
> >
> > > Hi,
> > >
> > > On 2023-12-07 12:54:27 -0500, Dave Cramer wrote:
> > > > state-exec: run failed: cannot create new executor meta: cannot get
> > > > matching bin by path: no matching binary by path
> > > >
> > >
> "C:\\Users\\Administrator\\AppData\\Local\\activestate\\cache\\b9117b06\\exec\\perl.EXE"
> > > > state-exec: Not user serviceable; Please contact support for
> assistance.
> > > >
> > > > anyone seen this or have a fix ?
> > >
> > > I've not seen that before. Please provide a bit more detail. Compiler,
> > > building with ninja or msbuild/visual studio, when exactly you're
> > > encountering
> > > the issue, ...
> > >
> > > Windows Server 2019
> > VS 2019
> > building with ninja
>
> I don't think this is sufficient detail to provide you with advice / fix
> problems / whatnot. Please provide complete logs of configuring and
> building.
>

I built perl from source and it worked.

Dave



>
> - Andres
>

Re: errors building on windows using meson

[Dave Cramer]

On Thu, 7 Dec 2023 at 13:53, Andres Freund  wrote:

> Hi,
>
> On 2023-12-07 12:54:27 -0500, Dave Cramer wrote:
> > state-exec: run failed: cannot create new executor meta: cannot get
> > matching bin by path: no matching binary by path
> >
> "C:\\Users\\Administrator\\AppData\\Local\\activestate\\cache\\b9117b06\\exec\\perl.EXE"
> > state-exec: Not user serviceable; Please contact support for assistance.
> >
> > anyone seen this or have a fix ?
>
> I've not seen that before. Please provide a bit more detail. Compiler,
> building with ninja or msbuild/visual studio, when exactly you're
> encountering
> the issue, ...
>
> Windows Server 2019
VS 2019
building with ninja

Dave


> Greetings,
>
> Andres Freund
>

errors building on windows using meson

[Dave Cramer]

Greetings,

Getting the following error:

state-exec: run failed: cannot create new executor meta: cannot get
matching bin by path: no matching binary by path
"C:\\Users\\Administrator\\AppData\\Local\\activestate\\cache\\b9117b06\\exec\\perl.EXE"
state-exec: Not user serviceable; Please contact support for assistance.

anyone seen this or have a fix ?

Dave Cramer

[nlug] Re: Chat from Online Meeting

[Tommy TBones Cramer]

I've a the servers we can start with, I'll need help with DNS/Bind9 
services zone configurations, they're install and confirmed working it's 
the zones where I have a challenge. 
I've installed iRedMail.org which can host multiple mail domains if the DNS 
is configured and working(FQDMs required). 
I'll make a few hours time to see if I can install discourse on my home HP 
DL360 Gen8 96M RAM 8 360G 15000RPM SATA I have an additional 64G RAM if 
wanted


On Tuesday, November 14, 2023 at 8:20:40 PM UTC-6 Paul Boniol wrote:

> I can't see any reasons for any objection to posting all of tonight's 
> online chat to the group, so here it is:
>
> Michael Lyda  to  Everyone 6:56 PM
> can you tell people what Proxmox does, for those that haven't used it?
>
> You  to  Everyone 7:42 PM
>
>- I was using Myth TV to record TV. Nice, but there are problems, e.g. 
>all videos are stored in the same directory. File names are like the 
>internal channel number, date and time recorded. No reference to what it 
> is 
>unless you go through the interface, or query the database. (And if you 
>ever have a working instance, you don't want to mess it up by doing a 
> major 
>MythTV update.)
>- I was using Plex to watch the MythTV recordings on the TV, but they 
>stopped allowing plugins, i.e. how Plex interfaced with MythTV. So Plex 
>pissed me off.
>- I looked for an alternative and found Emby. Paid for a perpetual 
>license.
>- If I didn't already pay, I would probably use Jellyfin to make my TV 
>recordings now, which is an open source fork created when Emby went to a 
>pay model.
>- Oh, and the recording source is a HDHomeRun.
>
> Michael Slade  to  Everyone 8:03 PM
> here's the setup guide for discourse. says it takes 30 mins: 
> https://github.com/discourse/discourse/blob/main/docs/INSTALL-cloud.md
> there's also a NixOS config :)
>

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nlug-talk+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/nlug-talk/6e381724-dafc-4a41-9928-ef7bd5949593n%40googlegroups.com.

[RBW] WTT 51cm Sam for 48cm/or ISO 48cm Sam Hillborne

[Ron Cramer]

51cm hiho silver Sam, never built up for a 48 in decent shape.

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5eC6n5LLop6xd%2B_7yF7UUBLuaz24bafk5E2gyujwi5Ozw%40mail.gmail.com.

[RBW] WTT Sam 51cm for 48cm

[Ron Cramer]

Never built up 51cm HiHo Silver Hillborne for a 48, any color, in decent
shape. Thanks

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5eUf2HmFGMauxRxXHrxgmeZQYbYr0-AOp02M-vR9-0qHg%40mail.gmail.com.

Re: [RBW] Re: Has anyone else tried the new Riv seat?

[Ron Cramer]

Didn't. Looks comfortable. If it was a little bit narrower I'd keep it.
NWT. Never mounted.

On Tue, Nov 14, 2023, 10:14 AM Jon Craig (Vendraen) 
wrote:

> Huh - I'm curious.  Did you ever have the black plastic one they included
> with the 2016 Sam completes?  If so, how does it compare?
>
> On Monday, November 13, 2023 at 4:41:29 PM UTC-5 Tom Goodmann wrote:
>
>> Riv shipment just delivered, including the new seat, which I mounted
>> right away for a neighborhood spin.  I find it immediately comfortable and
>> am eager to try it on a longer ride; first impressions are very positive.
>> Have any of you ridden it yet?
>>
>> Now for that new derailer/derailleur!
>>
>> Tom
>> Miami, FL, where it is currently 82ºF
>>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/be7d87ba-cb54-4d13-b407-f668cb0d80c6n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5fE69rTrLAgh9MexE%3DS6eMLoP7GiV2_g3oAUsD3NDZ_rQ%40mail.gmail.com.

Re: [RBW] Has anyone else tried the new Riv seat?

[Ron Cramer]

I have 2. Anyone interested? I'll make you deal.

On Mon, Nov 13, 2023, 3:41 PM Tom Goodmann  wrote:

> Riv shipment just delivered, including the new seat, which I mounted right
> away for a neighborhood spin.  I find it immediately comfortable and am
> eager to try it on a longer ride; first impressions are very positive.
> Have any of you ridden it yet?
>
> Now for that new derailer/derailleur!
>
> Tom
> Miami, FL, where it is currently 82ºF
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/eab04312-1ae8-4162-9197-5af20794c9abn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5c3h1f4z3%2B2gBGtB1PYPQoChZCJRuMq4e4Ux%3DU0x4D%3D7A%40mail.gmail.com.

Re: building with meson on windows with ssl

[Dave Cramer]

On Mon, 13 Nov 2023 at 20:56, Andres Freund  wrote:

> Hi,
>
> On 2023-11-12 11:41:15 -0500, Dave Cramer wrote:
> > On Sun, 12 Nov 2023 at 07:57, Dave Cramer  wrote:
> > > I am getting the following error
> > > building on HEAD
> > >
> > > Library crypto found: YES
> > > Checking for function "CRYPTO_new_ex_data" with dependencies -lssl,
> > > -lcrypto: NO
> > >
> >
> > So this is the error you get if you mix a 64 bit version of openssl and
> > build with x86 tools. Clearly my problem, but the error message is less
> > than helpful
>
> There probably is more detail in meson-logs/meson-log.txt - could you post
> that?
>
I'd have to undo what I did to fix it, but if I find time I will

>
>
> The problem could be related to the fact that on windows you (I think) can
> have binaries with both 32bit and 64bit libraries loaded.
>

I was building with the 32bit tools by mistake.

>
> Was this with msvc or gcc/mingw?
>

msvc

Dave

>
> Greetings,
>
> Andres Freund
>

Re: building with meson on windows with ssl

[Dave Cramer]

On Sun, 12 Nov 2023 at 07:57, Dave Cramer  wrote:

> Greetings,
>
> I am getting the following error
> building on HEAD
>
> Library crypto found: YES
> Checking for function "CRYPTO_new_ex_data" with dependencies -lssl,
> -lcrypto: NO
>

So this is the error you get if you mix a 64 bit version of openssl and
build with x86 tools. Clearly my problem, but the error message is less
than helpful

Dave

>

building with meson on windows with ssl

[Dave Cramer]

Greetings,

I am getting the following error
building on HEAD

Library crypto found: YES
Checking for function "CRYPTO_new_ex_data" with dependencies -lssl,
-lcrypto: NO

I have openssl 1.1.1 installed

Dave Cramer

[nlug] Show & Tell Tuesday

[Tommy TBones Cramer]

I thought it'd be fun to learn what tools we all use for working with Linux 
and what we accomplish with those tools. 
Prepare 2 to 5 minutes with or without screen sharing
Talk about why you use the tool is it the tool supplied by your employer?
What is the tool capable of?
Open Source or closed?
What do you like/dislike about the tool
and what you think other could accomplish with that tool
See you Tuesday November 14, 2023
Tom

-- 
-- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To post to this group, send email to nlug-talk@googlegroups.com
To unsubscribe from this group, send email to 
nlug-talk+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/nlug-talk?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to nlug-talk+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/nlug-talk/4274dd14-e1d6-4c81-9a06-6109bf77908fn%40googlegroups.com.

Re: Right version of jdbc

[Dave Cramer]

On Fri, 29 Sept 2023 at 01:23, Raivo Rebane  wrote:

> But goes worst if I am using
> postgis-geometry-2021.1.0.jar
>
> Raivo
>
> On Fri, Sep 29, 2023 at 8:14 AM Raivo Rebane  wrote:
>
>> It goes better, if I add postgis-geometry-2.5.0.jar and Eclipse founds
>>
>> import org.postgis.Point;
>>
>>
>> Raivo
>>
>> On Fri, Sep 29, 2023 at 7:18 AM Raivo Rebane  wrote:
>>
>>> If I use this jar i give errors - Description Resource Path Location Type
>>> PGgeometry cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 22 Java Problem
>>> PGgeometry cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 46 Java Problem
>>> PGgeometry cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 46 Java Problem
>>> Point cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 14 Java Problem
>>> Point cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 35 Java Problem
>>> Point cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 47 Java Problem
>>> Point cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 47 Java Problem
>>> Point cannot be resolved to a type ProcAddMushrooms.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 83 Java Problem
>>> Point cannot be resolved to a type Utils.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 9 Java Problem
>>> Point cannot be resolved to a type Utils.java
>>> /KatseAPIs/src/main/java/MushroomAPIs line 22 Java Problem
>>>
>>> Raivo
>>>
>>> On Thu, Sep 28, 2023 at 11:06 PM Dave Cramer 
>>> wrote:
>>>
>>>> The latest version of postgis-jdbc is Maven Repository: net.postgis »
>>>> postgis-jdbc » 2021.1.0 (mvnrepository.com)
>>>> <https://mvnrepository.com/artifact/net.postgis/postgis-jdbc/2021.1.0>
>>>> Dave Cramer
>>>> www.postgres.rocks
>>>>
>>>>
>>>> On Thu, 28 Sept 2023 at 14:51, Raivo Rebane 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The same problem of postgres-jdbc compatibility remains and I pushed
>>>>> it to github - https://github.com/raaivore/APIexperiment.
>>>>>
>>>>> I am using Postgres 15 and Java 1.8 and Tomcat9.
>>>>> Maybe somebody can help me to solve the problem.
>>>>>
>>>>> Regards
>>>>> Raivo
>>>>>
>>>>
Sorry, I just realized I dropped the ball here. Did you ever figure this
out ?
Dave

Re: Performance problems with Postgres JDBC 42.4.2

[Dave Cramer]

On Mon, 6 Nov 2023 at 09:59, Jose Osinde  wrote:

>
> Dear all,
>
> I'm running a query  from Java on a postgres database:
>
> Java version: 17
> JDBC version: 42.4.2
> Postgres version: 13.1
>
> In parallel I'm testing the same queries from pgAdmin 4 version 6.13
>
> The tables I'm using contains more than 10million rows each and I have two
> questions here:
>
> 1. I need to extract the path of a file without the file itself. For this
> I use two alternatives as I found that sentence "A" is much faster than
> the "B" one:
>
> "A" sentence:
>
> SELECT DISTINCT ( LEFT(opf.file_path, length(opf.file_path) - position('/'
> in reverse(opf.file_path))) ) AS path
>FROM product AS op JOIN product_file AS opf ON
> opf.product_id = op.id
>WHERE op.proprietary_end_date <= CURRENT_DATE
> AND op.id LIKE 'urn:esa:psa:%'
>
> "B" sentence:
>
> SELECT DISTINCT ( regexp_replace(opf.file_path, '(.*)\/(.*)$', '\1') ) AS
> path
>FROM product AS op JOIN product_file AS opf ON
> opf.product_id = op.id
>WHERE op.proprietary_end_date <= CURRENT_DATE
> AND op.id LIKE 'urn:esa:psa:%'
>
> 2. Running sentence "A" on the pgAdmin client takes 4-5 minutes to finish
> but running it from a Java program it never ends. This is still the case
> when I limit the output to the first 100 rows so I assume this is not a
> problem with the amount of data being transferred but the way postgres
> resolve the query. To make it work in Java I had to define a postgres
> function that I call from the Java code instead of running the query
> directly.
>
> I had a similar problem in the past with a query that performed very
> poorly from a Java client while it was fine from pgAdmin or a python
> script. In that case it was a matter of column types not compatible with
> the JDBC (citext) deriving in an implicit cast that prevented the
> postgres engine from using a given index or to cast all the values of that
> column before using it, not sure now. But I don't think this is not the
> case here.
>
> Could anyone help me again?
>

Can you share your java code ?

If you are using a PreparedStatement the driver will use the extended
protocol which may be slower. Statements use SimpleQuery which is faster
and more like pgadmin

Issuing a Query and Processing the Result | pgJDBC (postgresql.org)



Dave

>
>

Re: Protocol question regarding Portal vs Cursor

[Dave Cramer]

Dave Cramer


On Tue, 7 Nov 2023 at 10:26, Tom Lane  wrote:

> Dave Cramer  writes:
> > If we use a Portal it is possible to open the portal and do a describe
> and
> > then Fetch N records.
>
> > Using a Cursor we open the cursor. Is there a corresponding describe and
> a
> > way to fetch N records without getting the fields each time. Currently we
> > have to send the SQL  "fetch  N" and we get the fields and the
> > rows. This seems overly verbose.
>
> Portals and cursors are pretty much the same thing, so why not use
> the API that suits you better?
>

So in this case this is a refcursor. Based on above then I should be able
to do a describe on the refcursor and fetch using the extended query
protocol

Cool!

Dave

Protocol question regarding Portal vs Cursor

[Dave Cramer]

Greetings,

If we use a Portal it is possible to open the portal and do a describe and
then Fetch N records.

Using a Cursor we open the cursor. Is there a corresponding describe and a
way to fetch N records without getting the fields each time. Currently we
have to send the SQL  "fetch  N" and we get the fields and the
rows. This seems overly verbose.

Dave Cramer

Re: [RBW] Bike Rack

[Ron Cramer]

IMHO the Kuat Sherpa. Had other racks, but this is my favorite. The Sherpa
is light, therefore easy to mount. But I would use an additional cable lock.

On Sat, Nov 4, 2023, 1:35 PM SallyG <3mun...@gmail.com> wrote:

> Hi all!
> Any bike rack you'd recommend for Clem Smith L 45 cm and future Platy 50
> cm for husband? Kuat or? Model? Thanks for any help!
> Sally
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/960e898e-fbe1-42f5-9a4c-4322482ee328n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5f5G-1%2Bg3w4GyoNwJzL1P-Q0fa-%2BEtBEWBg%3DAfu3HRVag%40mail.gmail.com.

[RBW] IS0 Soma Eagle handlebar

[Ron Cramer]

Looking for a Soma Eagle handlebar.  Anyone got one you are willing to
sell? Thanks

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5e4bAuGSDJ9-NUESA4WiYpxTHi298fWBarXB9P%2BmiFyEQ%40mail.gmail.com.

iPhone Photos

[Tom Cramer]

Hello,
I have been using the new Be My AI service and it has been great at
describing all of the photos in my photos app.
Is there a way to either label or rename these photos now that I know
what they are so that I can find them easier? I would think there
would have to be an easy way of labeling them but ca't see how.
Thanks.

-- 
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/CAPr-VTpNOB_%2BGJgvok%3DSNE%2B%2BT-2geNyucaEeQd1rQ55gdie1Vw%40mail.gmail.com.

Re: Driver Postgresql HP-Unix

[Dave Cramer]

On Sat, 21 Oct 2023 at 05:50, Justin Clift  wrote:

> On 2023-10-19 04:45, Abelardo Erazo Lopez wrote:
> > Hi, Everyone
> >
> > I have an Oracle database Oracle 19c and I need to access a PostgreSQL
> > database 15.4  that resides on a different server. I see that one
> > alternative is to use ODBC from Oracle. However, the server where the
> > database resides is an HP-UX server and I understand that I need a
> > PostgreSQL driver manager compatible with this operating system. Can
> > you help me by indicating if there is one available, where to obtain
> > it, and if it requires a license?
>
> Any idea which version of HP-UX is running on that PostgreSQL server?
>
> Also, are you *sure* it's PostgreSQL 15.4, and not PostgreSQL 12.4?
>
> Asking because I'm not seeing version PG 15.4 in the list here, though
> PG 12.4 and 16 are:
>
>http://hpux.connect.org.uk/hppd/cgi-bin/search?term=postgresql


I do not believe we publish the binaries for HP-UX but you should be able
to build it.

Dave

building 32bit windows version

[Dave Cramer]

Greetings,

I've been running into challenges building 32 bit windows version. I
suspect there are no build farms and nobody really builds this.

The reason I need these is to be able to build 32 bit dll's for ODBC. At
one time EDB used to provide binaries but that doesn't appear to be the
case.

running build.bat in an x86 environment fails but that can be easily fixed
by adding

$ENV{CONFIG}="x86"; in buld_env.pl

build postgres then works as advertised, however

install  fails with

"Copying build output files...Could not copy release\zic\zic.exe to
postgres\bin\zic.exe"

Apparently 32 bit dlls are required. If there is an easier way to get
libpq.dll and the include files for building I'm all ears.


Dave Cramer

Re: Request for comment on setting binary format output per session

[Dave Cramer]

On Tue, 10 Oct 2023 at 10:25, Robert Haas  wrote:

> On Mon, Oct 9, 2023 at 4:25 PM Jeff Davis  wrote:
> > Another thing to consider is that using a GUC for binary formats is a
> > protocol change in a way that client_encoding is not. The existing
> > documentation for the protocol already specifies when binary formats
> > will be used, and a GUC would change that behavior. We absolutely would
> > need to update the documentation, and clients (like psql) really should
> > be updated.
>
> I think the idea of using a new parameterFormat value is a good one.
> Let 0 and 1 continue to mean what they mean, and let clients opt in to
> the new mechanism if they're aware of it.
>

Correct me if I am wrong, but the client has to request this. So I'm not
sure how we would be surprised ?

Dave

Re: Request for comment on setting binary format output per session

[Dave Cramer]

On Mon, 9 Oct 2023 at 17:11, Jelte Fennema  wrote:

> On Mon, 9 Oct 2023 at 21:08, Dave Cramer  wrote:
> > So if we use . would it be possible to have something like
>  which represents a set of well known types?
> > My goal here is to reduce the overhead of naming all the types the
> client  wants in binary. The list of well known types is pretty long.
> > Additionally we could have a shorthand for removing a well known type.
>
> You're only setting this once in the lifetime of the connection right,
>

Correct

> i.e. right at the start (although pgbouncer could set it once per
> transaction in the worst case). It seems like it shouldn't really
> matter much to optimize the size of the "SET format_binary=..."
> command, I'd expect it to be at most 1 kilobyte. I'm not super opposed
> to having a shorthand for some of the most commonly wanted built-in
> types, but then we'd need to decide on what those are, which would add
> even more discussion/bikeshedding to this thread. I'm not sure the win
> in size is worth that effort.
>
It's worth the effort if we use schema.typename, if we use oids then I'm
not that invested in this approach.

Dave

Re: Request for comment on setting binary format output per session

[Dave Cramer]

On Mon, 9 Oct 2023 at 15:00, Robert Haas  wrote:

> On Mon, Oct 9, 2023 at 11:09 AM Jelte Fennema  wrote:
> > Since the protocol already returns OIDs in the ParameterDescription
> > and RowDescription messages I don't see why using OIDs for this GUC
> > would cause any additional problems.
>
> ...but then...
>
> > With Citus the same user defined type can have
> > different OIDs on each of the servers in the cluster.
>
> I realize that your intention here may be to say that this is not an
> *additional* problem but one we have already. But it seems like one
> that we ought to be trying to solve, rather than propagating a
> problematic solution into more places.
>
> Decisions we make about the wire protocol are some of the most
> long-lasting and painful decisions we make, right up there with the
> on-disk format. Maybe worse, in some ways.
>

So if we use . would it be possible to have something like
 which represents a set of well known types?
My goal here is to reduce the overhead of naming all the types the client
wants in binary. The list of well known types is pretty long.
Additionally we could have a shorthand for removing a well known type.

Dave

Change of behaviour for creating same type name in multiple schemas

[Dave Cramer]

Greetings,

Before 16 if I created an array type in schema1 it would be named
schema1._array_type
if I created the same type in schema 2 it would have been named

schema2.__array_type

Can someone point me to where the code was changed ?

Thanks,
Dave Cramer

Re: Request for comment on setting binary format output per session

[Dave Cramer]

On Wed, 4 Oct 2023 at 10:17, Peter Eisentraut  wrote:

> On 31.07.23 18:27, Dave Cramer wrote:
> > On Mon, 10 Jul 2023 at 03:56, Daniel Gustafsson  > <mailto:dan...@yesql.se>> wrote:
> >
> >  > On 25 Apr 2023, at 16:47, Dave Cramer  > <mailto:davecra...@gmail.com>> wrote:
> >
> >  > Patch attached with comments removed
> >
> > This patch no longer applies, please submit a rebased version on top
> > of HEAD.
> >
> >
> > Rebased see attached
>
> I have studied this thread now.  It seems it has gone through the same
> progression with the same (non-)result as my original patch on the subject.
>
> I have a few intermediate conclusions:
>
> - Doing it with a GUC is challenging.  It's questionable layering to
> have the GUC system control protocol behavior.  It would allow weird
> behavior where a GUC set, maybe for a user or a database, would confuse,
> say, psql or pg_dump.  We probably should make some of those more robust
> in any case.  Also, handling of GUCs through connection poolers is a
> challenge.  It does work, but it's more like opt-in, and so can't be
> fully relied on for protocol correctness.
>
> - Doing it with a session-level protocol-level setting is challenging.
> We currently don't have that kind of thing.  It's not clear how
> connection poolers would/should handle it.  Someone would have to work
> all this out before this could be used.
>
> - In either case, there are issues like what if there is a connection
> pooler and types have different OIDs in different databases.  (Or,
> similarly, an extension is upgraded during the lifetime of a session and
> a type's OID changes.)  Also, maybe, what if types are in different
> schemas on different databases.
>
> - We could avoid some of the session-state issues by doing this per
> request, like extending the Bind message somehow by appending the list
> of types to be sent in binary.  But the JDBC driver currently lists 24
> types for which it supports binary, so that would require adding 24*4=96
> bytes per request, which seems untenable.
>
> I think intuitively, this facility ought to work like client_encoding.
> There, the client declares its capabilities, and the server has to
> format the output according to the client's capabilities.  That works,
> and it also works through connection poolers.  (It is a GUC.)  If we can
> model it like that as closely as possible, then we have a chance of
> getting it working reliably.  Notably, the value space for
> client_encoding is a globally known fixed list of strings.  We need to
> figure out what is the right way to globally identify types, like either
> by fully-qualified name, by base name, some combination, how does it
> work with extensions, or do we need a new mechanism like UUIDs.  I think
> that is something we need to work out, no matter which protocol
> mechanism we end up using.
>

So how is this different than the GUC that I proposed ?

Dave

Re: Right version of jdbc

[Dave Cramer]

Again, can you please post the solution so others can learn as well ?

Dave Cramer
www.postgres.rocks


On Sat, 30 Sept 2023 at 06:49, Raivo Rebane  wrote:

> Thanks for very much for help.
> It seems that I can do the test project for new job.
> In future I use help of chat.gpt
>
> Regards
> Raivo
>
> On Sat, Sep 30, 2023 at 11:15 AM  wrote:
>
>> Am 30.09.23 um 08:33 schrieb Raivo Rebane:
>> > Hi,
>> > sometimes I am lucky and don't get the old error, but sometime not.
>> >
>> > I tried to use PreparedStatement, but I got error -
>> > org.postgresql.util.PSQLException: Can't use query methods that take a
>> > query string on a PreparedStatement.
>> >  at
>> >
>> org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:145)
>> >  at MushroomAPIs.Clean.deleteAllRecordsFromTable(Clean.java:34)
>> >   and java code is -
>> >
>> > String deleteQuery = "DELETE FROM " + tableNam
>> >
>> > System.out.println(deleteQuery);
>> >
>> > PreparedStatement statement = connection.prepareStatement(deleteQuery);
>> if your statement is already prepared with query, use
>> statement.exequte(); or statement.executeQuery() without querystring;
>> if you have a new statement without query, use execute and such with
>> query string.
>> >
>> > May be it's easy for me to use normal statement ?
>> >
>> >
>> > Raivo
>> >
>> >
>> > On Sat, Sep 30, 2023 at 8:27 AM Raivo Rebane 
>> wrote:
>> [snip]
>>
>>
>> Am 30.09.23 um 09:18 schrieb Raivo Rebane:
>> > I fix previous error what was my bad knowledge,
>> > But new error occur which is related to postgres postgis jars.
>> > If You are kind to answer me more;
>> >
>> > Java code is :
>> >
>> > public static boolean CheckIsNewInMushrooms(Connection connection, Point
>> > AddLocation, String AddDescription) {
>> >
>> > boolean IsNew = true;
>> >
>> >
>> > try {
>> >
>> > String sqlQuery = "SELECT location, description FROM mushrooms";
>> >
>> > try (PreparedStatement preparedStatement = connection.prepareStatement(
>> > sqlQuery)) {
>> >
>> > ResultSet resultSet = preparedStatement.executeQuery();
>> >
>> >
>> > while (resultSet.next()) {
>> >
>> > Point point = (Point) resultSet.getObject("location");
>> >
>> > String description = resultSet.getString("description");
>> >
>> >
>> > if (AddLocation.x == point.x && AddLocation.y == point.y &&
>> AddDescription
>> > .equals(description))
>> >
>> > IsNew = false;
>> >
>> > }
>> >
>> > }
>> >
>> > } catch (SQLException e) {
>> >
>> > e.printStackTrace();
>> >
>> > }
>> >
>> >
>> > return IsNew;
>> >
>> > }
>> >
>> > and at line
>> >
>> > Point point = (Point) resultSet.getObject("location");
>> >
>> >
>> > java.lang.ClassCastException: org.postgresql.util.PGobject cannot be
>> cast
>> > to org.postgis.Point
>> >  at
>> >
>> MushroomAPIs.ProcAddMushrooms.CheckIsNewInMushrooms(ProcAddMushrooms.java:45)
>> > How to get Point from resultset ?
>> > Is it related to postgis driver ?
>> try another way to cast to Point.
>> look for the way over PGgeometry like here
>> https://postgis.net/docs/manual-3.3/ch07.html#idm3092
>> >
>> > Regards
>> > Raivo
>>
>>
>>

Re: Right version of jdbc

[Dave Cramer]

On Fri, 29 Sept 2023 at 14:22, Raivo Rebane  wrote:

> Thanks,
>
> there was really JDK 17 in use.
> I changed it to Java 1.8
> PS C:\Program Files\Apache Software Foundation\Tomcat 9.0\bin> java
> -version
> java version "1.8.0_381"
> Java(TM) SE Runtime Environment (build 1.8.0_381-b09)
> Java HotSpot(TM) 64-Bit Server VM (build 25.381-b09, mixed mode)
>
> but the same error occured :
> java.sql.SQLException: No suitable driver found for
> jdbc:postgresql://localhost:5432/mushroom_database
> at java.sql.DriverManager.getConnection(DriverManager.java:689)
> at java.sql.DriverManager.getConnection(DriverManager.java:247)
> at MushroomAPIs.AddMushrooms.doGet(AddMushrooms.java:30)
>  why  java.sql gives that error ?
>

for some reason the postgresql jar is not in the classpath.

Dave

>

Re: Right version of jdbc

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Fri, 29 Sept 2023 at 06:19, Raivo Rebane  wrote:

> Hi,
>
> The code is :
> package MushroomAPIs;
>
> import java.io.IOException;
> import javax.servlet.ServletException;
> import javax.servlet.annotation.WebServlet;
> import javax.servlet.http.HttpServlet;
> import javax.servlet.http.HttpServletRequest;
> import javax.servlet.http.HttpServletResponse;
>
> import java.sql.Connection;
> import java.sql.DriverManager;
> import java.sql.PreparedStatement;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Timestamp;
>
> @WebServlet("/AddMushrooms")
> public class AddMushrooms extends HttpServlet implements
> java.io.Serializable {
> protected void doGet(HttpServletRequest request, HttpServletResponse
> response)
> throws ServletException, IOException {
>
> final String DB_URL = "jdbc:postgresql://localhost:5432/mushroom_database";
> final String USER = "mushroomer";
> final String PASSWORD = "";
>
> Connection connection = null;
> Timestamp LastModifiedTS = Timestamp.valueOf("1970-01-01 00:00:00");
>
> try {
> connection = DriverManager.getConnection(DB_URL, USER, PASSWORD);
>
> // SQL päring vanima timestamp-i leidmiseks
> String query = "SELECT timestamp AS oldest_timestamp FROM mushrooms";
> PreparedStatement statement = connection.prepareStatement(query);
> ResultSet resultSet = statement.executeQuery();
>
> while (resultSet.next()) {
> Timestamp oldest_timestamp = resultSet.getTimestamp("oldest_timestamp");
> if (oldest_timestamp.after(LastModifiedTS))
> LastModifiedTS = oldest_timestamp;
> }
> System.out.println("Vanim timestamp: " + LastModifiedTS);
>
> } catch (SQLException e) {
> e.printStackTrace();
> }
>
> int count = ProcAddMushrooms.GetAddMushrooms(connection, LastModifiedTS);
>
> response.getWriter().println("Added " + count + " mushrooms");
> }
> }
> and available from github - https://github.com/raaivore/APIexperiment
>
> May be somebody can help me to solve the problem ?
>
> Raivo
>
> On Fri, Sep 29, 2023 at 6:44 AM Ron  wrote:
>
>> On 9/28/23 01:18, Raivo Rebane wrote:
>>
>> [snip]
>>
>> I made a new Java application Eclipse Dynamic WEB application and want to
>> use Postgres - PostgreSQL 10.14
>>
>> [snip]
>>
>> What's wrong. Or is better to use more newer postgres. And then which
>> jdbc-I need to use ?
>>
>>
>> https://www.postgresql.org/support/versioning/
>>
>> Pg 10 will be EOL in *6 weeks*.  Thus, "yes, use a newer version of
>> Postgresql" (unless, like me, you're constrained by circumstances like "the
>> business won't let us upgrade").
>>
>> Pg 15 and the latest JDBC are in the repositories:
>> https://www.postgresql.org/download/
>>
> --
>> Born in Arizona, moved to Babylonia.
>>
>


I loaded your project in IDEA and it was referring to jdk1.7
It also looks like you still have the postgis-geometry-2.5.0.jar in the
webapp/lib dir remove it

Dave

Re: Right version of jdbc

[Dave Cramer]

The latest version of postgis-jdbc is Maven Repository: net.postgis »
postgis-jdbc » 2021.1.0 (mvnrepository.com)
<https://mvnrepository.com/artifact/net.postgis/postgis-jdbc/2021.1.0>
Dave Cramer
www.postgres.rocks


On Thu, 28 Sept 2023 at 14:51, Raivo Rebane  wrote:

> Hi,
>
> The same problem of postgres-jdbc compatibility remains and I pushed it to
> github - https://github.com/raaivore/APIexperiment.
>
> I am using Postgres 15 and Java 1.8 and Tomcat9.
> Maybe somebody can help me to solve the problem.
>
> Regards
> Raivo
>

Re: Right version of jdbc

[Dave Cramer]

Please put this project on github so we can see it.

Thanks
Dave Cramer
www.postgres.rocks


On Thu, 28 Sept 2023 at 11:53, Raivo Rebane  wrote:

> Or may be I am using wrong version of Java - java version "17.0.8"
> 2023-07-18 LTS
>
> Raivo
>
> On Thu, Sep 28, 2023 at 6:41 PM Raivo Rebane  wrote:
>
>> Now I changed the Postgres Server to version 15 and making Tomcat 9.0
>> project.
>> Now I am using postgresql-42.6.0.jar driver, but Tomcat gives error :
>> java.sql.SQLException: No suitable driver found for
>> jdbc:postgresql://localhost:5432/mushroom_database
>> What driver I have to use for suitable driver.
>> Or must I downgrade my postgres version ?
>>
>> Regards
>> Raivo
>>
>> On Thu, Sep 28, 2023 at 12:32 PM Dave Cramer 
>> wrote:
>>
>>>
>>> Dave Cramer
>>> www.postgres.rocks
>>>
>>>
>>> On Thu, 28 Sept 2023 at 02:18, Raivo Rebane  wrote:
>>>
>>>> Hi,
>>>>
>>>> I made a new Java application Eclipse Dynamic WEB application and want
>>>> to use Postgres - PostgreSQL 10.14 on x86_64-pc-linux-gnu, compiled by gcc
>>>> (Ubuntu 9.3.0-10ubuntu2) 9.3.0, 64-bit and Postgis - 2.4 USE_GEOS=1
>>>> USE_PROJ=1 USE_STATS=1.
>>>>
>>>> I added some jdbc-s in my project webapps/WEB-INF/lib directory which
>>>> now contains - javax.servlet-api.jar  postgis-jdbc-2.2.1.jar
>>>>  postgresql-42.2.5.jre7.jar.
>>>>
>>>
>>>   postgresql-42.2.5.jre7.jar. is for java 7.
>>> I suggest you use the latest versions of postgis and postgres jdbc
>>>
>>> Dave
>>>
>>>>
>>>> But they don't fit the needs and I got from tomcat -
>>>> java.sql.SQLException: No suitable driver found for
>>>> jdbc:postgresql://localhost:5432/mushroom_database
>>>> at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:702)
>>>> at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228)
>>>> at MushroomAPIs.AddMushrooms.doGet(AddMushrooms.java:30)
>>>>
>>>> What's wrong. Or is better to use more newer postgres. And then which
>>>> jdbc-I need to use ?
>>>>
>>>> Regards
>>>> Raivo
>>>>
>>>>
>>>>
>>>> On Wed, Sep 27, 2023 at 12:43 PM Dave Cramer 
>>>> wrote:
>>>>
>>>>> First of all please use reply all so that everyone sees the answers.
>>>>>
>>>>> Not sure since PgObject is certainly in the jdbc jar. 
>>>>> pgjdbc/pgjdbc/src/main/java/org/postgresql/util/PGobject.java
>>>>> at 5709a20fbef453749d2394e11502527e4a3ab5bb · pgjdbc/pgjdbc (github.com)
>>>>> <https://github.com/pgjdbc/pgjdbc/blob/5709a20fbef453749d2394e11502527e4a3ab5bb/pgjdbc/src/main/java/org/postgresql/util/PGobject.java#L19>
>>>>>
>>>>> I suggest at this point you provide a test project on github that you
>>>>> can share.
>>>>>
>>>>> There is something wrong with the classpath
>>>>>
>>>>> Dave Cramer
>>>>> www.postgres.rocks
>>>>>
>>>>>
>>>>> On Wed, 27 Sept 2023 at 01:52, Raivo Rebane 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> Thanks for response, but if I using following dependencies :
>>>>>>
>>>>>> 
>>>>>>
>>>>>> 
>>>>>>
>>>>>> net.postgis
>>>>>>
>>>>>> postgis-jdbc
>>>>>>
>>>>>> 2021.1.0
>>>>>>
>>>>>> 
>>>>>>
>>>>>> 
>>>>>>
>>>>>> org.postgresql
>>>>>>
>>>>>> postgresql
>>>>>>
>>>>>> 42.6.0 
>>>>>>
>>>>>> 
>>>>>>
>>>>>> 
>>>>>>
>>>>>> I have error :
>>>>>>
>>>>>> The type org.postgresql.util.PGobject cannot be resolved. It is
>>>>>> indirectly referenced from required type org.postgis.PGgeometry
>>>>>>
>>>>>>
>>>>>> What is wrong with me ?
>>>>>>
>>>>>>
>>>>>> Raivo
>>>>>>
>>>>>

Re: Right version of jdbc

[Dave Cramer]

Dave Cramer
www.postgres.rocks


On Thu, 28 Sept 2023 at 02:18, Raivo Rebane  wrote:

> Hi,
>
> I made a new Java application Eclipse Dynamic WEB application and want to
> use Postgres - PostgreSQL 10.14 on x86_64-pc-linux-gnu, compiled by gcc
> (Ubuntu 9.3.0-10ubuntu2) 9.3.0, 64-bit and Postgis - 2.4 USE_GEOS=1
> USE_PROJ=1 USE_STATS=1.
>
> I added some jdbc-s in my project webapps/WEB-INF/lib directory which now
> contains - javax.servlet-api.jar  postgis-jdbc-2.2.1.jar
>  postgresql-42.2.5.jre7.jar.
>

  postgresql-42.2.5.jre7.jar. is for java 7.
I suggest you use the latest versions of postgis and postgres jdbc

Dave

>
> But they don't fit the needs and I got from tomcat -
> java.sql.SQLException: No suitable driver found for
> jdbc:postgresql://localhost:5432/mushroom_database
> at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:702)
> at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228)
> at MushroomAPIs.AddMushrooms.doGet(AddMushrooms.java:30)
>
> What's wrong. Or is better to use more newer postgres. And then which
> jdbc-I need to use ?
>
> Regards
> Raivo
>
>
>
> On Wed, Sep 27, 2023 at 12:43 PM Dave Cramer 
> wrote:
>
>> First of all please use reply all so that everyone sees the answers.
>>
>> Not sure since PgObject is certainly in the jdbc jar. 
>> pgjdbc/pgjdbc/src/main/java/org/postgresql/util/PGobject.java
>> at 5709a20fbef453749d2394e11502527e4a3ab5bb · pgjdbc/pgjdbc (github.com)
>> <https://github.com/pgjdbc/pgjdbc/blob/5709a20fbef453749d2394e11502527e4a3ab5bb/pgjdbc/src/main/java/org/postgresql/util/PGobject.java#L19>
>>
>> I suggest at this point you provide a test project on github that you can
>> share.
>>
>> There is something wrong with the classpath
>>
>> Dave Cramer
>> www.postgres.rocks
>>
>>
>> On Wed, 27 Sept 2023 at 01:52, Raivo Rebane  wrote:
>>
>>> Hi,
>>> Thanks for response, but if I using following dependencies :
>>>
>>> 
>>>
>>> 
>>>
>>> net.postgis
>>>
>>> postgis-jdbc
>>>
>>> 2021.1.0
>>>
>>> 
>>>
>>> 
>>>
>>> org.postgresql
>>>
>>> postgresql
>>>
>>> 42.6.0 
>>>
>>> 
>>>
>>> 
>>>
>>> I have error :
>>>
>>> The type org.postgresql.util.PGobject cannot be resolved. It is
>>> indirectly referenced from required type org.postgis.PGgeometry
>>>
>>>
>>> What is wrong with me ?
>>>
>>>
>>> Raivo
>>>
>>

Re: [RBW] Looking For: dia compe 610s?

[Ron Cramer]

I have a pair. $30/ea + shipping?

On Tue, Sep 26, 2023, 8:24 PM Michael Baquerizo 
wrote:

> Thinking i'd like to try center pulls out on my next build. Anyone have a
> set they'd be interested in letting go?
>
> I don't have any of the necessary accoutrements either, front and rear
> cable hangers.
>
> Thanks in advance
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/55a68a6b-782b-4dbd-92f3-7b5a97f2f1b9n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CA%2BMcg5dNy530J86AkfSfD5eAD5b7dmEa_-OvrjTtk7V%2Bck6Oeg%40mail.gmail.com.

Re: Right version of jdbc

[Dave Cramer]

First of all please use reply all so that everyone sees the answers.

Not sure since PgObject is certainly in the jdbc jar.
pgjdbc/pgjdbc/src/main/java/org/postgresql/util/PGobject.java
at 5709a20fbef453749d2394e11502527e4a3ab5bb · pgjdbc/pgjdbc (github.com)
<https://github.com/pgjdbc/pgjdbc/blob/5709a20fbef453749d2394e11502527e4a3ab5bb/pgjdbc/src/main/java/org/postgresql/util/PGobject.java#L19>

I suggest at this point you provide a test project on github that you can
share.

There is something wrong with the classpath

Dave Cramer
www.postgres.rocks


On Wed, 27 Sept 2023 at 01:52, Raivo Rebane  wrote:

> Hi,
> Thanks for response, but if I using following dependencies :
>
> 
>
> 
>
> net.postgis
>
> postgis-jdbc
>
> 2021.1.0
>
> 
>
> 
>
> org.postgresql
>
> postgresql
>
> 42.6.0 
>
> 
>
> 
>
> I have error :
>
> The type org.postgresql.util.PGobject cannot be resolved. It is indirectly
> referenced from required type org.postgis.PGgeometry
>
>
> What is wrong with me ?
>
>
> Raivo
>

Re: Right version of jdbc

[Dave Cramer]

You should probably be using the latest version of postgis-jdbc

Maven Repository: net.postgis » postgis-jdbc » 2021.1.0 (mvnrepository.com)
<https://mvnrepository.com/artifact/net.postgis/postgis-jdbc/2021.1.0>

Dave Cramer
www.postgres.rocks


On Mon, 25 Sept 2023 at 08:43, Raivo Rebane  wrote:

> And target/lib is s following :
> Directory of C:\Users\Raivo\eclipse-workspace\backendproject\target\lib
>
> 25.09.2023  15:35  .
> 25.09.2023  15:33  ..
> 25.09.2023  15:33   214 381 checker-qual-3.5.0.jar
> 25.09.2023  13:1475 847 postgis-jdbc-1.3.3.jar
> 25.09.2023  13:14 2 833 postgis-stubs-1.3.3.jar
> 25.09.2023  15:33 1 049 651 postgresql-42.5.4.jar
> 25.09.2023  13:14   474 746 postgresql-8.3-603.jdbc4.jar
>
> Raivo
>
>
> On Mon, Sep 25, 2023 at 3:38 PM Raivo Rebane  wrote:
>
>> Hi, now I use -
>>   
>> 
>> org.postgis
>> postgis-jdbc
>> 1.3.3
>> 
>> 
>> org.postgresql
>> postgresql
>> 42.5.4 
>> 
>>   
>> But I got error -
>> Exception in thread "main" java.lang.NoSuchMethodError:
>> 'org.postgresql.core.Encoding
>> org.postgresql.core.BaseConnection.getEncoding()'
>> at
>> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getString(AbstractJdbc2ResultSet.java:1889)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:438)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:2406)
>> at backendproject.BackendMain.main(BackendMain.java:64)
>>
>> Whats wrong ?
>>
>> Raivo
>>
>> On Mon, Sep 25, 2023 at 3:26 PM Raivo Rebane  wrote:
>>
>>> Hi,
>>> now I using following -
>>> [INFO] Copying postgis-jdbc-2.1.7.jar to
>>> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\postgis-jdbc-2.1.7.jar
>>> [INFO] Copying postgresql-42.6.0.jar to
>>> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\postgresql-42.6.0.jar
>>> [INFO] Copying checker-qual-3.31.0.jar to
>>> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\checker-qual-3.31.0.jar
>>> but on executions I got -
>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>> org/postgis/PGgeometry
>>> at
>>> backendproject.ProcQueryMushrooms.ProcQuery(ProcQueryMushrooms.java:41)
>>> at backendproject.BackendMain.main(BackendMain.java:81)
>>> Caused by: java.lang.ClassNotFoundException: org.postgis.PGgeometry
>>> at
>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>>     at
>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>>     at
>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>>>
>>> What I have to do ?
>>>
>>> I use following -
>>> PostgreSQL 15.2, compiled by Visual C++ build 1914, 64-bit
>>> PostGIS  3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>>> Regards
>>> Raivo
>>>
>>> On Mon, Sep 25, 2023 at 2:29 PM Dave Cramer 
>>> wrote:
>>>
>>>> Sorry 42.6.0
>>>>
>>>> Interesting that github still has 42.5.4 as the release
>>>>
>>>> Dave Cramer
>>>> www.postgres.rocks
>>>>
>>>>
>>>> On Mon, 25 Sept 2023 at 07:27, Dave Cramer 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The latest version of the driver is usually the right answer. So 42.5.4
>>>>> Dave Cramer
>>>>> www.postgres.rocks
>>>>>
>>>>>
>>>>> On Mon, 25 Sept 2023 at 07:03, Raivo Rebane 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I use :
>>>>>>   PostgreSQL 15.2, compiled by Visual C++ build 1914, 64-bit
>>>>>> and
>>>>>> PostGIS  3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>>>>>>
>>>>>> What versions of jdbc driver I have to use for proper work ?
>>>>>>
>>>>>> Regards,
>>>>>> Raivo
>>>>>>
>>>>>>
>>>>>>
>>>>>>

Re: Right version of jdbc

[Dave Cramer]

It must be a dependency to something. postgis ?


Dave Cramer
www.postgres.rocks


On Mon, 25 Sept 2023 at 09:25, Raivo Rebane  wrote:

> Hi,
> postgresql-8.3-603.jdbc4.jar is added by maven maven install. How to
> avoid it ?
>

Re: Right version of jdbc

[Dave Cramer]

remove the postgresql-8.3-603.jdbc4.jar
Dave Cramer
www.postgres.rocks


On Mon, 25 Sept 2023 at 08:43, Raivo Rebane  wrote:

> And target/lib is s following :
> Directory of C:\Users\Raivo\eclipse-workspace\backendproject\target\lib
>
> 25.09.2023  15:35  .
> 25.09.2023  15:33  ..
> 25.09.2023  15:33   214 381 checker-qual-3.5.0.jar
> 25.09.2023  13:1475 847 postgis-jdbc-1.3.3.jar
> 25.09.2023  13:14 2 833 postgis-stubs-1.3.3.jar
> 25.09.2023  15:33 1 049 651 postgresql-42.5.4.jar
> 25.09.2023  13:14   474 746 postgresql-8.3-603.jdbc4.jar
>
> Raivo
>
>
> On Mon, Sep 25, 2023 at 3:38 PM Raivo Rebane  wrote:
>
>> Hi, now I use -
>>   
>> 
>> org.postgis
>> postgis-jdbc
>> 1.3.3
>> 
>> 
>> org.postgresql
>> postgresql
>> 42.5.4 
>> 
>>   
>> But I got error -
>> Exception in thread "main" java.lang.NoSuchMethodError:
>> 'org.postgresql.core.Encoding
>> org.postgresql.core.BaseConnection.getEncoding()'
>> at
>> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getString(AbstractJdbc2ResultSet.java:1889)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:438)
>> at
>> org.postgresql.jdbc2.AbstractJdbc2ResultSet.getTimestamp(AbstractJdbc2ResultSet.java:2406)
>> at backendproject.BackendMain.main(BackendMain.java:64)
>>
>> Whats wrong ?
>>
>> Raivo
>>
>> On Mon, Sep 25, 2023 at 3:26 PM Raivo Rebane  wrote:
>>
>>> Hi,
>>> now I using following -
>>> [INFO] Copying postgis-jdbc-2.1.7.jar to
>>> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\postgis-jdbc-2.1.7.jar
>>> [INFO] Copying postgresql-42.6.0.jar to
>>> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\postgresql-42.6.0.jar
>>> [INFO] Copying checker-qual-3.31.0.jar to
>>> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\checker-qual-3.31.0.jar
>>> but on executions I got -
>>> Exception in thread "main" java.lang.NoClassDefFoundError:
>>> org/postgis/PGgeometry
>>> at
>>> backendproject.ProcQueryMushrooms.ProcQuery(ProcQueryMushrooms.java:41)
>>> at backendproject.BackendMain.main(BackendMain.java:81)
>>> Caused by: java.lang.ClassNotFoundException: org.postgis.PGgeometry
>>> at
>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>> at
>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>>     at
>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>>>
>>> What I have to do ?
>>>
>>> I use following -
>>> PostgreSQL 15.2, compiled by Visual C++ build 1914, 64-bit
>>> PostGIS  3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>>> Regards
>>> Raivo
>>>
>>> On Mon, Sep 25, 2023 at 2:29 PM Dave Cramer 
>>> wrote:
>>>
>>>> Sorry 42.6.0
>>>>
>>>> Interesting that github still has 42.5.4 as the release
>>>>
>>>> Dave Cramer
>>>> www.postgres.rocks
>>>>
>>>>
>>>> On Mon, 25 Sept 2023 at 07:27, Dave Cramer 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The latest version of the driver is usually the right answer. So 42.5.4
>>>>> Dave Cramer
>>>>> www.postgres.rocks
>>>>>
>>>>>
>>>>> On Mon, 25 Sept 2023 at 07:03, Raivo Rebane 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I use :
>>>>>>   PostgreSQL 15.2, compiled by Visual C++ build 1914, 64-bit
>>>>>> and
>>>>>> PostGIS  3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>>>>>>
>>>>>> What versions of jdbc driver I have to use for proper work ?
>>>>>>
>>>>>> Regards,
>>>>>> Raivo
>>>>>>
>>>>>>
>>>>>>
>>>>>>

Re: Right version of jdbc

[Dave Cramer]

The missing class is from the postgis jar. Are you sure it is on your
classpath ?

Dave Cramer
www.postgres.rocks


On Mon, 25 Sept 2023 at 08:26, Raivo Rebane  wrote:

> Hi,
> now I using following -
> [INFO] Copying postgis-jdbc-2.1.7.jar to
> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\postgis-jdbc-2.1.7.jar
> [INFO] Copying postgresql-42.6.0.jar to
> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\postgresql-42.6.0.jar
> [INFO] Copying checker-qual-3.31.0.jar to
> C:\Users\Raivo\eclipse-workspace\backendproject\target\lib\checker-qual-3.31.0.jar
> but on executions I got -
> Exception in thread "main" java.lang.NoClassDefFoundError:
> org/postgis/PGgeometry
> at
> backendproject.ProcQueryMushrooms.ProcQuery(ProcQueryMushrooms.java:41)
> at backendproject.BackendMain.main(BackendMain.java:81)
> Caused by: java.lang.ClassNotFoundException: org.postgis.PGgeometry
> at
> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> at
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>
> What I have to do ?
>
> I use following -
> PostgreSQL 15.2, compiled by Visual C++ build 1914, 64-bit
> PostGIS  3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
> Regards
> Raivo
>
> On Mon, Sep 25, 2023 at 2:29 PM Dave Cramer 
> wrote:
>
>> Sorry 42.6.0
>>
>> Interesting that github still has 42.5.4 as the release
>>
>> Dave Cramer
>> www.postgres.rocks
>>
>>
>> On Mon, 25 Sept 2023 at 07:27, Dave Cramer 
>> wrote:
>>
>>> Hi,
>>>
>>> The latest version of the driver is usually the right answer. So 42.5.4
>>> Dave Cramer
>>> www.postgres.rocks
>>>
>>>
>>> On Mon, 25 Sept 2023 at 07:03, Raivo Rebane  wrote:
>>>
>>>> Hi,
>>>> I use :
>>>>   PostgreSQL 15.2, compiled by Visual C++ build 1914, 64-bit
>>>> and
>>>> PostGIS  3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>>>>
>>>> What versions of jdbc driver I have to use for proper work ?
>>>>
>>>> Regards,
>>>> Raivo
>>>>
>>>>
>>>>
>>>>

Re: Right version of jdbc

[Dave Cramer]

Sorry 42.6.0

Interesting that github still has 42.5.4 as the release

Dave Cramer
www.postgres.rocks


On Mon, 25 Sept 2023 at 07:27, Dave Cramer 
wrote:

> Hi,
>
> The latest version of the driver is usually the right answer. So 42.5.4
> Dave Cramer
> www.postgres.rocks
>
>
> On Mon, 25 Sept 2023 at 07:03, Raivo Rebane  wrote:
>
>> Hi,
>> I use :
>>   PostgreSQL 15.2, compiled by Visual C++ build 1914, 64-bit
>> and
>> PostGIS  3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>>
>> What versions of jdbc driver I have to use for proper work ?
>>
>> Regards,
>> Raivo
>>
>>
>>
>>