I have the 'archive_cleanup_command' command specified, but I still have
WAL files.
The documentation seems to indicate that it will run automatically, but it
doesn't seem to be running.
archive_cleanup_command = 'pg_archivecleanup
DISKSTATION\\AccessData\\Prod\\WALfiles %r'
On Tue, Jan 16, 2024 at 7:33 PM Brad White wrote:
> On Tue, Jan 16, 2024 at 6:24 PM Ron Johnson
> wrote:
>
>> On Tue, Jan 16, 2024 at 6:26 PM Brad White wrote:
>>
>>> On Tue, Jan 16, 2024 at 4:35 PM Ron Johnson
>>> wrote:
>>>
On Tue, Jan 16, 2024 at 6:24 PM Ron Johnson wrote:
> On Tue, Jan 16, 2024 at 6:26 PM Brad White wrote:
>
>> On Tue, Jan 16, 2024 at 4:35 PM Ron Johnson
>> wrote:
>>
>>>
>>>> What database version?
>>>
>> v15
>>
>&
On Tue, Jan 16, 2024 at 3:53 PM Emanuel Calvo <3man...@gmail.com> wrote:
>
> El mar, 16 ene 2024 a las 22:47, Brad White ()
> escribió:
>
>> Errors from the Primary server
>>
>> 2024-01-15 00:01:06.166 CST [1428] ERROR: requested WAL segment
>> 000
On Tue, Jan 16, 2024 at 4:35 PM Ron Johnson wrote:
> On Tue, Jan 16, 2024 at 4:10 PM Brad White wrote:
>
>> Errors from the primary
>>
>> 2024-01-15 00:00:51.157 CST [2660] ERROR: requested WAL segment
>> 0001000200A2 has already been removed
>&g
Sorry for the repeat. It looked like it hadn't been sent.
>
Errors from the Primary server
2024-01-15 00:01:06.166 CST [1428] ERROR: requested WAL segment
0001000200A2 has already been removed
2024-01-15 00:01:06.166 CST [1428] STATEMENT: START_REPLICATION 2/A200
TIMELINE 1
2024-01-15 00:01:11.158 CST [3472] ERROR: requested WAL segment
Errors from the primary
2024-01-15 00:00:51.157 CST [2660] ERROR: requested WAL segment
0001000200A2 has already been removed
2024-01-15 00:00:51.157 CST [2660] STATEMENT: START_REPLICATION 2/A200
TIMELINE 1
2024-01-15 00:00:56.158 CST [492] ERROR: requested WAL segment
From: Ron
Sent: Thursday, November 2, 2023 3:01:47 AM
To: pgsql-general@lists.postgresql.org
Subject: Re: pg_dump/pg_restore --jobs practical limit?
On 11/1/23 15:42, Laurenz Albe wrote:
On Wed, 2023-11-01 at 13:09 -0500, Ron wrote:
I will "soon" migrate
From: Ron
Sent: Wednesday, October 25, 2023 4:35:59 AM
To: pgsql-generallists.postgresql.org
Subject: Re: setting up streaming replication, part 2
On 10/24/23 23:47, Brad White wrote:
On Tue, Oct 24, 2023, 9:02 PM Ron
mailto:ronljohnso...@gmail.com>> wrote:
On 10/24/23 19:29, Brad White
On Tue, Oct 24, 2023, 9:02 PM Ron wrote:
> On 10/24/23 19:29, Brad White wrote:
> > I have the replication server set up and the streaming is working.
> > The latest data show up, as desired.
> >
> > 3 minor issues.
> >
>
> > 2) I have the connec
I have the replication server set up and the streaming is working.
The latest data show up, as desired.
3 minor issues.
1) I also have the WAL files being copied to a common location from the
primary server with
archive_command = 'copy %p
"DISKSTATION\\AccessData\\Prod\\WALfiles\\%f"'
On Tue, Oct 24, 2023 at 8:56 AM Ron wrote:
> On 10/24/23 08:14, b55white wrote:
>
> Is all that stuff with slots necessary since the backup will automatically
> create a temporary slot for replication?
>
>
> I want a permanent slot so that replication automatically resumes if the
> secondary
I'm stumped.
Using this command to set up the slave and replication on PG v 15:
"C:\Program Files\PostgreSQL\15\bin\pg_basebackup" -h 192.168.1.126 -U
pgrep_user -p 5433 -D "C:\Program Files\PostgreSQL\15\data" -Fp -Xs -R
If I have PG running on the remote server and the data directory is
I wanted to thank everyone who helped out in our transition to the new
version.
Thanks especially to Tom, Laurenz, and Adrian.
It has taken over a year, since this upgrade project kept getting
superseded by more important projects, and because I only work with this
client one day a week, but as
I have the v15 service started and listening on 0.0.0.0:5434.
Through TCPView, I can see it listening on 5434, I can see the previous
version listening and connecting on 5432.
I can connect from localhost to port 5434.
I have ipv6 turned off in the network settings on both machines.
>From any
messages when run from CLI and
could fix the issue in pg_hba.conf.
Now the service starts.
Thanks,
Brad.
On Fri, Sep 22, 2023 at 2:43 PM wrote:
> Am 22.09.23 um 20:40 schrieb Brad White:
> > I'm trying to start a v15 service on a Windows 2012 R2 server where it
> > hasn't been u
s issue somehow.
On Fri, Sep 22, 2023 at 1:56 PM Brad White wrote:
> Good guess, but no. I should have mentioned that I checked that.
>
> There is, though, a postmaster.opts file that wasn't there earlier. It
> contains
> C:/Program Files/PostgreSQL/15/bin/postgres.exe &qu
he exe path.
On Fri, Sep 22, 2023 at 1:48 PM Nick Ivanov
wrote:
> I'd check if there is already "postmaster.pid" in C:\Program
> Files\PostgreSQL\15\data, left over from a previous abend.
>
> On Fri, Sep 22, 2023 at 2:40 PM Brad White wrote:
>
>> I'm trying to st
I'm trying to start a v15 service on a Windows 2012 R2 server where it
hasn't been used for a while.
The service is set to run as pgUser.
pgUser owns the Postgres directory, including the data dir.
The command the service is using is
' "C:\Program Files\PostgreSQL\15\bin\pg_ctl.exe"
Seems to me that your tool could set the env var that you want.
If you don't export it, I think it shouldn't "leak" but your child process
should get it as part of their environment.
On Fri, Sep 22, 2023 at 12:43 PM Dominique Devienne
wrote:
> On Fri, Sep 22, 2023 at 5:19 PM Luca Ferrari
David,
Thanks!
'EXPLAIN ANALYZE' is very slick.
Promises to be very helpful.
As soon as I saw the output, it was obvious where my problem was.
Brad.
On Mon, Mar 6, 2023 at 2:30 PM David G. Johnston
wrote:
> On Mon, Mar 6, 2023 at 1:18 PM Brad White wrote:
>
>>
>> As you
:
> On Mon, Mar 6, 2023 at 1:48 PM Brad White wrote:
>
>> LOL
>>
>> Joke's on me.
>>
>> Here's the relevant part of the view
>>
>> SELECT ...
>> "Order Items"."ID" AS "OrderItemID",
>> ...
>
Ds different?
Here are the results again, with the FileKey field expanded a bit.
[image: image.png]
On Mon, Mar 6, 2023 at 2:23 PM Adrian Klaver
wrote:
> On 3/6/23 12:17, Brad White wrote:
> > I was doing a SELECT * FROM view WHERE field LIKE pattern
> > and getting garbage data
I was doing a SELECT * FROM view WHERE field LIKE pattern
and getting garbage data back.
Turns out it is filtering on a different field.
As you can see here, when attempting to filter on the FileKey, it is
actually filtering on the Order Item ID field.
select "FileKey", "OrderItemID" from
On Tue, Feb 21, 2023 at 2:56 PM David Rowley wrote:
> On Tue, 21 Feb 2023 at 08:42, Brad White wrote:
> >
> > I'm concerned that Autovacuum may not be running based on the results of
> this query.
> >
> > SELECT relname, last_vacuum, last_autovacuum FROM pg_stat_u
On Tue, Feb 21, 2023 at 11:58 AM Christophe Pettus wrote:
>
>
> > On Feb 21, 2023, at 09:54, Brad White wrote:
> > Any suggestions on how to proceed?
>
> First, look at pg_stat_user_tables to see how many inserts etc. have
> occurred on the tables that are not show
On Mon, Feb 20, 2023 at 1:42 PM Brad White wrote:
> I'm concerned that Autovacuum may not be running based on the results of
> this query.
>
> SELECT relname, last_vacuum, last_autovacuum FROM pg_stat_user_tables;
> gives 211 rows like this...
> *relname
I'm concerned that Autovacuum may not be running based on the results of
this query.
SELECT relname, last_vacuum, last_autovacuum FROM pg_stat_user_tables;
gives 211 rows like this...
*relname| last_vacuum |
last_autovacuum*BusinessIncidentCategories
| null | null
Valid Use
On 2/16/2023 12:28 PM, Dominique Devienne wrote:
On Thu, Feb 16, 2023 at 6:51 PM Adrian Klaver
wrote:
You have two tables with list in their name, so are rows deleted from
both. Just to be clear enity_list should actually be entity_list?
Also how are entity and enity_list
> Are these UPDATE's actually necessary?
> In other words has nobody noticed a problem with the data over that time
frame?
I don't know what to make of it.
I had the same question you did.
I now have proof that these hundreds of errors are not an issue.
The postgres logs in pg_log clearly show
On Thu, Feb 9, 2023 at 5:10 PM Adrian Klaver
wrote:
> On 2/9/23 14:43, Brad White wrote:
> > On Tue, Feb 7, 2023 at 10:20 PM Brad White > <mailto:b55wh...@gmail.com>> wrote:
> >
> > On 2/7/2023 6:19 PM, Adrian Klaver wrote:
> >> On 2/7/23 16
>> Where these preexisting queries or where they created today?
> These queries are decades old but I don't view this log file very often,
so I don't know how long.
> I'll review when I get back on site Thursday and see if I can find any
users that are not getting the error or when it started.
On Tue, Feb 7, 2023 at 10:20 PM Brad White wrote:
> On 2/7/2023 6:19 PM, Adrian Klaver wrote:
>
> On 2/7/23 16:10, Brad White wrote:
>
> Front end: Access 365
> Back end: Postgres 9.4
> (I know, we are in the process of upgrading)
>
> I'm getting some cases where
On 2/7/2023 6:19 PM, Adrian Klaver wrote:
On 2/7/23 16:10, Brad White wrote:
Front end: Access 365
Back end: Postgres 9.4
(I know, we are in the process of upgrading)
I'm getting some cases where the SQL sent from MS-Access is failing.
Looking at the postgres log shows that the field names
Front end: Access 365
Back end: Postgres 9.4
(I know, we are in the process of upgrading)
I'm getting some cases where the SQL sent from MS-Access is failing.
Looking at the postgres log shows that the field names and table names are
not being quoted properly.
It has been my experience that
I'm setting my options for my DNS-less connection using
https://odbc.postgresql.org/docs/config.html
and
https://odbc.postgresql.org/docs/config-opt.html
I found it interesting that the sample at the bottom of the first page had
options that don't exist on the second page.
Namely, B4, B5, D4. I
1) Do not tack on to an existing thread, create a new post.
Yup. Failure on my part.
I'll repost.
Sorry about the reply failure. I was trying to start a new thread and
failed.
On Tue, Feb 7, 2023 at 5:42 PM Brad White wrote:
> I'm setting my options for my DNS-less connection using
> https://odbc.postgresql.org/docs/config.html
> and
> https://odbc.postgresql.org/docs/config-op
Front end: Access 365
Back end: Postgres 9.4
(I know, we are in the process of upgrading)
I'm getting some cases where the SQL sent from MS-Access is failing.
Looking at the postgres log shows that the field names and table names are
not being quoted properly.
It has been my experience that
Front end: Access 365
Back end: Postgres 9.4
(I know, we are in the process of upgrading)
I'm getting some cases where the SQL sent from MS-Access is failing.
Looking at the postgres log shows that the field names and table names are
not being quoted properly.
It has been my experience that
I'm setting my options for my DNS-less connection using
https://odbc.postgresql.org/docs/config.html
and
https://odbc.postgresql.org/docs/config-opt.html
I found it interesting that the sample at the bottom of the first page had
options that don't exist on the second page.
Namely, B4, B5, D4. I
On 1/31/2023 6:23 AM, hubert depesz lubaczewski wrote:
Not sure why:
2. you ask me that off list
In a lot of email clients, it is very easy to accidentally reply to the
author instead of the list without realizing it.
Hope that helps,
Brad.
--
Quote Signature I talk with clients, find out
On 1/6/2023 7:44 PM, Ken Tanzer wrote:
On Fri, Jan 6, 2023 at 3:32 PM Brad White wrote:
I can generate ALTER statements, per David's sensible suggestion,
but they fail because you have to drop all the views.
Altering the defaults seems safe because the default value
On Wednesday, December 28, 2022, Brad White wrote:
> On timestamp fields, I need to update the column default from the current
> "Now()" to "LOCALTIMESTAMP(0)"
>
> I could just manually make the change on every table, but they want the
> existing backups to sti
On 1/4/2023 9:34 AM, Ron wrote:
I don't think VACUUM FULL (copy the table, create new indices and
other metadata all in one command) actually vacuums tables. It's a
misleading name.
Something like REBUILD TABLE would be a better name.
Well s***.
That explains a lot. Thanks for clearing
RECAP
I'm running an Access front end against the Postgres back end.
Copying and updating a record succeeds in 9.4 but fails in 9.5 and
everything after.
It was the precision of the timestamp fields after all.
Turns out the initial data wasn't coming from Access, but from the
field default
On 12/24/2022 9:03 PM, David Goldsmith wrote:
How do I force "empty rows" to be included in my query output? (I've
tried LEFT JOINing to the row header results, and using CASE
statements; but due to my unfamiliarity w/ using crosstab, I'm not
sure if I've used those correctly in the current
We had a similar situation in a completely different context.
Our eventual solution was to fire off a request as soon as one came in.
Then we batched further requests until the first returned. Whenever a
request returned, we sent any pending requests.
Any single request not sent immediately was
I needed to be able to compare the contents of a table across
several databases and clusters.
Since it took me several hours to write this, I thought I'd share it with
you, in case anyone needs a starting point for anything similar.
BACKGROUND DETAILS:
These databases are all on sandbox
On 12/2/2022 9:05 AM, Peter J. Holzer wrote:
I don't know how reproducable that tokenization process is. Can you just
do it again and compere the results?
Right.
You can compare passwords, even though you don't store the original.
You might be able to run your virgin copy through the
On 11/30/2022 9:48 AM, Вадим Самохин wrote:
Thank you so much Ivan, it worked!
Can you give any more detail on which approach you took, for the sake of
future followers?
Tom,
I tried to run initdb after re-installing pg 12
using postgresql-12.10-2-windows-x64.exe.
But the runas I'm using to execute it as pguser seems to be swallowing all
the output, so I can't see any errors.
I was able to run pg_checksums and get those enabled.
Is there anything else I want from
On 11/18/2022 6:34 PM, Adrian Klaver wrote:
On 11/18/22 16:05, Brad White wrote:
--> The Microsoft Access database engine stopped the process because
you and another user are attempting to change the same data at the
same time.
Code in question:
rst!Update <-- success
tl;dr How do I turn up the logging so I can see what is failing?
In our quest to get replication working, we are upgrading from v9.4 to
v12.10.
Access365 via ODBC
Driver = "PostgreSQL Unicode" v13.02, Date 9/22/2021
In testing the app against v12, I find this issue:
On updating a record, I
>
>
> > How where the restored copies made on the original cluster?
> I guess I'm not understanding the confusion here. They were restored with
> the same script but to a different DB name and with the 9.4 executables.
> In fact, that was why the script was originally written, so we could
>
> If the client lets you, of course.
Right? 8: -)
That's not a concern here.
A) They trust me, and
B) They only see the front end. They don't really care what happens with
the back end.
so long as
A) It doesn't break, and
B) We get replication working.
>
> Step #1: upgrade to 9.4.26. You'll get *five years* of bug fixes.
Good idea.
I'll try 12 first, and if that doesn't work we'll go with this.
>
> When moving up in version you need to use the newer version of
pg_dump(...\12\bin\pg_dump.exe) to dump the 9.4 instance and then the
version 12 pg_restore to the 12 instance.
Oh my. That's a substantial change that could make a difference.
Thanks for catching that.
>
>
On Fri, Nov 11, 2022, 9:57 PM Adrian Klaver
wrote:
> On 11/11/22 18:41, Brad White wrote:
> > > From your original post, what did "Not the half dozen restored copies"
> > mean?
> > Over time, we've restored multiple copies for testing and reproducing
> >
Sorry. Ignore the errors. That was mistakenly copied in from elsewhere.
on anyway.
pg_restore: WARNING: column "Button5" has type "unknown"
DETAIL: Proceeding with relation creation anyway.
pg_restore
: WARNING: column "Button6" has type "unknown"
DETAIL: Proceeding with relation creation anyway.
pg_restore
: WARNING: colum
> Can you do a pg_dump of that database?
Yes. No visible problems. No errors reported.
On Fri, Nov 11, 2022 at 3:17 PM Adrian Klaver
wrote:
> On 11/11/22 13:11, Brad White wrote:
> > I deleted all the other DBs and left only the primary.
> > Still getting the same err
on Prod at least.
On Fri, Nov 11, 2022 at 3:17 PM Adrian Klaver
wrote:
> On 11/11/22 13:11, Brad White wrote:
> > I deleted all the other DBs and left only the primary.
> > Still getting the same error message, ending with
> >
> > ERROR: could not access status of tran
I deleted all the other DBs and left only the primary.
Still getting the same error message, ending with
ERROR: could not access status of transaction 22316920
DETAIL: Could not read from file "pg_clog/0015" at offset 73728: No error.
> What was the complete pg_upgrade command you used?
"C:\Program Files\PostgreSQL\12\bin\pg_upgrade" -d "C:\Program
Files\PostgreSQL\9.4\data" -D "C:\Program Files\PostgreSQL\12\data" -b
"C:\Program Files\PostgreSQL\9.4\bin" -B "C:\Program
Files\PostgreSQL\12\bin" -U postgres -p 5432 -P 5435
>
I'm upgrading from v9.4 to v12.10 as a half step to 15.
Q1: How do I tell it which database to upgrade?
I only need the primary.
Not the half dozen restored copies.
Or do I need to detach everything I don't want copied?
Q2: I get this error, and then at the end, it says "No error."
Performing
> Or manually running the application queries?
That was the odd thing. It didn't appear to be in the middle of running any
queries. The database shouldn't have had any effect.
> Anyway, try Pg 9.6.
I have Pg 12 installed, so I'll try that.
I'll start a new thread on my adventures in upgrading.
From the error log:
FATAL: hot standby is not possible because wal_level was not
set to "hot_standby" or higher on the master server
HINT: Either set wal_level to "hot_standby" on the master, or
turn off hot_standby here.
I tried setting hot_standby to off, but that
On 11/7/2022 3:42 PM, Rob Sargent wrote:
> Care to share some of the ways the app stopped working? You might
get a leg up on where best to remediate.
I don't recall, as that was a few months ago.
We are running MS-Access as a front end with Postgres as the back end.
It appeared to read and
>
>
> > v9.4 has been EOL for 2 years 9 months.
As I said, the next step will be to upgrade.
It would make sense to upgrade first, since "there have been some big
advances since then which make replication much easier"
But when we upgraded, the app stopped working.
So I'll need to go through and
I'm setting up a backup for our primary postgres server using the archived
WAL files.
Then I'll try to upgrade it to Streaming Replication.
Then I'll upgrade the system to v.latest.
For now, we are on v.9.4.
I do a base backup from the primary to a directory on the NAS.
"C:\Program
72 matches
Mail list logo
