George Woodring writes:
> I have always thought the way to avoid deadlocks was to update rows in the
> same order by the different updaters. Is there a better chain of thought
> for updating and deleting rows at the same time? Do we need to put a lock
> on the table to update, then have the dele
On Thu, Mar 10, 2022 at 10:56 AM Tom Lane wrote:
> Each cascaded delete ought to be removing a disjoint set of rows in the
> referencing
table, so I'm not quite sure why order should matter.
>
> regards, tom lane
>
I have always thought the way to avoid deadlocks was to
Hi all,
we have a setup where we use PGPOOL instances between our application
and the main DB server. Lately there is an intermittent but annoying
error that sometimes pops up:
ERROR: unable to parse the query
DETAIL: invalid read kind
SSL SYSCALL error: EOF detected
Version numbers:
pgpool 3
George Woodring writes:
> When using FOREIGN KEY ON DELETE CASCADE, is there an order the entries are
> being deleted?
No, there's no particular attempt to order the deletions. Each cascaded
delete ought to be removing a disjoint set of rows in the referencing
table, so I'm not quite sure why or
When using FOREIGN KEY ON DELETE CASCADE, is there an order the entries are
being deleted?
We are seeing intermittent deadlocks with trying to update a table with the
foreign key entry being deleted.
We have 4 levels of tables chained by foreign keys.
machine -> point -> poll -> status
The stat
Dominique Devienne writes:
> I've instrumented by libpq code, to show the byte size of the result-set.
> And I'm suprised that it's never smaller than 2,264 bytes, then the next
> size I see is 3,288, etc... Even when receiving no rows at all, in fact.
See PGRESULT_DATA_BLOCKSIZE and associated c
On Thu, Mar 10, 2022 at 7:22 PM Luca Ferrari wrote:
>
> Hi all,
> a friend of mine has shown to me a "strange" configuration of its
> physical replication server (13): he has both primary_conninfo and
> primary_slot_name, with replication slots active when queried on the
> master. So far so good,
Hi,
I've instrumented by libpq code, to show the byte size of the result-set.
And I'm suprised that it's never smaller than 2,264 bytes, then the next
size I see is 3,288, etc... Even when receiving no rows at all, in fact.
I've trimmed-out the SQL, but these are all SELECT statements.
The output
Hi,
On Thu, Mar 10, 2022 at 02:51:16PM +0100, Luca Ferrari wrote:
> a friend of mine has shown to me a "strange" configuration of its
> physical replication server (13): he has both primary_conninfo and
> primary_slot_name, with replication slots active when queried on the
> master. So far so good
Hi all,
a friend of mine has shown to me a "strange" configuration of its
physical replication server (13): he has both primary_conninfo and
primary_slot_name, with replication slots active when queried on the
master. So far so good, but in the configuration he has also
restore_command to restore a
On Thu, Mar 10, 2022 at 12:12 AM Scott Macri wrote:
I've verified the data a 100 times and am totally perplexed. Thanks.
>
> SELECT *
> FROM public.map_table
> WHERE company_letters = 'abcdefg';
>
>
Not sure what kinds of verification you did, but did you check to make sure
that there's no trail
Hi,
On Wed, Mar 09, 2022 at 08:40:45PM -0500, Scott Macri wrote:
>
> If I do a select * without a where clause I get the expected results.
> However, when I execute the following select statement I was astonished
> to see no results come back.
>
> SELECT *
> FROM public.map_table
> WHERE company_l
I have a simple database with table, "map_table", and coulmn,
"company_letters". The database is populated and the first row
contains a value of 'abcdefg' in the company_letters column.
If I do a select * without a where clause I get the expected results.
However, when I execute the following se
13 matches
Mail list logo
