=?UTF-8?B?6ZmI?= writes:
> I tried to access the PostgresDB 32bit, with 64bit libpq and it works very
> nice.
> So my question is, can we use 64bit lippq to access 32bit PostgresDB in
> X86_64 platform?
Seems like you know your answer already.
In any case, the PG wire protocol is platform-in
Hi, all
We use 32bit postgres PG11 in our product for X86_64 platform, Now we want to
add new process which is 64bit
to access the 32bit progres using 64bit libpq.
I tried to access the PostgresDB 32bit, with 64bit libpq and it works very nice.
So my question is, can we use 64bit lippq to acc
> The buildfarm is still complaining about the synopsis being too
> wide for PDF format. I think what we ought to do is give up on
> using a for log lines at all, and instead convert the
> documentation into a tabular list of fields. Proposal attached,
> which also fixes a couple of outright err
Andres Freund writes:
> It's been broken in different ways all the way back to 9.0, from what I can
> see, but I didn't check every single version.
> Afaics the fix is to nuke the idea of doing anything substantial in the signal
> handler from orbit, and instead just set a flag in the handler.
+
Hi,
On 2022-04-09 16:10:02 -0700, Andres Freund wrote:
> It's not that (although I still suspect it's a problem). It's a self-deadlock,
> because StandbyTimeoutHandler(), which ResolveRecoveryConflictWithBufferPin()
> *explicitly enables*, calls SendRecoveryConflictWithBufferPin(). Which does
> Ca
postgreSql_ New and improved website for pgjdbc (JDBC) (2022).pdf
Description: Adobe PDF document
Hi,
On 2022-04-09 15:00:54 -0700, Andres Freund wrote:
> What are we expecting to wake the startup process up, once it does
> SendRecoveryConflictWithBufferPin()?
>
> It's likely not the problem here, because we never seem to have even reached
> that path, but afaics once we've called disable_all_
Hi,
On 2022-04-09 14:39:16 -0700, Andres Freund wrote:
> On 2022-04-09 17:00:41 -0400, Tom Lane wrote:
> > Thomas Munro writes:
> > > Unlike most "procsignal" handler routines, RecoveryConflictInterrupt()
> > > doesn't just set a sig_atomic_t flag and poke the latch. Is the extra
> > > stuff it
On 4/9/22 1:14 PM, Greg Stark wrote:
On Sat, 9 Apr 2022 at 10:51, Tom Lane wrote:
Sound like bugfixes to be backpatched.
Yeah. I'm not sure why these have received so little love.
Since bug fixes are important enough that they'll definitely get done
(and can happen after feature freeze)
Hi,
On 2022-04-08 22:05:01 -0700, Andres Freund wrote:
> On 2022-04-08 21:55:15 -0700, Andres Freund wrote:
> > on CI [1] the new t/031_recovery_conflict.pl is failing occasionally. Which
> > is
> > interesting, because I ran it there dozens if not hundreds of times before
> > commit, with - I th
Hi,
On 2022-04-09 17:00:41 -0400, Tom Lane wrote:
> Thomas Munro writes:
> > Unlike most "procsignal" handler routines, RecoveryConflictInterrupt()
> > doesn't just set a sig_atomic_t flag and poke the latch. Is the extra
> > stuff it does safe? For example, is this call stack OK (to pick one
>
Thomas Munro writes:
> Unlike most "procsignal" handler routines, RecoveryConflictInterrupt()
> doesn't just set a sig_atomic_t flag and poke the latch. Is the extra
> stuff it does safe? For example, is this call stack OK (to pick one
> that jumps out, but not the only one)?
> procsignal_sigus
Tatsuo Ishii writes:
> Patch pushed. Thanks.
The buildfarm is still complaining about the synopsis being too
wide for PDF format. I think what we ought to do is give up on
using a for log lines at all, and instead convert the
documentation into a tabular list of fields. Proposal attached,
whic
Hi,
Unlike most "procsignal" handler routines, RecoveryConflictInterrupt()
doesn't just set a sig_atomic_t flag and poke the latch. Is the extra
stuff it does safe? For example, is this call stack OK (to pick one
that jumps out, but not the only one)?
procsignal_sigusr1_handler
-> RecoveryConfl
On Sat, Apr 9, 2022 at 12:07 PM Andres Freund wrote:
>
> > ... specific counters. In particular, replay will not increment
> > pg_stat_database or pg_stat_all_tables columns, and the startup process
> > will not report reads and writes for the pg_statio views.
> >
> > It would helpful to give at
Hi,
On 2022-04-07 21:39:55 -0700, David G. Johnston wrote:
> On Thu, Apr 7, 2022 at 8:59 PM Andres Freund wrote:
>
> >
> >
> >Cumulative statistics are collected in shared memory. Every
> >PostgreSQL process collects statistics
> > locally
> >then updates the shared data at approp
On 4/9/22 12:27 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
-1, at least for the moment. Sometimes a user doesn't know what they're
looking for coupled with being unaware of what the default value is. If
a setting is set to a default value and that value is the problematic
setting, a user sh
On Sat, 9 Apr 2022 at 10:51, Tom Lane wrote:
>
> > Sound like bugfixes to be backpatched.
>
> Yeah. I'm not sure why these have received so little love.
Since bug fixes are important enough that they'll definitely get done
(and can happen after feature freeze) there's a bit of a perverse
incenti
On Sat, Apr 9, 2022 at 12:25 PM Andrey Borodin wrote:
> Please excuse me if I'm not attentive enough. I've read this thread. And I
> could not find what is the problem that you are solving. What is the purpose
> of the WAL file name you want to obtain?
Yeah, I'd also like to know this.
--
Rob
On 4/9/22 16:31, Tom Lane wrote:
Christoph Berg writes:
I would think that if \dconfig showed the non-default settings only,
it would be much more useful; the full list would still be available
with "\dconfig *". This is in line with \dt only showing tables on the
search_path, and "\dt *.*" sh
On Sat, Apr 9, 2022 at 10:31 AM Tom Lane wrote:
> Christoph Berg writes:
> > The name has evolved from \dcp over various longer \d-things to the
> > more verbose \dconfig. How about we evolve it even more and just call
> > it \config?
>
> I think people felt that it should be part of the \d famil
On Sat, Apr 9, 2022 at 9:27 AM Tom Lane wrote:
> "Jonathan S. Katz" writes:
> > -1, at least for the moment. Sometimes a user doesn't know what they're
> > looking for coupled with being unaware of what the default value is. If
> > a setting is set to a default value and that value is the proble
On Sat, Apr 09, 2022 at 12:31:23PM -0400, Tom Lane wrote:
> Julien Rouhaud writes:
> > On Sat, Apr 09, 2022 at 10:42:12AM -0400, Tom Lane wrote:
> >> Also, good luck with "looking in the logs", because by default
> >> WARNING-level messages don't go to the postmaster log.
>
> > I must be missing
On 4/8/22 21:02, Andres Freund wrote:
> Hi,
>
> On 2022-04-08 19:27:58 -0500, Justin Pryzby wrote:
>> On Thu, Apr 07, 2022 at 10:10:21AM -0700, Andres Freund wrote:
>>> On 2022-04-06 11:03:37 -0400, Andrew Dunstan wrote:
On 3/30/22 20:26, Andres Freund wrote:
> Could you try using dash t
Julien Rouhaud writes:
> On Sat, Apr 09, 2022 at 10:42:12AM -0400, Tom Lane wrote:
>> Also, good luck with "looking in the logs", because by default
>> WARNING-level messages don't go to the postmaster log.
> I must be missing something because by default log_min_messages is WARNING,
> and
> AFA
"Jonathan S. Katz" writes:
> -1, at least for the moment. Sometimes a user doesn't know what they're
> looking for coupled with being unaware of what the default value is. If
> a setting is set to a default value and that value is the problematic
> setting, a user should be able to see that eve
> On 9 Apr 2022, at 18:30, Bharath Rupireddy
> wrote:
>
> Using insert tli when not in recovery and using tli of the last WAL
> replayed record in crash/archive/standby recovery, seems a reasonable
> choice to me.
Please excuse me if I'm not attentive enough. I've read this thread. And I
c
On 4/9/22 11:58 AM, Julien Rouhaud wrote:
On Sat, Apr 09, 2022 at 10:31:17AM -0400, Tom Lane wrote:
Christoph Berg writes:
I would think that if \dconfig showed the non-default settings only,
it would be much more useful; the full list would still be available
with "\dconfig *". This is in li
On Sat, Apr 09, 2022 at 10:31:17AM -0400, Tom Lane wrote:
> Christoph Berg writes:
>
> > I would think that if \dconfig showed the non-default settings only,
> > it would be much more useful; the full list would still be available
> > with "\dconfig *". This is in line with \dt only showing table
On Sat, Apr 09, 2022 at 10:42:12AM -0400, Tom Lane wrote:
>
> Also, good luck with "looking in the logs", because by default
> WARNING-level messages don't go to the postmaster log. If that's
> the intended use-case then the message ought to appear at LOG
> level (which'd also change the desirable
Greg Stark writes:
> On Sat, 9 Apr 2022 at 06:44, Alvaro Herrera wrote:
>>> * Simplify some RI checks to reduce SPI overhead
>> Move to next; a lot more work is required.
> If it's going to be part of a much larger patch set I wonder if it
> shouldn't just be marked Rejected and start a new thr
Alvaro Herrera writes:
> On 2022-Apr-08, Greg Stark wrote:
>> * fix psql pattern handling
> Sounds like a bugfix, but how old and how backpatchable a fix is?
> Thread is quite long.
There's been more contention than one could wish about both what
the behavior should be and how to refactor the co
Julien Rouhaud writes:
> On Fri, Apr 08, 2022 at 09:39:18AM -0400, Stephen Frost wrote:
>> Having this in pg_stat_statements is certainly helpful but having a
>> warning also is. I don't think we have to address this in only one way.
>> A lot faster to flip this guc and then look in the logs on a
Christoph Berg writes:
> The name has evolved from \dcp over various longer \d-things to the
> more verbose \dconfig. How about we evolve it even more and just call
> it \config?
I think people felt that it should be part of the \d family.
Also, because we have \connect and \conninfo, you'd need
On Fri, Apr 8, 2022 at 7:28 PM Robert Haas wrote:
>
> On Fri, Apr 8, 2022 at 9:31 AM Bharath Rupireddy
> wrote:
> > Fundamental question - should the pg_walfile_{name, name_offset} check
> > whether the file with the computed WAL file name exists on the server
> > right now or ever existed earlie
On Sat, 9 Apr 2022 at 06:44, Alvaro Herrera wrote:
>
> > * Simplify some RI checks to reduce SPI overhead
>
> Move to next; a lot more work is required.
If it's going to be part of a much larger patch set I wonder if it
shouldn't just be marked Rejected and start a new thread and new CF
entry for
On Wed, Mar 30, 2022 at 09:30:51AM -0700, Nathan Bossart wrote:
> On Tue, Mar 29, 2022 at 12:22:21PM -0400, Robert Haas wrote:
> > It's not, though, because the original proposal was to change things
> > around so that the value of MaxBackends would have been reliable in
> > _PG_init(). If we'd don
On Sat, Apr 09, 2022 at 02:38:50PM +0530, Bharath Rupireddy wrote:
> On Fri, Apr 8, 2022 at 10:22 PM SATYANARAYANA NARLAPURAM
> wrote:
> >
> >> > wrote:
> >> > >
> >> > > Hi,
> >> > >
> >> > > I'm thinking if there's a way in core postgres to achieve $subject. In
> >> > > reality, the sync/async
On Tue, Jan 4, 2022 at 1:40 AM SATYANARAYANA NARLAPURAM
wrote:
>
> On Sun, Jan 2, 2022 at 11:56 PM Michael Paquier wrote:
>>
>> On Sun, Jan 02, 2022 at 09:27:43PM -0800, SATYANARAYANA NARLAPURAM wrote:
>> > I noticed that pg_receivewal fails to stream when the partial file to write
>> > is not fu
On 2022-Apr-08, Peter Smith wrote:
> PSA patch v6 to address some of Amit's review comments [1].
I think the text is good (didn't read it all, just about the first
half), but why is there one paragraph per sentence? Seems a bit too
sparse.
--
Álvaro Herrera 48°01'N 7°57'E — htt
On 2022-Apr-08, Greg Stark wrote:
> These remaining CF entries look like they're bugs that are maybe Open
> Issues for release?
>
> * fix spinlock contention in LogwrtResult
I don't have a good enough grip on barriers needed for this, so I'd
rather move it to pg16 to have time for further study.
On 2022-Apr-08, Andres Freund wrote:
> I just realized that the second find is pretty expensive compared to the
> first.
>
> time find "$sourcetree" -type d \( \( -name CVS -prune \) -o \( -name .git
> -prune \) -o -print \) | grep -v "$sourcetree/doc/src/sgml/\+" > /dev/null
> real 0m0.019s
>
Re: Tom Lane
> Looks like the consensus has shifted to \dconfig. I'll do it like that.
A bit late to the party, but two more ideas:
The name has evolved from \dcp over various longer \d-things to the
more verbose \dconfig. How about we evolve it even more and just call
it \config? That would be
On Fri, Apr 8, 2022 at 10:22 PM SATYANARAYANA NARLAPURAM
wrote:
>
>> > wrote:
>> > >
>> > > Hi,
>> > >
>> > > I'm thinking if there's a way in core postgres to achieve $subject. In
>> > > reality, the sync/async standbys can either be closer/farther (which
>> > > means sync/async standbys can rec
44 matches
Mail list logo
